I am forced to use HTML::Mason for the dynamically generated web page. Unfortunately, the page depends on some long running computation. I need to display progress to user somehow. Is it possible to make Mason not to wait until the page is fully generated?
Having had a similar problem (though I was using Template Toolkit as the front end), the solution I used was to show the user a "query is in progress" page. This had a link that the user could click to check for results; if the query had finished, the results came up, and if not, another "progress" page was loaded. The page automatically refreshed after a certain amount of time so the user could just sit and wait if they preferred.
You could write some javascript that polls the server and dynamically loads the result into the page, rather than having the page reloading every x seconds.
Related
I am making a chrome extension that fetched JSON data from CoinMarketCap.com API and currently I have it running in the background script. I'm not 100% sure what the purpose of the page is really. I was wondering if I could simply fetch the data from the popup script after I click a button within my popup?
Each button represents a different coin. I basically want to get the price of a chosen coin and display it on whatever page the user is on when they double click the coin in a text article. Eventually I want to make it so you can double click any coin and have it show a live price conversion while you're on the web-page.
The point of a background page is to be always available (running if persistent: true, woken up / recreated for registered events if persistent: false).
A popup's lifetime is determined by its visibility. The moment the user clicks away and closes it, the page is closed (as if the tab with it was closed), so it can no longer process any events and its state is lost.
As long as:
The data you need fetched is to be received/processed while the popup is open
Any state you need to persist between popups being shown can be stored in chrome.storage
Then you don't need the background page to do the fetching. Popup page has the same level of access to Chrome APIs.
However, consider this scenario: suppose you want the data to be ready as soon as popup is opened (at least, you want it to be fresher than "since last time"). You may want to do periodic updates even while the popup is closed to refresh the data. You can only do that reliably with a background page (and, say, chrome.alarms API). Then you can cache the latest available data in chrome.storage and use that in the popup.
Background pages have their uses as some code that can run periodically regardless of user actions, and to be able to always react to events.
According to Changes to Cross-Origin Requests in Chrome Extension Content Scripts now you have to do your fetches in Background Script. Not in Content Script.
My web application is mimicing the UI of my desktop application, flow is as follows
Select Task in browser window
Change any Options and then start
Show Progress in same browser window, the progress bar goess back to server every 5 seconds checking progress.
When task has completed we show report in new tab
and go back to Select task Window,
this is done by running following Javascript in progress page
window.open('/start','_self'); window.open('/reporturl','_blank');
This works fine on my PC but when trying on Safari on OSX and on Android phone and iPad one of two things happen
The progress page becomes the start page but the report page is not opened in tab
The Progress page becomes the report page
My question is does opening window in new tab with _blank have all the problems of using popup windows. If so should I modify my prcoess so that at stage 3 it just displays report page, and then add a back button or navigable footer to the report to allow user to get back to start page ?
I can think of some options you could use instead of new tab.
Modal with Ajax
-- With jQuery it is posible to open modal
dialogs they can be populated with html (or other data) fetched with ajax (async). I am a big fan of these and use them all over my projects. Users will not be annoyed with pop-up warning messages, etc. Once the content is read (or whatever) the user can simply close the dialog. (If I had to make your app I would certainly implement this).
Besides the jQuery dialogs, other modal/dialog scripts are out there. Check out Bootstrap Modal if you like it modern.
Serve report as download
-- Depending on what the user can/will do with the report, it might be interesting to write the report page in a way that it sends back a .pdf file, or another type of file, as download. Loading the URL in a new tab will now always start a download. Triggering this from JS without user interaction might be a problem though (same as with pop-up / new tab). Adding a button to trigger the download on complete will solve this.
I know the question was about the use of tabs.. But try to avoid it. Browsers handle it all in their own way. And many users get confused when suddenly stuff is opening in tabs when they did not ask for it. In case of pop-ups, it is possible for users to turn them of or convert into opening a new tab from within the browser settings. If they have been fiddling with browser defaults, you'll have troubles of keeping the 'flow' of the app the same for all users (and cross browser).
I'm building a Google Chrome extension at the moment and I have a question about when to use an event page.
A quick look at the Chrome extension docs shows that Google really want its developers to use event pages, if possible.
My extension currently uses a background page, but I was wondering if I should switch to an event page?
This is what my extension does:
When matched with a particular website, it injects a script that adds buttons for the user to access extra functionality.
Most of this extra functionality consists of doing fairly computationally expensive operations on user-entered data - this is all done in the background page (it is all it does).
When a user wants to run these operations on their data they press a button and this passes a message, from the injected script to the background page, which then passes a message back containing the results of its operations.
Essentially, all the background page is doing is waiting for message passing from an injected script in one particular website and then running some operations. Since it doesn't need to be active all the time, this suggests that I should be using an event page.
Can anyone confirm if this would be a good idea for me? Or are there reasons why I should stick to a background page?
Allowing the background page to suspend (chrome.runtime.onSusend) is great, because it will free up system resources. The page will automatically be launched when a matching event happens (chrome.tab.onUpdated etc). I can't think of any compelling reason to use a persistent background page. You can always store any long term state in chrome.storage.local or indexedDb, etc.
Here's what happens:
Page loads (a timeline view)
User scrolls down to the bottom
More timeline content is loaded via AJAX
The URL is set to a new value with history.pushState(). If this URL is accessed directly, it loads the timeline so that it includes all content that's been loaded dynamically so far.
The user clicks a link in the timeline
The user then clicks the back button in the browser.
My question: when the back button is pressed, will the browser do a fresh load of the url provided via pushState() (which may involve a large performance hit if they have gone a long way down the timeline)? I'm hoping that instead it will update its page cache somehow when pushState() is called to include the DOM with the dynamic content added, and then reload that instead.
If it doesn't do any automatic cache magic like that, is there any way to make it do so in order to improve performance? It seems wasteful to reload a large number of posts every time the user clicks away from the timeline. Also, as they scroll, the URL is constantly updated so it would be a fresh load of all posts every time they click away, not even using normal browser caching.
I've looked for information, but can't seem to find anything that says how pushState() modifies the cache, if at all.
I've been working on a new website and practicing my JS/jQuery/AJaxy skills. Last night I wanted to take a look at how long the page was taking to render and see if there were any areas I could clean up to increase speed. While the page loads in about 200 - 300 ms every time, I'm seeing a large amount of blank space between resource loads under the network inspector.
http://i.imgur.com/7ng6m.jpg
Has anyone else seen this or know what I can do to minimize that time (talking about the blank space between like the html and the first css file)?
Quite possibly it is caused by the extensions you have installed. AdBlock, LastPass and Google quick scroll took altogether about 200 ms on my machine.
Unfortunately, these extensions are invoked on every site and block loading the additional resources.
Try it with out of the box browser setup, the loading time will increase tremendously.
You've got a bunch of images loaded just after the page has been loaded (the load and DOMContentLoaded events have fired - the blue and red vertical lines across the Timeline). I can see that the images are loaded by the JQuery library (the Initiator column), perhaps to build a gallery or something.
So, the case is that JQuery loads the images after the page load, presumably in the onload handler (this can look like $(document).ready(handler) in your code, but other options are possible, too).
The delay between the initial page load and requesting the first resources is almost certainly caused by Chrome extensions. To find the culprit: Record a timeline in the Timeline tab in Chrome Developer Tools; Identify the scripts that are running during the Parse HTML phase; Work out which extensions they're from.
To record a timeline:
Open the timeline tab and click record.
Reload the page and then stop the recording. (A couple of seconds should be enough.)
To find the culprit:
Find the first main Parse HTML block on the timeline. On the row below you will probably see one or more Evaluate Script blocks. These are the culprits.
Click on one of the Evaluate Script blocks and find the script name in the bottom pane. Mouse-over the script name. The tooltip will have the URL of the script, which should be of the form chrome-extension://{long_identifier}/{path}
Memorise the first few letters of the identifier and search for it in the chrome://extensions/ page. This tells you which extension is causing the problem. Try disabling it - you should see a difference.
Repeat for the other Evaluate Script blocks.
In my case, I have 20 extensions installed but only two were causing a delay: LastPass and Fauxbar. I've chosen to leave them enabled because for me the productivity benefit of these extensions outweighs the downside of the added latency.