Bug 19324 - onbeforeunload related bug?
: onbeforeunload related bug?
Status: NEW
Product: WebKit
Classification: Unclassified
Component: Forms
: 525.x (Safari 3.1)
: PC Windows XP
: P2 Normal
Assigned To: Nobody
: InRadar
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-30 10:12 PDT by Tore B. Krudtaa
Modified: 2010-11-18 19:02 PST (History)
5 users (show)

See Also:


Attachments
Tescase and explanation on how to reproduce (5.42 KB, application/octet-stream)
2008-05-30 10:15 PDT, Tore B. Krudtaa
no flags Details
USE THIS TESTCASE (this is htm file and not php) (5.40 KB, text/html)
2008-06-13 05:43 PDT, Tore B. Krudtaa
no flags Details
Here you can test the two bugs that might be related (7.06 KB, text/html)
2009-03-04 10:26 PST, Tore B. Krudtaa
no flags Details
work in progress (746 bytes, text/plain)
2010-11-18 15:58 PST, Ryosuke Niwa
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tore B. Krudtaa 2008-05-30 10:12:37 PDT
Tested in Safari 3.1.1 (525.17) for Win XP

See attached php file for testing and javascript.

The page produces a warning to the user if the form has been modified and the user tries to navigate away from current page. 

If the page has been modified, if any of the two checkboxes are checked, and the user does one of the following:
Tries to close the browser.
Tries to navigate away from the page either by using the select in the form, or enter a new address in the address field, or click a link in the page (if it had been a link).
then the user should be presented with a warning. 

To see the strange behaviour do the following:
Open the page
Check either one of the checkboxes
Then change the content of the select box
You should now be presented with the warning, as expected
In the dialogbox (the warning), click Cancel to stay on the page.
Then try click anywhere in the page, except on the select and the Save button.
Now Safari displays the same dialog box again. Which it should not.

See attached php file for testing and javascript.
Comment 1 Tore B. Krudtaa 2008-05-30 10:15:03 PDT
Created attachment 21436 [details]
Tescase and explanation on how to reproduce

Example file to reproduce the bug.
Comment 2 Tore B. Krudtaa 2008-06-09 02:06:06 PDT
Is everyone on vacation?

Would appreciate if some could look into this.
Comment 3 Tore B. Krudtaa 2008-06-13 05:43:18 PDT
Created attachment 21679 [details]
USE THIS TESTCASE (this is htm file and not php)

Now there should be no reason not to look at this bug anymore.
Last attachment is HTM file and not PHP file.
Comment 4 mitz@webkit.org 2008-06-13 10:43:20 PDT
I think the problem might be that the change event is fired twice (the second time when the select element is blurred).
Comment 5 Tore B. Krudtaa 2008-06-14 02:13:36 PDT
Okay, but this is still a bug in Safai for XP, isnt it?

Hope someone can fix this bug ASAP!
Comment 6 Tore B. Krudtaa 2008-06-19 09:00:41 PDT
Hope someone can fix this ASAP.

It is a truly annoying bug!

Who is taking it?
Comment 7 Adele Peterson 2008-06-19 09:47:20 PDT
I agree that this is a bad bug.  Here are some ways that you could contribute to getting this fixed quicker:

- Help track down if this is a regression (using WebKit nightlies), and if it is, which revision caused the problem.

- Help determine if it is platform-specific.  If you don't have access to other platforms, hop on IRC, and ask other community members for help.

- Work with members of the community to learn more about the issue, and retitle this bug to describe the underlying problem as well as the symptom.

If you have more questions about the relative priority of this issue, you may want to take a look at this document:

http://webkit.org/quality/bugpriorities.html

This will give you a good idea if this bug should be re-prioritized as a P1 issue.

In general, comments in a bug that provide more information are very useful.  But you may not it effective to request a higher priority just through the bug comments.
Comment 8 Adele Peterson 2008-06-19 09:48:32 PDT
meant to write, "you may not find it effective..."
Comment 9 Tore B. Krudtaa 2008-06-19 14:03:32 PDT
Well here is my take on it.

I make my living from developing web-apps.

When I find bugs in browsers like Firefox, Opera, and Safari then I try to post my findings ASAP in hope of getting the bugs fixed.
I did not mention IE here, probably because IE developers lives in a secret place somewhere and do not want to be disturbed... so there is no easy way to report bugs to those guys... shame on them.. and probably one reason that IE sucks big time.

