Closed Bug 11967 Opened 25 years ago Closed 25 years ago

Form onsubmit handler called from XUL dialog.

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

VERIFIED INVALID

People

(Reporter: hangas, Assigned: pollmann)

Details

(Whiteboard: Trying to determine correct behaviour.)

The wallet dialog is comming up in the mail compose window asking me if I want to
put the values of this form in my wallet.  I do not ever want to see this dialog
from any of my xul windows or dialogs.
*** This bug has been marked as a duplicate of 11397 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Above auto-generated comment is wrong.  This bug was marked as a duplicate of
bug 11317, not 11397.
Status: RESOLVED → REOPENED
Component: Autofill → Layout
QA Contact: paulmac
morse just told me that the only way the wallet code could get involved is if it
was being called from the onsubmit handler.  This seems wrong to me.  morse is
fixing some wallet issues by eliminating this dialog that pops up and replacing
it with a menu item that the user must choose.  However, it seems like we should
not be calling the onsubmit handler from the html:input inside of a xul dialog
every time return is hit.
Assignee: morse → __UNKNOWN__
Status: REOPENED → NEW
Assignee: __UNKNOWN__ → troy
Resolution: DUPLICATE → ---
Assignee: troy → morse
Component: Layout → other
Why is this assigned to me, I have nothing to do with the wallet code and the
wallet is certainly not layout...
Assignee: morse → troy
Component: other → Layout
The wallet code is not what is concerning Paul, rather layout's on-submit
handler is.  And since wallet is registered to receive the on-submit handler, it
gets called in.

Paul feels that on-submit should not be called in the first place and so he is
reporting this bug against layout to prevent his xul form firing on-submit.
Assignee: troy → pollmann
Component: Layout → Form Submission
That's still not a core layout. People waste so much of my time because they
don't set components correctly...
Is is the case that nobody will ever want to register as an observer for form
submission inside of XUL?  If this is true, I can make this check in
nsFormFrame.

Another solution might be for the wallet code, to check to see if the form that
is being submitted is inside of XUL.
I am not the right person to ask about form submission.  It seems wrong to me to

be doing anything related to form submission from a xul dialog just because

someone hits return in an html:input field.  If we can get confirmation from one

of our XUL masters then this could be removed.
QA Contact: paulmac
paulmac...do you see this on all platforms?
Severity: normal → minor
Status: NEW → ASSIGNED
OS: Mac System 8.6 → All
Hardware: Macintosh → All
Whiteboard: Trying to determine correct behaviour.
Target Milestone: M11
Paul, can you attach the XUL that is causing the onSubmit handler to be fired?

I think there are at least three solutions to this problem.

1) We can change the logic that handles Enter key presses for all text inputs
(html and xul).

I looked over the logic that handles Enter presses for text elements.  We
currently take the simple approach of submitting the form whenever Enter is
pressed in an <html:input type=text>.  This is the same approach taken by IE
5.0, and I think that it makes a good deal of sense as a keyboard shortcut.
Enter keypresses have no function inside of an <html:input> element as they can
only contain one line of text, why not enable them to save the user time in
submitting the form? (in the XUL dialog case, this submit could be trapped to
"Okay" the dialog).

In Nav 4.x, we took a different approach.  In forms that only contained one text
element, we also submitted the form on an Enter press.  However if there was
more than one <input> element, we would change focus to the next element rather
than submitting the form.  I think that this is a reasonable behaviour, but the
Tab key already performs this function.  Also, having a key that changes
behaviour based on the content may be confusing to the user.

2) We can change the logic that handles Enter key presses in text inputs for xul
text inputs only.

This seems to be what you are advocating.  Taking this approach, we should
consider that this will provide an inconsistent user interface.  When Enter is
pressed in a text input on a forms on the webit will submit the form.  When
Enter is pressed in a text input in a XUL dialog nothing will happen.

3) Disable wallet as a listener for form submission inside XUL dialogs.

With this approach, we can still maintain a consistent user interface (submit
the form/close the dialog when Enter is pressed), and also don't confuse the
user with the wallet popup.

I think this is the approach we should take.  It solves the problem that caused
this bug to be file ("Wallet dialog comes up in my xul dialog") and it also does
not prevent us from later deciding to use Enter keypress to trigger form
submisstion to close a XUL dialog.


I am not a usability expert, so I'm CC'ing German on this to see if he has any
additional comments...
Wallet *will* be changed to not be a listener for form submission in all cases
(xul as well as web page).  That is the focus of another bug report (11317).  So
let's leave that out of the solution here.

Paul wasn't happy when I told him that because he felt that the on-submit
handler should not even be called in this case.  If he is wrong in feeling this
way, then close the bug down as invalid.  If he is correct, then fix it so that
xul does not trigger on submit.  But leave wallet out of it because that is
not what Paul is complaining about.
I wasn't aware of this bug.  From what I read of that bug report though, wallet
would still want to be a listener for form submission for general web pages,
right?  The only change I read Kevin asking for in bug 11317 is to add a
checkbox to the wallet dialog (which will still come up when a form is
submitted) to disable wallet.  I added a comment to bug 11317 to this effect.

If this bug (11967) is going to be changed to "Enter causes form submission",
let me reiterate that I don't think that it should be fixed.  And, if I do not
fix the "Enter causes form submission" bug, and even if bug 11317 *is* fixed, we
still have the problem that is the summary of this bug report, "Wallet dialog
comes up in my xul dialogs".

I could be missing something here, but I'm trying to get a sense of what the
right thing to do is.  I don't think we should turn off the "Enter causes form
submission" feature.  I don't think we should turn off "Form submission causes
the wallet dialog to come up" feature.  I do think that we should turn off
wallet inside of XUL dialogs.  Paul?  Steve?  German?
The point you're missing is that wallet is going to be removed from the
on-submit handler (bug 11317).
Summary: Wallet dialog comes up in my xul dialogs → Form onsubmit handler called from XUL dialog.
Okay, I'm changing the summary of this bug to narrow the scope of this problem.
Since the wallet dialog is no longer going to be popping up inside of XUL
dialogs (see Steve's comment).  Is there any reason to not notify people who
register for form submission?  If not, I'm going to mark this bug invalid.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → INVALID
Sorry for the spam, changing QA contact.
QA Contact: paulmac → ckritzer
Updating QA contact.
QA Contact: ckritzer → vladimire
Verifying
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.