Bug 26211 – Cancel in onbeforeunload dialog sometime causes a button to stop working.

• Component: Forms
• Status: RESOLVED FIXED

[Tore B. Krudtaa]

If you (have a form and) are using the onbeforeunload
Then you have a button which run code like this:
document.frmName.submit();
which causes the onbeforeunload to trigger

If you then press "Cancel" (Safari) or "Stay on this page" (Chrome) 
then, if you try clicking the same button again, nothing happens.

Now, if you have a textfield on the same page, you could mouse-click on the text field to put cursor in textfield and then TAB out of the tetfield (using TAB key) and the button will start working again.

(If you just mouse-click inside the textfield and then mouse-click outside the textfield again, then button will not start working again.)

Please see testcase to see how this works.

[Tore B. Krudtaa]

Created attachment 30998 [details]
Testcase

Use this to reproduce the bug

[Tore B. Krudtaa]

This bug is also in 

Safari for win, version: 4.0 (530.17)

and latest version of Chrome... version: 2.0.172.30

[Steve Waring]

Further to this. If you have a number of elements with an associated onclick function on the page, where by the function does some work and then submits the form, then:

When you click on one of the elements, the leave/stay fialogue is shown. If you choose stay on page, then thereafter clicking on the element you clicked on previously does not give you the leave/stay dialogue, and the page is not unloaded. IE the same bug as described above. If you now click on a different element that has the same function bound to the onclick event, the same scenario is repeated, but the first element you clicked on now "comes back to life" and clicking on it once again gives you the leave/stay dialogue.

In this situation, clicking into a text box does not bring the onclick element back into life.

This happens in Google Chrome 3.0.195.38

[Andy Estes]

Created attachment 103793 [details]
Patch

[Andy Estes]

*** Bug 66128 has been marked as a duplicate of this bug. ***

[Andy Estes]

<rdar://problem/9765500>

[Alexey Proskuryakov]

Comment on attachment 103793 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=103793&action=review

I only glanced over the patch, since Jessie had a deeper look already.

> LayoutTests/fast/loader/form-submission-after-beforeunload-cancel.html:22
> +    return "";

It might be slightly less confusing to return an actual string like "Please don't agree to closing the page to test". In fact, does this test work for manual testing? It seems like it should.

> Source/WebCore/loader/FrameLoader.cpp:2736
> +    if (!shouldClose)
> +         m_submittedFormURL = KURL();

Bad indentation here (five spaces).

[Andy Estes]

(In reply to comment #7)
> (From update of attachment 103793 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=103793&action=review
> 
> I only glanced over the patch, since Jessie had a deeper look already.
> 
> > LayoutTests/fast/loader/form-submission-after-beforeunload-cancel.html:22
> > +    return "";
> 
> It might be slightly less confusing to return an actual string like "Please don't agree to closing the page to test". In fact, does this test work for manual testing? It seems like it should.

Agree. It does work for manual testing. I have a paragraph of text in the test explaining what to do, but having useful text in the confirmation dialog will make it even more obvious.

> 
> > Source/WebCore/loader/FrameLoader.cpp:2736
> > +    if (!shouldClose)
> > +         m_submittedFormURL = KURL();
> 
> Bad indentation here (five spaces).

I blame Xcode :(

[Andy Estes]

Committed r92982: <http://trac.webkit.org/changeset/92982>