Hi. There seem to be a problem with onbeforeunload for Safari (and Chrome) for WIN XP. All versions. If I change a field in a form and then click a button that "tries to leave the page" and the form is made in such way that it triggers the onbeforeunload event and the user click cancel in the message triggered by the onbeforeunload if you then click the button again.... nothing happens. Please test BUG 1 in attached testcase. I kept a related bug (BUG 2) in the same testcase ref. this issue: https://bugs.webkit.org/show_bug.cgi?id=19324 Really hope that this can be fixed. Have several web applications that make use of the very handy onbeforeunload..... and if my customers would like to use safari or chrome then they cannot do it because of this bug. Has reported other problems with unbeforeunload that affects both safari for win and Chrome... but nobody wanted to fix that: See here for a related bug : https://bugs.webkit.org/show_bug.cgi?id=19324 Hope someone can take this (these) BUGS serious now and get it fixed. Regards
Created attachment 30498 [details] Testcase to see the bug(s) in action
Tore - I too am tracking the variety of bugs that have to do with Webkit's poor support for onbeforeunload. I really need to sit down and do a test case for all of the variety of ways that this can be set. I did figure out a workaround that, at least, works for me: 1. Either put the onbeforeunload="...function text..." on the body element itself or 2. Put some JavaScript in your page that sets that attribute on the body as part of the onload process, thusly: function onloadSetup() { document.body.setAttribute('onbeforeunload', 'return "Do you really want to do this?"'); } .... And then in your markup: <body onload="onloadSetup()">...</body> Hope this helps. Cheers, - Bill
Hi William I have now tried your proposed workaround. I found it not to work for my attached example. Same bugs as before for both Safari and Chrome. Could you please look at my testcase for this bug and change it so it works. Regards
Tore - Spent some time working with your test case. My proposed fix does *not* fix your bugs. I thought I would try some of the 'latest builds' of both Webkit and Chrome, since it was logical that if the bugs were fixed, they would've been fixed there. Here are my results, based on your bug #1 and bug #2: Mac OS X, Webkit 43880 Bug #1: Success Mac OS X, Webkit 43880 Bug #2: Failure Mac OS X, Chrome 2.0.182.0 Bug #1: Failure Mac OS X, Chrome 2.0.182.0 Bug #1: Failure Win XP, Webkit 43880 Bug #1: Failure Win XP, Webkit 43880 Bug #2: Failure Win XP, Chrome 2.0.180.0 Bug #1: Failure Win XP, Chrome 2.0.180.0 Bug #2: Failure I'll post over to the Chromium bug to let them know about these results. Cheers, - Bill
Hi again William Instead of posting a new case a chromium you could eventually make a post here: http://code.google.com/p/chromium/issues/detail?id=4422 I see they closed that bug today, even though I really do not understand why they did it.... as you can see from my comment in that bug.... If you can make any sense from the comment from jon I would be interested in knowing what I missed in his comment and his link (URL). I would really like to see the proposed solution from jon's link used in my attachment... just could not figure out how that could be done.... If you figure it out please let me know! If you choose to post a new bug in chromium please post a link to that here. Regards
Hi. Have done more testing and have reduced the bug(s) a bit more. I have filed a new bug which describes it better: Please look here: https://bugs.webkit.org/show_bug.cgi?id=26213 The other bug which I though where related... was not, and is in a new bug here: https://bugs.webkit.org/show_bug.cgi?id=26211 I therefore suggest this bug is closed.
> I therefore suggest this bug is closed. Done.