225565 - [FIX]Browser ignores form fields with input type "article"

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Wayne Woods]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031111 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031111 Firebird/0.7+

If the form has a text box that is set to input type of "article" then the
browser won't treat it as a proper form element. (I hope I'm using the right
terminology here).

This becomes obvious on the page http://203.166.10.94/overdrive.htm
If you fill out the competition form and try to "Submit your guess" on Seamonkey
or Firebird, it tells you that you haven't answererd "question 4_4", which is
the "Daytime Phone Number:"field. Also, if you use the tab key to switch between
fields, it works for the other fields, but skips the phone number field entirely
and goes back to the location bar.

The phone number field has its input type set to "article". I've produced a
reduced test case that proves it's the input type that's the problem. I'll
submit that as an attachment next.

For all I know, "article" might just be a bad input type and Mozilla might be
right in ignoring it. However the web page form works fine in both Safari and
Internet Explorer, so I thought it was worth reporting.

Reproducible: Always

Steps to Reproduce:
1.Go to http://203.166.10.94/overdrive.htm
2.Fill out all the fields on the "Overdrive" competition form and click "Submit
your guess"

Actual Results:  
It creates a dialog box saying you have to answer question 4_4

Expected Results:  
Should have submitted the form correctly

Comment 1

[Wayne Woods]

Attachment: Displays the input type="article" form problem

Load the attachment in your browser. Use the tab key to switch between fields.
You'll note that it ignores the third field, which has an input type of
"article". In Safari and IE, it doesn't ignore this field.

Comment 2

[Emmanuel Bourg]

What's this input type ? The standard types defined in HTML 4.01 and XTHML 1.0
are text, password, checkbox, radio, submit, reset, file, hidden, image and button.

http://www.w3.org/TR/html4/interact/forms.html#input-control-types

Comment 3

[Wayne Woods]

Then I guess it may be Mozilla just ignoring a bad type then. I'm not a HTML
coder.. I just submitted it because it worked in the other two browsers. Thanks :)

Comment 4

[Emmanuel Bourg]

I'm not sure the error is due to the type attribute. Even with a wrong type an
input elements works like a "text" field and the value is submitted properly.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Confirming bug.  This is due to code in the ESM that relies on the type
attribute instead of the actual form control type...

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Comment 7

[Boris Zbarsky [:bzbarsky]]

I should just take this.

Note that to reproduce "buttons, radio buttons..." needs to be unchecked in your
keyboard nav preferences (default setting on Mac, which is why Wayne is seeing
the problem).

Comment 8

[Peter Van der Beken [:peterv]]

Comment on attachment 135415 [details] [diff] [review]
Proposed fix

I bet there's other places that do this :-/.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Actually, the only place lxr shows offhand that uses GetType(string) is in
wallet, which probably can't access nsIFormControl anyway.

Patch checked in.

Comment 10

[Wayne Woods]

Wow, I report a bug, go to sleep, wake up and it's fixed. Thanks Boris! :)
Yeah, that keyboard nav. preference was switched off (must be by default). In
Firebird I can't even find an equivalent pref to switch on.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Well, peterv's lightning-fast review helped.  ;)

Comment 12

[Wayne Woods]

OK, thanks Peter, too, then :)

Comment 13

[Wayne Woods]

Confirmed fixed on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.6b) Gecko/20031114 Firebird/0.7+ . Thanks again, guys!