won't login into zoho.com because of missing named getter on HTMLFormElement

[plasmoidian]

Servo reports an error in the authentication. Sometimes it freezes afterwards. Windows build.

[jdm]

The console shows

ERROR:script::dom::bindings::error: Error at https://accounts.zoho.com/login?servicename=ZohoHome&hidesignup=true&&hide_secure=true&css=https://www.zoho.com/css/prd-sign.css:384:21 frm.lid is undefined

This is part of the code that is executed during the form submission; we are missing the named getter on HTMLFormElement which allows referencing form elements by their id.

[jdm]

https://html.spec.whatwg.org/multipage/forms.html#dom-form-nameditem

[jdm]

Code: components/script/dom/htmlformelement.rs, components/script/dom/webidls/HTMLFormElement.webidl
Tests: ./mach test-wpt tests/wpt/web-platform-tests/html/semantics/forms/the-form-element/

[ghost]

I'd like to try to implement this. Not very experienced, but I've got the summer cleared up.

[jdm]

Please do! Ask questions about anything that's unclear!

[ghost]

I can't seem to find past names map in the htmlformelement.rs file. Do you know where I might find it? The following lines seem to be what I want but I'm not entirely sure since it implements only to step 2.2 of this spec.

[jdm]

We do not implement the past names map yet. Adding support for it is required for the named getter.

[jdm]

If you have questions about how to implement the past names map, I am happy to answer them :)

[ghost]

@jdm I'm not quite sure how to implement this. I understand from the documentation that the map is member variable in htmlformelement and that the bindings will handle the lifetimes of the object and not its implementation. So I figure that all the info that I'd need sits on the rust side, but I don't know how I'm to keep track of the changes made on each of the children of htmlformelement. Should I modify htmlelement to alert it's parent on a name change or is there something I'm missing?

[ghost]

Think I may have found what I'm looking for with the attribute list within elements. Would love your input if I'm still way off base.

[jdm]

The more I read the specification's description of the past names map, the weirder it becomes. It appears that you do not need to track changes to the children of a form element (as sensible as that might seem!). Instead, the specification describes behaviour that allows this script to show undefined for the input element's original id.

Let's look at all of the references to the "past names map" in the specification (click on the bold text to see the list for yourself):

• the definition
• including all of the entries from the map in the list of supported property names (this algorithm corresponds to the SupportedPropertyNames method that is required when a named getter operation is present in a WebIDL interface)
• determining which object to return for a given supported property name (this would be in the implementation of the NamedGetter method that is required when a named getter operation is present in a WebIDL interface)
• adding an entry to the map as part of the previous algorithm
• removing an entry from the map if it no longer belongs to the given form element

All of these are lazy activities - the map only ever is modified during the process of returning the list of supported property names. This means that this algorithm returns the list of names of elements that currently belong to this form, and the list of names that were known last time the list was created. Am I making sense? In short, I would be surprised to see many (if any) changes outside of htmlformelement.rs, since HTMLFormElement has a controls member which can give us the list of controls belonging to that form element.

[ghost]

Thanks so much! This makes a lot more sense.

[ghost]

Simple question. In step two from here it mentions the image object. For what I've written I've assumed it means an image button, as I think a regular image wouldn't be of much use for form submission. So I'm wondering if this is correct or if I should swap it to use the html image?

[jdm]

I agree that it's confusing! Given that the previous step is very explicit about image buttons, I recommend following the instructions as written. I'll see if I can figure out why they care about img elements in that algorithm.

[ghost]

I went looking through standard and found that usemap, a member variable of img, is considered palpable content. So I'm guessing a form might use it to choose between options.

[jdm]

@WholeGrainGoats Are you still working on this?

[ghost]

Yes, I started debugging this Monday. Sorry for taking so long. I do have a question, though. Is this ./mach test-wpt tests/wpt/web-platform-tests/html/semantics/forms/the-form-element/ enough to test fully or should I add some more test cases to it? I say that because I ran it at the beginning, before I uncommented the corresponding WebIDL and had written the code, but the tests all succeeded.

[jdm]

Yes, since we have lists of expected results like https://dxr.mozilla.org/servo/source/tests/wpt/metadata/html/semantics/forms/the-form-element/form-nameditem.html.ini which currently expect failures for all tests related to the named getter. Those should end up showing "PASS expected FAIL" once your changes take effect.

[jdm]

@WholeGrainGoats Are you still working on this?

[ghost]

I attempted to find related test cases and Bugzilla reports for Firefox.

The only test case I could find is: https://dxr.mozilla.org/comm-central/source/mozilla/dom/html/test/forms/test_form_named_getter_dynamic.html

I found three Bugzilla reports that are related:

• https://bugzilla.mozilla.org/show_bug.cgi?id=377413
• https://bugzilla.mozilla.org/show_bug.cgi?id=307415
• https://bugzilla.mozilla.org/show_bug.cgi?id=100499

[paavininanda]

Hi, @jdm! I would like to work on this issue.

[pshaughn]

Lack of a named getter makes WPT html/semantics/forms/form-submission-0/constructing-form-data-set.html fail (slightly confusingly, since the button is named "submit" and expected to shadow the built-in .submit without a comment explaining what's going on)