Regarding missing DOM features project

[Chintan Gandhi]

Hello All,

Greetings!

We, Chintan Gandhi, Jay Modi and Anshul Jethvani are grad students at NC
State University and will be working on the missing DOM features project.
We would be following this web page
https://github.com/servo/servo/wiki/Missing-DOM-features-project in order
to move forward with the project.

It would be really helpful if you could clarify the project definition and
throw some more light on the DOM features missing in Servo.

The steps that we plan to take are:
1. Build Servo on our machines using the guide mentioned on the above
website.
2. Follow the initial and subsequent steps mentioned on the above site.

Looking forward to making useful contributions.

Regards,
Chintan Gandhi
Jay Modi
Anshul Jethvani
NC State University

[Josh Bowman-Matthews]

Welcome! Could you be more specific about what kind of clarification
you're looking for? What parts of the project description page are
unclear right now?

Cheers,
Josh

[Josh Bowman-Matthews]

Welcome! Could you be more specific about what kind of clarification
you're looking for? What parts of the project description page are
unclear right now?

Cheers,
Josh

On 10/16/19 2:13 PM, Chintan Gandhi wrote:

[Josh Bowman-Matthews]

Welcome! Could you be more specific about what kind of clarification
you're looking for? What parts of the project description page are
unclear right now?

Cheers,
Josh

On 10/16/19 2:13 PM, Chintan Gandhi wrote:

[Josh Bowman-Matthews]

Oh, I just looked at the project page and I could see why the
descriptions of the missing DOM features might be lacking some
description. The issue link for srcdoc iframes was to the wrong issue;
sorry. I have updated the page to point at
https://github.com/servo/servo/issues/4767 instead, which contains some
more helpful links to the specification and explanatory documents.

As for named form getters, given an HTML document like:

<form>
<input id="name">
<input name="password" type="password">
</form>

It is legal to write JS that does something like:

let form = document.querySelector('form');
let the_name = form.name;
let the_password = form.password;

