1306686 - submit form fails if iframe display changed to none

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Cree]

Attachment: test.tar.gz Example test page. See line in inner.html that can be commented out to get Firefox to POST again.

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160922113459

Steps to reproduce:

Submit a form where the iframe for that form is changed to "display: none" prior to the onsubmit function completing.


Actual results:

No "submit" occurs - no network POST etc.


Expected results:

A network POST of the submitted form. (Chrome and Edge both do this correctly.)

Comment 1

[Cree]

This might be identical to the previously fixed bug 100533. Or it could be a related regression.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This is not at all like bug 100533.

This testcase never gets as far as trying to submit the form.  When we are handling the click event on the button, the presshell goes away.  So this block in HTMLButtonElement::PostHandleEvent:

    if (mouseEvent && mouseEvent->IsLeftClickEvent()) {
      // DOMActive event should be trusted since the activation is actually
      // occurred even if the cause is an untrusted click event.
      InternalUIEvent actEvent(true, eLegacyDOMActivate, mouseEvent);
      actEvent.mDetail = 1;

      nsCOMPtr<nsIPresShell> shell = aVisitor.mPresContext->GetPresShell();
      if (shell) {
        nsEventStatus status = nsEventStatus_eIgnore;
        mInInternalActivate = true;
        shell->HandleDOMEventWithTarget(this, &actEvent, &status);
        mInInternalActivate = false;

never dispatches the activate event, and the activate event is what triggers form submission.  Chances are, my proposed fix for bug 548397 would fix this, but is there a reason we're guarding the activate event on having a presshell?  Olli?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, the patch for bug 548397 doesn't help here at all, because the presshell the document has _changes_.  So while OwnerDoc()->GetShell() starts returning non-null, aVisitor.mPresContext->GetPresShell() is still returning null, since the prescontext is torn down.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

The relevant code is super old, way before event dispatch rewrite which happened 10.5 years ago.
I think this is effectively from Bug 125351, even though the event type it deals with is different there.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

I think we could safely not use HandleDOMEventWithTarget, in case we don't have presshell.
Let me look at some code.

Comment 6

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.