I have a website that uses a long-polling comet connection. The connection needs to be setup on/after page load.
Despite my efforts to prevent it, many browsers consider the long-poll request to be part of the page loading mechanism, thus keeping the page in a 'loading' phase. In Safari this results in the progress bar (behind the url field) to not complete. In Chrome the favicon is shown as a spinning loading icon. Even more problematic is mobile safari on iphone, that does not allow hiding the url field while 'loading'. Mobile android has similar issues on some devices.
All in all, the behavior is difficult to reproduce and seems to be dependent on browser/platform/connection speed/etc. Right now, my code initiates the long polling 10msecs after the window.onLoad trigger. This seems to work well often, but not always. I suspect it may have something to do with loading some external (image/javascript) resources, yet one would say the onLoad event is fired after these are completely loaded.
Anyone some pointers on how to force these browsers into considering my page as loaded? Ideally, one could somehow mark an xmlhttprequest as comet-like, but this is no feature :).
I've been having the same issue and found that if you allow the page to exit its onload handler before issuing your long polling ajax request, everything works fine and the page does not go back into a loading state.
So for example, what usually would be
$(document).ready(function() { $.ajax(...); });
would become
$(document).ready(function() setTimeout(function() { $.ajax(...); }, 0); });
In the particular case of WebKit, I believe that $(document).ready is a synonym for window.onload. So that's why it matters.
This worked for me on iPad1,1 with iOS 5.
We have been successful removing the "loading" indicator in Safari 5.1.5 with ajax long polling requests. Chrome unfortunately still consistently shows the loading indicator. For chrome, our team has chosen to simply change the css cursor value on the entire body element (ex: crosshair or a custom cursor) - a terrible "hack" - but at least the user won't see the loading mouse cursor while they are on the system.
Related
I would like to display a nice page transition when navigating between pages on a site.
I've tried using these events: beforeunload unload pagehide and also visibilitychange.
There was a webkit bug described as
visibilitychange:hidden doesn't fire during page navigations
And a workaround is listed:
using the pagehide event is the workaround
I am adding a class to the html element on these events. On Chrome and Firefox this activates my loading indicator class and the animation is displayed until the page is replaced. I get a nice loading transition between page navigation. So, in Chrome and Firefox, everything works great.
Unfortunately, I am not having any luck with Safari on iOS (iPhone or iPad) and also failing on macOS Big Sur Safari. I found a related question here: Safari change dom on before unload page however, it only discusses the beforeunload event. I am hoping that by being less specific here that a viable alternative pops up.
I have tested the css works on Safari by manually applying it and also verified my listeners are called on Safari via the javascript console. However the css change doesn't seem to be rendered. There is no transition shown on the page being unloaded before getting the new page response from the server. I've also verified it isn't related to the CSS in use by setting a simple background color without any transition or similar effects.
So far, the only way that I have been able to get Safari to render the dom change is by returning a truthy string on unload - but this prompts the user if they want to leave or not which is not my intention.
I want to avoid browser detection - however the last viable alternative I can come up with is scanning the dom for anchors, buttons, forms, etc when Safari is detected to enable the loading indicator before navigating.
Are there any other options to consider?
I have a php page that hangs for 3-10 seconds after the page loads, you can't even scroll up or down, or close the tab when this happens. (the chrome loading gif still loops tho) Happens in Chrome and IE.
Chrome Timeline: http://imgur.com/wF5Pioz,KRbnxIm#0
Shows ContentVeil.js repeating over and over. I think it is client side(?), I did a grepWIN to search for ContentVeil, with no luck, and it doesn't show up in Chrome Network tab.
Chrome Profile: Second image, from above link.
I think this shows the issue at the anonymous function from meta-boxes.min.js, ln 1.
meta-boxes.min.js: http://pastebin.com/yqtJyqB1
Unfortunately line one is a function that encapsulates the whole script. I don't know js very well, I tried to just remove each function one by one but that just created more errors.
Any ideas on how I could find the source of the problem would be much appreciated.
It's part of the Evernote web clipping extension, and it's hooks DOM events, causing massive slowdowns if you are doing large amount of dom changes.
I have an aspx page with JS calling window.location.reload(true) to force refresh a page when a function is called.
This appears to work a few times, with the page reloading as expected, but gets to a scenario where the function is called (i.e. alert in the function is visible) but the reload does not occur. I've also tried setting window.location with the same outcome - it works 2 or 3 times then fails.
This does not occur in Firefox (16), but is happening in different versions of IE (7 & 9)
Using Fiddler to monitor the browser traffic, all is as expected when the reload is working, but there is no traffic reported when the reload stops, suggesting the browser is not sending the request to the server? The IE window does go blank with the loading spinner spinning, but eventually IE displays the error page:
Internet Explorer cannot display the webpage
Most likely causes:
You are not connected to the Internet.
The website is encountering problems.
There might be a typing error in the address.
This appears to lock the browser. Trying to hit another website results in the same output in Fiddler (nothing). Opening a new IE window means I am able to hit the site with no problems.
This was initially causing a problem updating UpdatePanels via __doPostBack so this JS reload of the page was seen as a quick workaround, but this does not seem to be the case.
I would tend to think this is server related, but I have been unable to replicate the issue in Firefox. This does however unfortunately have to work in IE.
Any ideas much appreciated!
JS snippet below (though this is pretty simple stuff)
function ReloadWindow() {
alert(window.location); // Can see this alert, even when page fails to reload
window.location.reload(true);
}
Why is it that when I visit my jQuery mobile page, lets say page.php it shows up fine, but when I visit the same page page.php#someDetailsHere it just shows a white page?
And how can I fix this?
I use a third party app that redirects to my webpage with the # added to the url..
Edit: I stepped through your page to see what was going on.
Your grief is caused by jQuery Mobile. When the page loads, it detects this as an "page change", and because jQuery Mobile uses the hash (#) to emulate the back-button for AJAX requests, it also has some special handling for pages that it sees are loaded with a hash.
The bottom line is that it sees a page load, decides it should "reject" it, and prevents anything further from happening.
My guess is that the jQuery Mobile team didn't expect anyone to load a mobile page with a hash on init, since the code seems to assume that the first load of the page will not have one.
To follow this yourself, set a breakpoint in the function isEmbeddedPage in jquery.mobile-1.0.min.css.
A possible solution would be to somehow prevent the jQuery Mobile code from running when the page initially loads. This might break other stuff that jQuery Mobile provides, though.
As says It turns out jQM parses hashes for its own purposes and just freezes if it can't make sense of them on load (unnecessarily aggressive behaviour if you ask me, they should at least fire a custom event — although there is a high priority issue reported for it on GitHub).
One solution is to disable jQM's hash processing: before DOM ready, execute the following:
$.mobile.hashListeningEnabled = false;
Note this will necessarily break any functional reliance on jQM's history polyfill on browsers that don't support history pushState (IE etc).
Currently I am developing a web application for which I am using a pre-loader icon. What I want is that the pre-loader becomes visible every time the user navigates to another page or refreshes the page. So far I have the following solution:
window.onbeforeunload = function() { $("applicationdisabler").show(); };
For Safari and Firefox it works fine when the user clicks a link or refreshes the page. However in IE7 the div only becomes visible when the user clicks a link and NOT when the user refreshes the page.
The user can refresh the page by hitting F5 (on Windows) or any other possible way the browser provided.
Of course I have been looking for some workarounds already. The following code shows the alert in IE7, but the div still doesn't become visible.
window.onbeforeunload = function() { $("applicationdisabler").show(); alert("come on!"); };
The code of my div:
<div id="applicationdisabler"><img src="images/preloader.gif" /></div>
Hopefully someone can help me out.
You need to put the # before the id on the jQuery selector:
$("#applicationdisabler").show();
Why not use just use the onLoad listener instead? Although it would be slightly slower it should be more reliable.
Actually after a bit of looking around I'm not sure modifying the DOM makes any sense unless the onBeforeUnload handler returns false first - i.e. forces the user to stay on the same page.
As I understand it the onBeforeUnload event is fired just before the page is unloaded, so if you don't return false the browser will unload the page and DOM, and any JavaScript executed after that will be pointless.
That doesn't quite explain why JavaScript isn't executed properly in the onBeforeUnload function, but from what I've seen sites only use the window.alert or window.prompt dialogs to ask the user if they want to leave the site, and then often executing JavaScript if the user decides to stay.
Hence I'm guessing that some browsers may not allow DOM manipulation when this event is fired - since if the page is unloaded any DOM manipulation done is completely pointless.
So either:
Return false in your onBeforeUnload method, and then show your preloader (although this will stop navigation to the next page)
Use the onLoad event of the next page to show the preloader image instead
Also note: Opera versions 9.5 and below do not support this event (I'm unsure about later versions) but GMail does manage to catch the back button in Opera.
Possibly related is this security warning for IE7's implementation of the onBeforeUnload event - it's possible Microsoft patched it in a way that prevents the things you're trying to do. And I know IE6 and below don't allow commands like document.location='' in the onBeforeUnload handler for security reasons.