Even though the 'name' and 'password' members are not part of the
HTMLFormElement interface
(https://html.spec.whatwg.org/multipage/forms.html#the-form-element),
the presence of a "named getter" in the interface describes how the web
platform should interpret an arbitrary property name
(https://html.spec.whatwg.org/multipage/forms.html#dom-form-nameditem).
Our engine does not support this yet, so part of this project is
designed to implement it.

Cheers,
Josh

[Josh Bowman-Matthews]

Oh, I just looked at the project page and I could see why the
descriptions of the missing DOM features might be lacking some
description. The issue link for srcdoc iframes was to the wrong issue;
sorry. I have updated the page to point at
https://github.com/servo/servo/issues/4767 instead, which contains some
more helpful links to the specification and explanatory documents.

As for named form getters, given an HTML document like:

<form>
<input id="name">
<input name="password" type="password">
</form>

It is legal to write JS that does something like:

let form = document.querySelector('form');
let the_name = form.name;
let the_password = form.password;

Even though the 'name' and 'password' members are not part of the
HTMLFormElement interface
(https://html.spec.whatwg.org/multipage/forms.html#the-form-element),
the presence of a "named getter" in the interface describes how the web
platform should interpret an arbitrary property name
(https://html.spec.whatwg.org/multipage/forms.html#dom-form-nameditem).
Our engine does not support this yet, so part of this project is
designed to implement it.

Cheers,
Josh

On 10/16/19 2:40 PM, Josh Bowman-Matthews wrote:

[Josh Bowman-Matthews]

Oh, I just looked at the project page and I could see why the
descriptions of the missing DOM features might be lacking some
description. The issue link for srcdoc iframes was to the wrong issue;
sorry. I have updated the page to point at
https://github.com/servo/servo/issues/4767 instead, which contains some
more helpful links to the specification and explanatory documents.

As for named form getters, given an HTML document like:

<form>
<input id="name">
<input name="password" type="password">
</form>

It is legal to write JS that does something like:

let form = document.querySelector('form');
let the_name = form.name;
let the_password = form.password;

Even though the 'name' and 'password' members are not part of the
HTMLFormElement interface
(https://html.spec.whatwg.org/multipage/forms.html#the-form-element),
the presence of a "named getter" in the interface describes how the web
platform should interpret an arbitrary property name
(https://html.spec.whatwg.org/multipage/forms.html#dom-form-nameditem).
Our engine does not support this yet, so part of this project is
designed to implement it.

Cheers,
Josh

On 10/16/19 2:40 PM, Josh Bowman-Matthews wrote:

[Chintan Gandhi]

Hello Josh,

We are currently working on the *srcdoc iframe* issue and have made some
changes to the files: *components/script_traits/lib.rs
<http://lib.rs>,
components/script/dom/webidls/HTMLIFrameElement.webidl,
components/script/script_thread.rs
<http://script_thread.rs> *as specified in the bullet points 2, 3, 4, 5 of
the *initial steps* section on the project site.

How do we test the changes that we have made? Do we simply verify our
changes by running this test: ./mach test-wpt
tests/web-platform-tests/html/semantics/embedded-content/the-iframe-element/srcdoc_process_attributes.html
or
do we need to build servo again?

If we are building servo to test the changes, do we rebuild servo
from scratch or only some specific crates?

If anything else is required to be done or you need more information on our
work, kindly let us know.

Thanking you. Hoping to hear from you soon.

Regards
Chintan Gandhi
NC State University


On Wed, Oct 16, 2019 at 2:49 PM Josh Bowman-Matthews <jo...@joshmatthews.net>
wrote:

> Oh, I just looked at the project page and I could see why the
> descriptions of the missing DOM features might be lacking some
> description. The issue link for srcdoc iframes was to the wrong issue;
> sorry. I have updated the page to point at
> https://github.com/servo/servo/issues/4767 instead, which contains some
> more helpful links to the specification and explanatory documents.
>
> As for named form getters, given an HTML document like:
>
> <form>
> <input id="name">
> <input name="password" type="password">
> </form>
>
> It is legal to write JS that does something like:
>
> let form = document.querySelector('form');
> let the_name = form.name;
> let the_password = form.password;
>
> Even though the 'name' and 'password' members are not part of the
> HTMLFormElement interface
> (https://html.spec.whatwg.org/multipage/forms.html#the-form-element),
> the presence of a "named getter" in the interface describes how the web
> platform should interpret an arbitrary property name
> (https://html.spec.whatwg.org/multipage/forms.html#dom-form-nameditem).
> Our engine does not support this yet, so part of this project is
> designed to implement it.
>

> Cheers,
> Josh
>

> On 10/16/19 2:40 PM, Josh Bowman-Matthews wrote:

[Chintan Gandhi]

> Cheers,
> Josh
>

> On 10/16/19 2:40 PM, Josh Bowman-Matthews wrote:

[Cheng You Bai]

Hi Chintan,

I think I can help to answer some questions

> How do we test the changes that we have made? Do we simply verify our
changes by running this test: ./mach test-wpt
tests/web-platform-tests/html/semantics/embedded-content/the-iframe-element/srcdoc_process_attributes.html
or do we need to build servo again?

First of all, if you just clone the Servo repo and build it successfully,
then run `./mach test-wpt` with the `srcdoc_process_attributes.html` test.

You will see the test result says "TEST_END: Test TIMEOUT. Subtests passed
0/3. Unexpected 0".
There are no subtests passed but there's no unexpected results.

For wpt tests, there's a folder
<https://github.com/servo/servo/tree/master/tests/wpt/metadata> to record
current test status.
For the srcdoc test, its metadata file is at
tests/wpt/metadata/html/semantics/embedded-content/the-iframe-element/srcdoc_process_attributes.html.ini
<https://github.com/servo/servo/blob/master/tests/wpt/metadata/html/semantics/embedded-content/the-iframe-element/srcdoc_process_attributes.html.ini>
.

So, if you implement the srcdoc correctly and try to run test-wpt with it,
you should get unexpected PASS for the `srcdoc_process_attributes` test.

and that's how you can verify your implementation is correct or not.

> If we are building servo to test the changes, do we rebuild servo from
scratch or only some specific crates?

When you do any code change with the Servo codebase, you will need to build
again to get a new executable Servo.
But, if you've built the project before, it will not be rebuilt from
scratch; instead, it will get the benefit of incremental compilation from
Rust so it will only rebuild those parts you've changed.


Hope I help you to understand the questions clearly 🙏

Cheers,
CYBAI

> > Cheers,
> > Josh
> >

> > On 10/16/19 2:40 PM, Josh Bowman-Matthews wrote:

> _______________________________________________
> dev-servo mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>

[Cheng You Bai]

> > Cheers,
> > Josh
> >

> > On 10/16/19 2:40 PM, Josh Bowman-Matthews wrote:

[Chintan Gandhi]

Hi Josh,

Greetings!

We are currently working on the named getter implementation by
following the spec and the steps you listed on the project page:
https://github.com/servo/servo/wiki/Missing-DOM-features-project.

There a couple of questions related to the SupportedPropertyNames method
implementation:

1. What should be the type of elements in the sourced names enum? The
spec says to set the source as id, name, past based on the type of
attribute it has. Would these be elements of enum be strings or of some
other data type? Currently, the enum is defined as follows:
2. // source types enum
enum SourcedNamesStates {
"id",
"name",
"past",
}
3. How do we fetch the value of id or name attribute? We cannot seem to
find a way to do it.

Hoping to hear from you soon. Thank you. Have a happy Thanksgiving.

Regards
Chintan Gandhi
NC State University

>> Cheers,
>> Josh
>>

>> On 10/16/19 2:40 PM, Josh Bowman-Matthews wrote:

[Chintan Gandhi]

>> Cheers,
>> Josh
>>

>> On 10/16/19 2:40 PM, Josh Bowman-Matthews wrote:

[Josh Bowman-Matthews]

Great question! I recommend representing it like:

enum SourcedNameSource {
Id,
Name,
Past(Duration)
}

struct SourcedName {
name: String,
element: DomRoot<Element>,
source: SourcedNameSource,
}

This will allow you to access the values that are always present as
named fields of the entry, and then use the `match` language feature to
access the values that can change depending on what kind of source it is.

For fetching the id and name attribute values, you will need the
Element::get_string_attribute API
(https://doc.servo.org/script/dom/element/struct.Element.html#method.get_string_attribute),
and you will pass a value like `&local_name!("id")`.

Cheers,
Josh

[Josh Bowman-Matthews]

Great question! I recommend representing it like:

enum SourcedNameSource {
Id,
Name,
Past(Duration)
}

struct SourcedName {
name: String,
element: DomRoot<Element>,
source: SourcedNameSource,
}

This will allow you to access the values that are always present as
named fields of the entry, and then use the `match` language feature to
access the values that can change depending on what kind of source it is.

For fetching the id and name attribute values, you will need the
Element::get_string_attribute API
(https://doc.servo.org/script/dom/element/struct.Element.html#method.get_string_attribute),
and you will pass a value like `&local_name!("id")`.

Cheers,
Josh

On 11/28/19 2:07 AM, Chintan Gandhi wrote:

[Josh Bowman-Matthews]

Great question! I recommend representing it like:

enum SourcedNameSource {
Id,
Name,
Past(Duration)
}

struct SourcedName {
name: String,
element: DomRoot<Element>,
source: SourcedNameSource,
}

This will allow you to access the values that are always present as
named fields of the entry, and then use the `match` language feature to
access the values that can change depending on what kind of source it is.

For fetching the id and name attribute values, you will need the
Element::get_string_attribute API
(https://doc.servo.org/script/dom/element/struct.Element.html#method.get_string_attribute),
and you will pass a value like `&local_name!("id")`.

Cheers,
Josh

On 11/28/19 2:07 AM, Chintan Gandhi wrote:

[Josh Bowman-Matthews]

Great question! I recommend representing it like:

enum SourcedNameSource {
Id,
Name,
Past(Duration)
}

struct SourcedName {
name: String,
element: DomRoot<Element>,
source: SourcedNameSource,
}

This will allow you to access the values that are always present as
named fields of the entry, and then use the `match` language feature to
access the values that can change depending on what kind of source it is.

For fetching the id and name attribute values, you will need the
Element::get_string_attribute API
(https://doc.servo.org/script/dom/element/struct.Element.html#method.get_string_attribute),
and you will pass a value like `&local_name!("id")`.

Cheers,
Josh

On 11/28/19 2:07 AM, Chintan Gandhi wrote:

[Chintan Gandhi]

Hi Josh,

Sorry to bother you on a Sunday.

We have added the enum and struct modifications as mentioned above. Listed
below are some issues which we are unclear about:

*1.* As mentioned on the project page, we need to create a *vector*
*(SourcedName,
DomRoot<HTMLElement>)* by iterating over *self.controls* member. This
*vector* is to be used as an *ordered list of structs (string, element,
source)* as specified in step 1 of the spec
<https://html.spec.whatwg.org/multipage/forms.html#the-form-element:supported-property-names>,
right?

*2.* Currently, we have considered the *vector (SourcedName,
DomRoot<HTMLElement>)* as the *ordered list of structs (string, element,
source)* that we will return as the method output. This snippet iterates
over all the control elements and checks if it is a listed element. We
change the source based on the attribute the child element has and push the
entry to the *vector*. Kindly review the code and let us know if there are
any issues in the code.














* let controls = self.controls.borrow(); // borrow immutable
`controls` member for child in controls.iter() { if
child.is_listed_element() { if
child.has_attribute(&local_name!("id")) { let entry =
SourcedName {name: child.get_string_attribute(&local_name!("id")), element:
child, source: Id}; vec.push(entry, child);
} else if child.has_attribute(&local_name!("name")) {
let entry = SourcedName {name:
child.get_string_attribute(&local_name!("name")), element: child, source:
Name}; vec.push(entry, child); }
} }*

For step 3 related to image buttons, the function call *if
child.is_listed_element()* is replaced by *if
child.get_string_attribute(&local_name!("type")) == "image" **.*

*3.* In which function do we add the entries in the map and how do we
implement the past names map exactly? We read through the issue but
couldn't understand exactly the way in which we will implement it.

These are a lot of questions but we would greatly appreciate your
inputs. Thank you.

Regards
Chintan Gandhi
NC State University

On Thu, Nov 28, 2019 at 10:31 AM Josh Bowman-Matthews <jo...@joshmatthews.net>
wrote:

> Great question! I recommend representing it like:
>
> enum SourcedNameSource {
> Id,
> Name,
> Past(Duration)
> }
>
> struct SourcedName {
> name: String,
> element: DomRoot<Element>,
> source: SourcedNameSource,
> }
>
> This will allow you to access the values that are always present as
> named fields of the entry, and then use the `match` language feature to
> access the values that can change depending on what kind of source it is.
>
> For fetching the id and name attribute values, you will need the
> Element::get_string_attribute API
> (
> https://doc.servo.org/script/dom/element/struct.Element.html#method.get_string_attribute),
>
> and you will pass a value like `&local_name!("id")`.
>
> Cheers,
> Josh
>
> On 11/28/19 2:07 AM, Chintan Gandhi wrote:

[Chintan Gandhi]

Regards
Chintan Gandhi
NC State University

On Thu, Nov 28, 2019 at 10:31 AM Josh Bowman-Matthews <jo...@joshmatthews.net>
wrote:

> Great question! I recommend representing it like:
>
> enum SourcedNameSource {
> Id,
> Name,
> Past(Duration)
> }
>
> struct SourcedName {
> name: String,
> element: DomRoot<Element>,
> source: SourcedNameSource,
> }
>
> This will allow you to access the values that are always present as
> named fields of the entry, and then use the `match` language feature to
> access the values that can change depending on what kind of source it is.
>
> For fetching the id and name attribute values, you will need the
> Element::get_string_attribute API
> (
> https://doc.servo.org/script/dom/element/struct.Element.html#method.get_string_attribute),
>
> and you will pass a value like `&local_name!("id")`.
>
> Cheers,
> Josh
>
> On 11/28/19 2:07 AM, Chintan Gandhi wrote:

[Josh Bowman-Matthews]

1. Using the struct/enum combo that I suggested in the previous email,
you would only need a vector of SourcedName, since the element is
included in the struct. You are correct that this corresponds with the
description of the specification for `sourced names`.

2. That code snippet looks like it's got the right idea, yes. As for the
image candidates, you can use `if child.is::<HTMLImageElement>()`.

3. Uncommenting the named getter in the HTMLFormElement WebIDL yields
two new methods that need to be implemented in htmlformelement.rs -
supported_property_names and NamedGetter. These correspond with two
operations - getting the list of all meaningful property names for a
HTMLFormElement object, and getting the value of a specific property
name. Adding an entry to the `past names map` happens in step 5 of
"determine the value of a named property", which will be implemented in
NamedGetter.

The past names map is a map (ie. HashMap) from a DOMString (which holds
an element's id/name value) to Dom<Element>. At the point when
NamedGetter is invoked with a string value and there is a unique form
element whose name matches the provided string, you will add an entry to
the past names map to represent that this mapping exists. This allows
the following JS code to succeed (given this HMTL: <form><input
id="first"></form>)

let form = document.querySelector('form');

let elem = document.querySelector('#first');
console.log(form.first === elem); // expected: true
elem.id = "second";
console.log(form.first === elem); // expected: true
console.log(form.first === form.second); // expected: true

(I created
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7498 to
demonstrate this, with console.log replaced with w() to use the provided
in-page log).

So both NamedGetter and SupportedPropertyNames are expected to read from
the past names map, but only NamedGetter is expected to modify it. Does
that answer your question?

Cheers,
josh