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)
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•25 years ago
|
||
*** This bug has been marked as a duplicate of 11397 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Comment 2•25 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•25 years ago
|
Assignee: morse → troy
Component: other → Layout
Comment 5•25 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•25 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•25 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•25 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•25 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•25 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•25 years ago
|
||
The point you're missing is that wallet is going to be removed from the on-submit handler (bug 11317).
Assignee | ||
Updated•25 years ago
|
Summary: Wallet dialog comes up in my xul dialogs → Form onsubmit handler called from XUL dialog.
Assignee | ||
Comment 14•25 years ago
|
||
Okay, I'm changing the summary of this bug to narrow the scope of this problem.
Assignee | ||
Comment 15•25 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•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → INVALID
Updated•5 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
•