A bit of a curve ball request that might well not have a solution, but worth asking...
We have a heavy AJAX-based website and we rely on modal/loading screens fairly heavily to indicate when something important is happening. All works well.
We also have some operations that trigger full page changes which can take a couple seconds. I'd like to impose the same modal/loading screen when those changes kick off, however- if a user cancels the page load I'd like to detect it and take the loading modal down. Else it'd just sit there forever.
I can watch for the Escape key being used but is there a way to detect the cancellation in a more generic way that'd also work when initiated by the browser's cancel controls?
Thanks
P.S. To be clear, I'm talking normal page changes in this case. Mentioning the AJAX used elsewhere was just to explain why I want the loading screen now; for consistency. Otherwise I think we'd all agree it's abnormal to have loading screens just to navigate around a site.
RESULT
Evidently not possible.
As niklas found:
But now I see what you're tying to do and i found this https://stackoverflow.com/a/1776490/3877639. I don't like your odds I'm afraid.
Started answering, then I saw Carlos answer and thought I might have misinterpret your question. I'll leave my first answer in the bottom, just in case it might be of some use to you either way.
You wish to detect the page load being canceled. But if the page load is canceled, won't the ajax call fail? Couldn't you listen for that some how and then take down the modal/loading screen?
Don't know if you use jQuery's .ajax(), but then it's easy doing stuff if there's any errors.
What you are looking for is the onunload event. However, the browser support is not so good (as you can see in the link).
There's also the onbeforeunload event that has better browser support, but it triggers a browser dialog you can't override. Just send a text to. Then the user can choose to stay on the page or leave it/close it.
Basically you can abort the XMLHttpRequest the ajax call returns with jQuery.
See this
Related
I have a link that opens a new window using window.open. The pop up works fine, however the normal web page stops loading objects (images, scripts, ajax scripts) and sometimes the page doesn't load at all.
Here is my code:
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
Is there anything I am doing wrong?
Thanks,
Peter
First of all, please be more specific: tell us more about your browser and which version, and possible your OS. It could be more related to the browser than to the web content.
Then on to the possible problem; you start with saying "I have a link that ...".
To me that sound like you use <a href="javascript:DoSomething()">. Or perhaps <a href="#" onclick="DoSomething()">.
I tried both in some modern browsers: Chrome v37, IE v11. Both browsers did not produce what you describe:
- Chrome v37 will happily keep on loading, even if I immediately click a "window.open()"-link on top of a (huge) webpage;
- IE v11 will someshow show "false", which is strange, but still not what you got.
In some cases I also got to deal with the popup blocker.
A general tip might be to NOT USE <a href> for things like this. Behaviour seems inconsistent across browsers, also these days there are better alternatives, such as <span onclick="">...</span> and <button onclick="">...<button> or by using JQuery or other frameworks (which I do not know much about).
Although this many not be a conclusive answer, maybe this can help you experiment on your own, and think about possible causes or alternative ways of doing things.
The behaviour you describe should definitely NOT normally happen. This is confirmed by robbmj's JSFiddle, that fails to reproduce the problem. That's evidence that something is going on in the main page that is not plain vanilla page loading, or your "link opening" has something unusual to it. Apart from the syntax error (you use four parameters, not three).
Since you do not supply information on either of these points (how do you load the main page? How do you trigger the popup-opening code?), we do not even know if the problem
might be browser-related; I'd start and try to test things in IE, Chrome and Mozilla to see
whether anything changes; this might provide some useful insights.
One possibility
A very strong possibility is that your inadvertent fourth parameter goes into the window.open() "replace" parameter, which is a boolean, and triggers undefined behaviour or simply an error that stops everything. You should have things somewhat working in IE and not working at all in Firefox.
You should also be able to see whether this is the case by using Firefox and the Firebug extension, or the Web Developer Console in Chrome.
Another possibility
A more esoteric possibility is that the way you define the link might make the browser believe you've actually moved on to another page, so that there's no point in continuing loading the current page. Depending on the browser, this might have to do with how the link is defined and could be remedied by defining it some other way.
For example it could conceivably happen if you had
...
which I suspect is what led user Tomzan to ask, "is the link something like javascript:...?"
So if this is the case, try with this instead (this works for me in IE9/Chrome/FF):
link
function openPopup() {
MyWindow = window.open('player.php', 'Player', 'width=500, height=300');
// Also try the following. You won't probably like the results (it should send the
// popup window behind), but if it works, it proves we're dealing with a browser
// issue there.
// Blur and refocus
// MyWindow.blur();
// window.focus();
// Just focus
// window.focus();
return false;
}
Workaround
A possibly acceptable workaround could be to disable the link altogether (or hide it via CSS), and only reactivate/show it upon main document being ready. This sidesteps the problem, even if user experience could be somewhat worse due to a longer wait.
But if it's so likely that a user clicks on the link before waiting for the whole page to load, I'd also consider not automatically loading the rest of the page at all, and reorganize information to provide a more streamlined navigation. Or maybe distribute it on two sequential pages. Again, unfortunately you did not supply enough information to do more than guess.
As you probably know, JavaScript is single threaded. Every event is queued until there is idle time for it to be executed.
In the case of window.open, both windows must share a single context to keep it thread-safe because the opened window can access to it's parent using window.opener.
I don't know how browsers implements it, but we can guess two possibilities:
Idle time is shared between the two windows. It means if the popup does many blocking statements, it can freeze the main window's events.
Only one of the two windows can be active, which depends on which one has the focus. In that case, all events may be paused in the main window when you're using the popup.
If you want a more precise answer, I need more details about your code.
document.addEventListener("DOMContentLoaded", function () {
//whatever the code
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
}, false);
Try to wrap the code in SetTimeout
setTimeout(function () {
window.open( .. )
}, 0);
Your document should be loaded first, then popup should be open, So write your javascript code in the scope of $(document).ready().
enter code here
$(document).ready(function(){
$("#clickme").click(function(e){
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
});
});
I ran across this code in some HTML and I am unsure what the point of it is:
onresize="window.location.reload(false);"
I am not very proficient in JavaScript, but it looks like it basically just... reloads the browser window when it is resized? Does that even work? It seems odd.
It does reload the page as you suspect, although the argument false that is passed to reload indicates that the page should be reloaded from the cache if possible, to minimize load time. See Mozilla's window.location documentation for more details.
I suspect this is to force the browser to re-layout the page in case resizing the window changes how it renders. Typically that should not be necessary, especially if the site is employing responsive web design techniques, but some sites may do it anyway.
I agree with Stuart. Do you own this code? In other words can you make changes to the code and deploy it to some test environment? If so, try commenting that line and see what happens. May be this line was added way back when some particular browser couldn't handle window re-size events correctly. May be it's not needed anymore.
I am trying to write a JavaScript script that is "overlayed" on top of a Facebook page. It uses DOMContentLoaded to detect when content is loaded, then adds some extra stuff in. However, because Facebook doesn't actually "reload" the page when going to a new page (it just uses AJAX), the DOMContentLoaded handler doesn't run again, even though there is new stuff to look through.
Anyway, to detect the change, I thought about using onhashchange since Facebook used to change the page's hash, but in Firefox 4 (I need to support Firefox 3 and later with this, but no other browsers), Facebook doesn't change the hash anymore and in pre-Firefox 3.6 there is no onhashchange.
I thought about using DOMNodeInserted, but would that really slow down the page? (I really can't have any slowdowns in this script.)
you might want to monitor the windows.history object, see the following answer, on how facebook uses it to update pages:
"Redirect" page without refresh (Facebook photos style)
For lightweight pages it generally doesn't have noticable effect. However, on bulky pages (I tried this on gmail) it makes that really really slow that I cannot even compose a message smoothly. And that event was added to a very simple span element which just had a single link in that. The events like DOMNodeInserted and DOMSubTreeModified are real show stoppers.
UPDATE: For all those trying to find an answer to this, note that these methods DOMNodeInserted (or DOMSubtreeModified) really had performance problems, so according to new ECMA specs it is a much faster listener : MutationObserver for doing the same thing (and more).
https://hacks.mozilla.org/2012/05/dom-mutationobserver-reacting-to-dom-changes-without-killing-browser-performance/
i search online but can't get satisfactory result
i want to protect images on my website, i know i can disable save as, right click.
the real question is can we Disable Clipboard & Print Screen with JQUERY or java script.
so no image copy from print screen.
thanks
Not from a webpage.
Even if you were able to disable these from within a browser, it will only stop a casual user. If you make a resource available on a public server (as you must in order to let a casual user view it), there really is no way to stop someone from retrieving that resource. After all, you actually want the user to retrieve the resource.
No. I am pretty sure you can't do that. Print screen is a part of the OS, not the browser. I would hope that web sites weren't able to mess with my OS like that.
You can certainly throw roadblocks in front of people trying to download an image, but short of watermarking, there isn't a great way to prevent people from getting your image (that I know of) if you make it available online.
No you can´t. And you can´t disable right click in a bullet proof way either.
The only way to protect your images is by watermark them.
Print Screen is a function of the operating system, and as such, cannot be disable by a webpage.
Actually, you can't disable anything. I know you technically can, but most browsers have an option to not allow disabling of those things. And really, worst case scenario, anyone can view the source of your site and copy the image's url.
In short, don't worry about it so much. Some people will copy your images, but this is nothing new on the internet, so you'll just have to learn to live with it. The only thing that any of your work will do is annoy some people, and make other people have to try a little bit. So, it's really best to not do anything. Place a copyright notice on your site and most people won't try to blatantly steal from you.
The only way to do what you're requesting is to incorporate OS-embedded DRM into your content (think HDCP). This can prevent even screenshots from being done but will severely limit your audience and is an absolutely horrible idea - don't do it!
If you really want to protect your images, the best way to do it is with watermarks and providing very low-quality images on your website and the high-quality stuff in some other way. The watermarks aren't a perfect solution but many consider them good enough.
Well there is no direct way to do that, but I used javascript to hide the content whenever the user hovers outside the website. This forces the user to actually activate your page to be able to see its content. This will activate the javascript that prevents prnt scrn too.
I would like to use the jquery slideUp effect when the user navigates away from the page just to make the page look cool as it closes.
I assume that I should use the onunload event but how can I delay the page closing long enough for the effect to run to completion.
One of the options that came to mind is effectively hijacking the page closing function, storing it in some variable and then executing it once I had run my effect but I have no idea how I would do that.
Any suggestions or alternative ideas are more than welcome
what you're looking for is the onbeforeunload event.
just a warning though... it should be really quick... or your visitors are probably going to hate it no matter how cool it looks
as to preventing the page from navigating away before the animation is done, that's a bigger problem... any animation is going to rely on setTimeout/setInterval and the page won't wait for those to complete before leaving.
Doing anything but closing the window when the users ask to is breaking a contract with the user. The browser window is not yours, it's the users, and no matter how cool the effect, it will inevitably annoy most of your users.
The onbeforeunload event is very restricted in what it can do. It must return a string, which is then used to prompt the user for a confirmation about leaving the page. It won't work for cool animations.
As far as I know, the only way to stop a user from leaving a page is the onbeforeunload event, which isn't cancelable. Instead, you return a string from that method, the browser prompts the user with a Yes/No dialog, life goes on. 276660 has more info about this.
I don't think you're going to have much luck with this one.
why not, instead of making a "cool" effect when a user simple want to go away from your website (even if the user closes the browser/tab the unload event will be fired) and annoying the simple user with that ... preventing him/her to return again...
...do that "cool" effect when a user reaches your website for the first time? as a normal intro effect?
I did that as a simple idea, you can see it here: http://www.balexandre.com/jmfc
I would agree 100% with Jonathan Fingland's answer, and add this.
In IE, (I'm not sure what versions support this, I know IE6 did) you can use some propriety meta tags to achieve fades etc when leaving the page. However, this is limited in browsers (IE only), so you're stuck for cross browser use.
You may find loading new content via AJAX would give you better control of effects and transitions, as well as reducing the annoyance factor to the user which can result from trying to hijack the browser actions in such a manner.
I would look at using a form of slider as mentioned above (see for instance http://webdesignledger.com/tutorials/13-super-useful-jquery-content-slider-scripts-and-tutorials),
or simply loading content panes in response to user clicks.
The only way I've found for delaying the window to close, is using an alert. If this is an acceptable compromise for your case, it will really delay the window destruction in memory, and allow your page timers to execute (of course, if user does not close the alert popup earlier than your animations finalize).
I recently used this approach so i could call a flex method through FABridge (which would otherwise be destroyed before the flex method call finishes). I'd like to hear your comments on this.