Of the three mentioned here Firefox and Safari (webkit) really shines. :)
Why is that?
Because they give the users like me the ability to post bugs and to actually be able to follow up the bug and see if there is any bugfixing going on.

Opera is allmost as bad as IE. They have a way to report a bug. But when the bug has been reported it is lost in Opera's private cyberspace and only insiders knows what happens with that bugreport....

So WebKit do shine.....

Some of the bug reporters may have the time to do what you require, test nightly builds etc. etc.... 

I'm not one of those guys.... do not have time for this kind of testing.

I just reported the bug I found to WebKit team through this forum and I truly belive that should be enough "food" for the webkit team to handle it from now.

I belive that this is a to serious bug for it to be overlooked.
The onbeforeunload feature is an important feature for my customers.

The number one place I use it is to check if the form a user leaves is dirty (has been changed), and if it has, then one can prevent the user leaving the page without first beeing told that some changes where done and then give the enduser the option to stay on the page and save the changes.
For those that do not know it, it even works if you close the browser.. whooohaaa. 

So WebKit team keep up the good work, but I cannot contribute more than just reporting it :)
Comment 10 Adele Peterson 2008-06-19 14:07:47 PDT
That's fine if you can't contribute more.  We appreciate what you have contributed so far, and that information will certainly help when we work on the bug.

But please be aware that comments like #2, #5, and #6 will not help get the bug fixed any faster.
Comment 11 Mark Rowe (bdash) 2008-06-19 14:25:03 PDT
<rdar://problem/6022367>
Comment 12 Tore B. Krudtaa 2008-06-20 10:55:59 PDT
Installed the latest official Safari for XP today.

Version 3.1.2 (525.21)

The bug is still there.
Comment 13 William J. Edney 2008-06-23 15:58:52 PDT
Adele & Co. at Apple/Webkit -

Thanks for putting this into your queue for fixing. It's a really, really bad issue for those of us doing heavy 'AJAX' apps where we store client side data.

I've also filed another bug (bug 19418) about onbeforeunload not working in framesets. They may be related to that.

Note that, at least for me, this used to work in Safari 3.0 for Windows, but was broken when I updated to 3.1 for Windows. Not sure if that bit of information helps. It also continues to be broken in the Safari 4.0 developer preview.

Again, thank you for your help here.

Cheers,

- Bill
Comment 14 Hugo 2008-08-13 14:33:16 PDT
I found this issue too, but also found a woraround. This only works for frames that are in the same domain i.e. document.domain="foo"; on both.

In the frame, add top.document.onbeforeunload=beforeunload;

What it does is that it registers the event on the frame to fire the event that is coded in the top frameset.

The issue exist in both Mac and windows on Safari 3.0 and 3.1

Again, this is just a workaround.
Hugo
Comment 15 Tore B. Krudtaa 2008-09-03 05:41:46 PDT
Hi

Have just tested this bug using Chrome browser, and the BUG is there to...
Not a big surprise though....

Now two browsers are affected by this BUG!

Maybe another reason to get this bug fixed ASAP.
Comment 16 William J. Edney 2008-09-03 09:56:32 PDT
Confirmed that this bug also affects Chrome.

Any way to get this fixed soon? (before the Safari 4.0 release... please...)

Also note this bug around onbeforeunload for framesets....

https://bugs.webkit.org/show_bug.cgi?id=19418

Cheers,

- Bill
Comment 17 William J. Edney 2008-10-25 14:32:14 PDT
Folks -

This is still present in Webkit Build 37819 for Windows.

Any chance of fixing this soon?

Thanks!

Cheers,

- Bill
Comment 18 Tore B. Krudtaa 2008-10-31 01:23:29 PDT
This was reported a loooong time ago....

Installed latest version of Chrome 0.3.154.9 today, and the bug is still there.

AFAIK this affect both Safari for windows as well as Chrome.

Any chance to get this bug fixed?

This is a truly annnoying bug!
Comment 19 Tore B. Krudtaa 2008-11-13 23:52:14 PST
Innstalled Safari 3.2 (build 525.26.13) for win today....

And this bug has still not been fixed. (how many years will it take to get this done?)

Maybe time to assign this bug to someone and get it fixed.

AFAIK this bug also is present in Chrome.
Comment 20 William J. Edney 2009-02-05 16:36:27 PST
Webkit folks -

This bug is still present in Webkit Build 40471 for Windows.

This bug is *not* present in Webkit Build 40471 for Macintosh (i.e. the testcase properly shows the onbeforeunload dialog before allowing the window to be closed or navigated). In fact, I've never had an onbeforeunload problem on Macintosh.

