Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upImplement support for form owner #137
Conversation
|
\o/ ITS HAPPENING! |
| @@ -230,8 +241,9 @@ impl TreeSink for Sink { | |||
|
|
|||
| fn append_before_sibling(&mut self, | |||
| sibling: Handle, | |||
| child: NodeOrText<Handle>) -> Result<(), NodeOrText<Handle>> { | |||
| let (mut parent, i) = unwrap_or_return!(get_parent_and_index(sibling), Err(child)); | |||
This comment has been minimized.
This comment has been minimized.
Manishearth
May 26, 2015
Member
Perhaps we should avoid crashing here or document the panicky behavior?
This comment has been minimized.
This comment has been minimized.
mukilan
May 26, 2015
Author
Contributor
The comment in the trait definition documents the fact that append_before_sibling will only be called when has_parent(sibling) is true and hence it should never fail. Is this not enough?
|
r? @kmcallister (I'll go through this anyway, but I'm not nearly familiar with parsing to sign off on it) |
| } | ||
|
|
||
| fn associate_with_form(&mut self, _target: Handle, _form: Handle) { | ||
| } |
This comment has been minimized.
This comment has been minimized.
SimonSapin
May 26, 2015
Member
Could this (and same_home_subtree?) be a default implementation in the trait?
This comment has been minimized.
This comment has been minimized.
mukilan
May 26, 2015
Author
Contributor
I did this because I thought owned_dom and rc_dom were just examples and don't implement all features (form owner support in this case). For real clients wouldn't we want to enforce the implementation of form owners? Or is it optional?
This comment has been minimized.
This comment has been minimized.
SimonSapin
Jul 29, 2015
Member
It can be useful to parse HTML in a "real" application that is not a browser doesn't support form submission.
This comment has been minimized.
This comment has been minimized.
mukilan
Jul 30, 2015
Author
Contributor
That makes sense. I'll change them to be default implementations.
| @@ -61,6 +61,10 @@ pub trait TreeSink { | |||
| /// Do two handles refer to the same node? | |||
| fn same_node(&self, x: Self::Handle, y: Self::Handle) -> bool; | |||
|
|
|||
| /// Are two handles present in the same tree | |||
| /// https://html.spec.whatwg.org/multipage/infrastructure.html#home-subtree | |||
This comment has been minimized.
This comment has been minimized.
SimonSapin
May 26, 2015
Member
I don’t understand how this can ever be false. Could the doc-comment give an example?
This comment has been minimized.
This comment has been minimized.
mukilan
May 26, 2015
Author
Contributor
As far as I understand there are two cases where it will be false:
-
Fragment Parsing case i.e
elem.innerHTML = <input type="text" />. In this case the parser won't callassociate_form_ownereven when one ofelem's ancestor is a form element . But the form owner will be set when the DocumentFragment's children are inserted into the context element, after parsing. -
An inline script element removes the form element from the Document before the
<input>is parsed andform_elempoints to a form element that is not an ancestor of the input tag (the wierd table case)
I must admit that I don't fully understand case 1. In particular, why does the fragment parser algorithm initialize the parser's form element pointer to the closest form element ancestor of the context element? (https://html.spec.whatwg.org/multipage/syntax.html#parsing-html-fragments:form-element-pointer step 11)
I'm not sure if there are other cases that I might have missed.
|
Travis fails, btw. |
|
Fixed build errors. |
|
@mukilan Did you address @SimonSapin comments as well? |
|
I agreed to look over these changes. |
|
|
| Some((idx, last_table)) => { | ||
| // Try inserting "inside last table's parent node, immediately before last table" | ||
| if self.sink.has_parent_node(last_table.clone()) { | ||
| BeforeSibling(last_table.clone()) |
This comment has been minimized.
This comment has been minimized.
jdm
Aug 10, 2015
Member
We've lost the fallback behaviour from https://github.com/servo/html5ever/pull/137/files#diff-3f339094e126866dfc7763b9a1d54beaL232, haven't we?
This comment has been minimized.
This comment has been minimized.
jdm
Aug 10, 2015
Member
Nevermind, I've read the other comments and I understand why this change is appropriate.
|
|
||
| let form = self.form_elem.as_ref().unwrap().clone(); | ||
| if self.sink.same_home_subtree(tree_node, form.clone()) { | ||
| self.sink.associate_with_form(elem.clone(), form) |
This comment has been minimized.
This comment has been minimized.
hsivonen
commented
Sep 9, 2015
|
@mukilan, I'm not sure. It seems to me that @Hixie found it more convenient to handle parser-specific stuff in the parser's "create an element for a token" and to stipulate an exception to the insertion algorithm than to define parser-specific stuff in the insertion algorithm itself. There could be another reason that I fail to see, though. |
|
@mukilan Is there really no way to keep |
Implement support for form owner This is rebased version of #137. Fixed merge conflicts, updated to current codebase and addressed some comments. But there are still some todo's needs to be addressed. Servo side of this changes is currently WIP. Opening this for early feedbacks. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/html5ever/249) <!-- Reviewable:end -->
|
We can close this since it's implemented in #249 |
mukilan commentedMay 26, 2015
This is needed for servo/servo#3553.