Open Bug 1306686 Opened 5 years ago Updated 5 months ago

submit form fails if iframe display changed to none

Categories

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

49 Branch
defect

Tracking

()

People

(Reporter: CreeVinicio, Unassigned)

References

Details

Attachments

(1 file)

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.)
This might be identical to the previously fixed bug 100533. Or it could be a related regression.
Depends on: 100533
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?
Component: Untriaged → DOM: Events
Flags: needinfo?(bugs)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
Flags: needinfo?(bugs)
I think we could safely not use HandleDOMEventWithTarget, in case we don't have presshell.
Let me look at some code.
Priority: -- → P3

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.

Severity: normal → S4
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.