It's also in Chrome, so I'm headed over the Chromium bug tracker to see if a bug needs to be filed there.

Can someone *please* take a look at this bug?

Let me know if there is any way I can help - really! I'm willing to help in whatever way I can.

Cheers,

- Bill
Comment 21 William J. Edney 2009-02-05 16:46:41 PST
All -

I'm going to retract my statement regarding Chrome. As of build 2.0.160.0, they properly catch and handle onbeforeunload.

So, that means that they're ahead of you all here :-)   <- Note: this is a joke...

Cheers,

- Bill
Comment 22 Tore B. Krudtaa 2009-02-06 06:13:30 PST
One thing is for sure:

This bug is still present in latest dev version of Chrome: 2.0.160.0
Also present in Safari for Win version: 3.2.1 (525.27.1)

And Chrome is supposed to be out of beta... THAT must be a joke.

Will this annoying BUG EVER get fixed ????





Comment 23 William J. Edney 2009-02-06 13:08:44 PST
Tore -

Two items:

1. I went back and looked more closely at your testcase and indeed I am now seeing the problem you are seeing in both the latest Webkit for Windows (40471) and Chrome (2.0.160.0). The problem is that you didn't reduce your testcase enough... this isn't a problem with onbeforeunload. I downloaded and edited your testcase to just remove the onbeforeunload handler and tried again. Same result - the dialog box will again if you click a second time (but it won't show a third time). This happens if any other GUI event occurs, such as tabbing to the next form control, etc.

This has nothing to do with onbeforeunload, but rather a problem where another onchange is fired if a) the onchange() handler prompts the user with a dialog and b) it modifies the form (i.e. to reset values, etc.) before it returns.

Therefore, I think this bug could very well be a dupe of: https://bugs.webkit.org/show_bug.cgi?id=23721. That bug number also shows a Chromium bug number.

2. It really isn't helpful to come onto a bug and rant. I don't work on the Webkit team, but I have been doing the Web since 1997 and have contributed to a whole suite of bugs on the Mozilla Bugzilla database and have filed my share of bugs here too. Some of these folks are paid, some are volunteer - all have more work than they have time in the day, just like the rest of us. Yes, bugs can be frustrating - believe me, I know. But the best thing to do is to try to come up with a reduced testcase that shows what you're trying to do in the fewest lines of code possible to reproduce the bug. That way, these folks can go right to the heart of the matter. Yes, this takes time - that's your contribution back to this open source project.

Webkit team -

I recommend to mark this bug as INVALID or as a DUP of 23271 (as that bug has a more accurate description of what's really going here, IMHO), unless anyone else has any objections. I'd also be willing to file a new bug, with a new testcase, if folks think that this is something different than 23271.

Cheers,

- Bill
Comment 24 Tore B. Krudtaa 2009-03-04 10:26:35 PST
Created attachment 28271 [details]
Here you can test the two bugs that might be related

Found another bug that might be related to onbeforeunload.

Have created a new testfile, showing the two bugs.

I really hope that someone can take a look at this and get the bugs fixed regardless if this is related to onbeforeunload or not.

Both bugs appears in latest versions of Safari and Chrome.
Comment 25 Adele Peterson 2009-03-04 11:41:44 PST
Tore, please file a new bug so it can be investigated separately from this one.
Comment 26 Tore B. Krudtaa 2009-05-20 00:04:20 PDT
Have now reported a new bug for "BUG 1" as seen in the latest testcase reported in this bug.

It is located here:
https://bugs.webkit.org/show_bug.cgi?id=25885

Will be interesting to see if anybody will take action and fix these serious bugs.
They are showstoppers for both Safari and Chrome.

Regards


Comment 27 Tore B. Krudtaa 2009-06-03 00:29:20 PDT
Just did a test on Safari for Mac today version 3 browser.

Looks like the same bug is there as well.

This affects both chrome and safari on windows, and Safari on Mac.

Would be nice if someone could get this bug assigned.

Why has it not been assigned?
Comment 28 Tore B. Krudtaa 2009-06-05 02:29:35 PDT
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=26211

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=26213

I therefore suggest this bug is closed.

Comment 29 Ryosuke Niwa 2010-11-18 15:58:41 PST
Created attachment 74309 [details]
work in progress

Here's very easy change to enable this feature.  I'll go talk with other folks to see if there are any security problems, and also to write tests.
Comment 30 Ryosuke Niwa 2010-11-18 16:31:56 PST
oops, I got confused this bug with the bug 19418.  My patch was for 19418.