127847 - [FIX]<object>'s not included in form.elements

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect, P1)

Description

[Andrea Aime]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8+) Gecko/20020220
BuildID:    2002022003

www.trenitalia.it provides a traintable search engine.
The query form is provided with default values (current
date and hour), but unfortunately the field placement
is wrong if you choose italian language, values are
not placed in their destination field, but in the next
one 

Reproducible: Always
Steps to Reproduce:
1. www.trenitalia.it
2. enter the english version of the site, form is properly initialized
3. go back
4. enter the italian version of the site
5. the fields are not initialized properly

Actual Results:  ... had to fill the form fields by hand

Expected Results:  to work in Italian as it does in English, French, Espagnol,...
(works in every other language, and works as expected in IE)

Comment 1

[Peter Trudelle]

->html form controls

Comment 2

[Boris Zbarsky [:bzbarsky]]

The site seems to be one single flash thing.  I see no way to navigate it and
see no content (but I have no flash).

Comment 3

[TucsonTester3]

Happens w/ Build: 2002022503  OS: WinME

Comment 4

[rods (gone)]

-->

Comment 5

[John Keiser (jkeiser)]

I have the same problem as Boris.  Can someone provide a link to the portion of
the site with the referenced input fields?

Comment 6

[Andrea Aime]

Try the following URL:
http://62.110.170.238/home/it/index.html

Comment 7

[Phil Schwartau]

This may be an Evangelism issue; see bug 138767

Comment 8

[Boris Zbarsky [:bzbarsky]]

*** Bug 138767 has been marked as a duplicate of this bug. ***

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Minimal testcase that shows the problem

Comment 10

[Boris Zbarsky [:bzbarsky]]

Jst, the problem here is that IE counts any <object> that comes inside a form in
form.elements.  Neither Mozilla nor NS4 does so....  Should we attempt to do
that (a major PITA, if I remember how this stuff works)?  Or call this broken
behavior on the part of IE and evangelize the site?

Comment 11

[John Keiser (jkeiser)]

To muddy the waters further, there is a spec that says the OBJECTs should be
able to submit their values.  In that case it makes *sense* to make OBJECTs submit.

Comment 12

[Boris Zbarsky [:bzbarsky]]

*** Bug 139206 has been marked as a duplicate of this bug. ***

Comment 13

[Fabian Guisset]

Summary: <object> elements are not included in the form.elements HTMLCollection.
This is backwards-compatible with NS4 but not with IE.
According to jkeiser, there is "a" spec that says <object> should be able to
submit their values, however.

Thoughts?

Comment 14

[Johnny Stenback (:jst)]

The DOM spec also defines a form property on object elements (see
nsIDOMHTMLObjectElement) so that seems to indicate that objects are indeed parts
of a form if they're associated with a form. IMO we should follow IE here, NS4x
didn't support object tags at all, so we can't really rely on what it did here.
This shouldn't really be that hard to fix, we'll just need to add the form fluff
to nsHTMLObjectElement and places where form controls are treated specially
(i.e. the html sink).

Comment 15

[Phil Schwartau]

*** Bug 155084 has been marked as a duplicate of this bug. ***

Comment 16

[Phil Schwartau]

*** Bug 160491 has been marked as a duplicate of this bug. ***

Comment 17

[Phil Schwartau]

Helpful comments by Marcus from the duplicate bug 160491:

------- Additional Comment_ #1 From Marcus Campbell 2002-08-01 06:57 ------- 

IE counts OBJECTs as FORM control elements but Mozilla doesn't.
As a result of this, the values being assigned to the INPUTs via
document.forms[0].elements[?].value are being assigned differently.

I don't know enough about the DOM to tell for certain,
but under DOM Level 1 [1] it seems that IE is right.
Under Level 2 [2] it seems Mozilla is right.

[1] http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html#ID-9893177
[2] http://www.w3.org/TR/2001/WD-DOM-Level-2-HTML-20011025/html.html#ID-9893177

Comment 18

[Boris Zbarsky [:bzbarsky]]

IE is in fact right, period.  We are wrong.  The DOM2 HTML candidate rec has an
error (and this error will be fixed now that you have pointed it out; thank you).

Nominating this.  This is going to come up more and more, I think, and should
not be so hard to fix.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Attachment: This should fix it

Comment 20

[John Keiser (jkeiser)]

Comment on attachment 93638 [details] [diff] [review]
This should fix it

Need to rename formControl to isFormControl now that it's a bool.

Pity our plugin interface doesn't support name/value submission.

r=jkeiser

Comment 21

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch with isFormControl

Comment 22

[Boris Zbarsky [:bzbarsky]]

taking

Comment 23

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 93653 [details] [diff] [review]
Patch with isFormControl

rolling r=jkeiser

Comment 24

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I think 1.2alpha is more appropriate milestone.

Comment 25

[Johnny Stenback (:jst)]

Comment on attachment 93653 [details] [diff] [review]
Patch with isFormControl

Not directly related to this patch, but it looks like NS_FORM_NOTSET is defined
in nsIFormControl but it's never used, so do you mind removing that while
you're at it? And NS_FORM_NOTOK is defined too, but isn't used for anything
useful, so that could be removed and the users replaced with NS_ERROR_FAILURE
or somesuch. If you want to file a new bug for this that's ok too.

Hmm, I wonder why nsGenericHTML*FormElement's destructor doesn't do the
SetForm(nsnull) for us? Seems silly to have to sprincle those calls in all
classes that inherit...

sr=jst

Comment 26

[Boris Zbarsky [:bzbarsky]]

New bug 161243 filed on those other issues.  This patch checked in.

Comment 27

[R.K.Aa.]

*** Bug 165498 has been marked as a duplicate of this bug. ***