All users were logged out of Bugzilla on October 13th, 2018

submit form fails if iframe display changed to none

NEW
Unassigned

Status

()

P3
normal
2 years ago
2 years ago

People

(Reporter: CreeVinicio, Unassigned)

Tracking

49 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8796647 [details]
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.)
(Reporter)

Comment 1

2 years ago
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.

Comment 4

2 years ago
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)

Comment 5

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

Updated

2 years ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.