Form onsubmit handler called from XUL dialog.

VERIFIED INVALID

Status

()

Core
HTML: Form Submission
P3
minor
VERIFIED INVALID
19 years ago
a year ago

People

(Reporter: hangas, Assigned: Eric Pollmann)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Trying to determine correct behaviour.)

(Reporter)

Description

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

Comment 1

19 years ago
*** This bug has been marked as a duplicate of 11397 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 2

19 years ago
Above auto-generated comment is wrong.  This bug was marked as a duplicate of
bug 11317, not 11397.
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
Component: Autofill → Layout
QA Contact: paulmac
(Reporter)

Comment 3

19 years ago
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.
(Reporter)

Updated

19 years ago
Assignee: morse → __UNKNOWN__
Status: REOPENED → NEW
(Reporter)

Updated

19 years ago
Assignee: __UNKNOWN__ → troy
(Reporter)

Updated

19 years ago
Resolution: DUPLICATE → ---

Updated

19 years ago
Assignee: troy → morse
Component: Layout → other

Comment 4

19 years ago
Why is this assigned to me, I have nothing to do with the wallet code and the
wallet is certainly not layout...

Updated

19 years ago
Assignee: morse → troy
Component: other → Layout

Comment 5

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

Updated

19 years ago
Assignee: troy → pollmann
Component: Layout → Form Submission

Comment 6

19 years ago
That's still not a core layout. People waste so much of my time because they
don't set components correctly...
(Assignee)

Comment 7

19 years ago
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.
(Reporter)

Comment 8

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

Updated

19 years ago
QA Contact: paulmac

Comment 9

19 years ago
paulmac...do you see this on all platforms?
(Assignee)

Updated

19 years ago
Severity: normal → minor
Status: NEW → ASSIGNED
OS: Mac System 8.6 → All
Hardware: Macintosh → All
Whiteboard: Trying to determine correct behaviour.
Target Milestone: M11
(Assignee)

Comment 10

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

Comment 11

19 years ago
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.
(Assignee)

Comment 12

19 years ago
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?

Comment 13

19 years ago
The point you're missing is that wallet is going to be removed from the
on-submit handler (bug 11317).
(Assignee)

Updated

19 years ago
Summary: Wallet dialog comes up in my xul dialogs → Form onsubmit handler called from XUL dialog.
(Assignee)

Comment 14

19 years ago
Okay, I'm changing the summary of this bug to narrow the scope of this problem.
(Assignee)

Comment 15

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → INVALID

Comment 16

18 years ago
Sorry for the spam, changing QA contact.
QA Contact: paulmac → ckritzer

Comment 17

18 years ago
Updating QA contact.
QA Contact: ckritzer → vladimire

Comment 18

17 years ago
Verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.