Bug 19324 – onbeforeunload related bug?

• Component: Forms
• Status: NEW

[Tore B. Krudtaa]

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.

[Tore B. Krudtaa]

Created attachment 21436 [details]
Tescase and explanation on how to reproduce

Example file to reproduce the bug.

[Tore B. Krudtaa]

Is everyone on vacation?

Would appreciate if some could look into this.

[Tore B. Krudtaa]

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.

I think the problem might be that the change event is fired twice (the second time when the select element is blurred).

[Tore B. Krudtaa]

Okay, but this is still a bug in Safai for XP, isnt it?

Hope someone can fix this bug ASAP!

[Tore B. Krudtaa]

Hope someone can fix this ASAP.

It is a truly annoying bug!

Who is taking it?

[Adele Peterson]

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.

[Adele Peterson]

meant to write, "you may not find it effective..."

[Tore B. Krudtaa]

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 :)

[Adele Peterson]

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.

[Mark Rowe (bdash)]

<rdar://problem/6022367>

[Tore B. Krudtaa]

Installed the latest official Safari for XP today.

Version 3.1.2 (525.21)

The bug is still there.

[William J. Edney]

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

[Hugo]

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

[Tore B. Krudtaa]

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.

[William J. Edney]

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

[William J. Edney]

Folks -

This is still present in Webkit Build 37819 for Windows.

Any chance of fixing this soon?

Thanks!

Cheers,

- Bill

[Tore B. Krudtaa]

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!

[Tore B. Krudtaa]

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.

[William J. Edney]

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

[William J. Edney]

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

[Tore B. Krudtaa]

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 ????

[William J. Edney]

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

[Tore B. Krudtaa]

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.

[Adele Peterson]

Tore, please file a new bug so it can be investigated separately from this one.

[Tore B. Krudtaa]

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

[Tore B. Krudtaa]

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?

[Tore B. Krudtaa]

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.

[Ryosuke Niwa]

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.

[Ryosuke Niwa]

oops, I got confused this bug with the bug 19418.  My patch was for 19418.

[supremepack]

spam removed