Closed
Bug 11967
Opened 26 years ago
Closed 26 years ago
Form onsubmit handler called from XUL dialog.
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
INVALID
M11
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.
Comment 1•26 years ago
|
||
*** This bug has been marked as a duplicate of 11397 ***
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
Comment 2•26 years ago
|
||
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.
Why is this assigned to me, I have nothing to do with the wallet code and the
wallet is certainly not layout...
Updated•26 years ago
|
Assignee: morse → troy
Component: other → Layout
Comment 5•26 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.
That's still not a core layout. People waste so much of my time because they
don't set components correctly...
Assignee | ||
Comment 7•26 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.
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.
Assignee | ||
Updated•26 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•26 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•26 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•26 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•26 years ago
|
||
The point you're missing is that wallet is going to be removed from the
on-submit handler (bug 11317).
Assignee | ||
Updated•26 years ago
|
Summary: Wallet dialog comes up in my xul dialogs → Form onsubmit handler called from XUL dialog.
Assignee | ||
Comment 14•26 years ago
|
||
Okay, I'm changing the summary of this bug to narrow the scope of this problem.
Assignee | ||
Comment 15•26 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•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → INVALID
Updated•6 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•