Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for form owner #137

Closed
wants to merge 1 commit into from
Closed

Conversation

@mukilan
Copy link
Contributor

mukilan commented May 26, 2015

This is needed for servo/servo#3553.

Review on Reviewable

@Manishearth
Copy link
Member

Manishearth commented May 26, 2015

\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.

@Manishearth

Manishearth May 26, 2015

Member

Perhaps we should avoid crashing here or document the panicky behavior?

This comment has been minimized.

@mukilan

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?

@Manishearth
Copy link
Member

Manishearth commented May 26, 2015

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.

@SimonSapin

SimonSapin May 26, 2015

Member

Could this (and same_home_subtree?) be a default implementation in the trait?

This comment has been minimized.

@mukilan

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.

@SimonSapin

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.

@mukilan

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.

@SimonSapin

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.

@mukilan

mukilan May 26, 2015

Author Contributor

As far as I understand there are two cases where it will be false:

  1. Fragment Parsing case i.e elem.innerHTML = <input type="text" /> . In this case the parser won't call associate_form_owner even when one of elem'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.

  2. An inline script element removes the form element from the Document before the <input> is parsed and form_elem points 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.

@Manishearth
Copy link
Member

Manishearth commented May 27, 2015

Travis fails, btw.

@mukilan
Copy link
Contributor Author

mukilan commented May 29, 2015

Fixed build errors.

@mukilan mukilan force-pushed the mukilan:form_owner branch from a1f7dae to f4d6ee6 Jun 20, 2015
@mukilan mukilan force-pushed the mukilan:form_owner branch from f4d6ee6 to 0e3a25e Jun 20, 2015
@metajack
Copy link
Contributor

metajack commented Jul 29, 2015

@mukilan Did you address @SimonSapin comments as well?

@jdm jdm self-assigned this Jul 29, 2015
@jdm
Copy link
Member

jdm commented Jul 29, 2015

I agreed to look over these changes.

@bors-servo
Copy link
Contributor

bors-servo commented Jul 31, 2015

The latest upstream changes (presumably #151) made this pull request unmergeable. Please resolve the merge conflicts.

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

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.

@mukilan

mukilan Aug 31, 2015

Author Contributor

Hi @hsivonen, @jdm referred me to you for this particular query: is there a specific reason why the spec requires "associating the form owner" to happen before the insertion of the form control element into the tree? Spec

@hsivonen
Copy link

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.

@nox
Copy link
Member

nox commented Sep 13, 2015

@mukilan Is there really no way to keep insert_appropriately() as it is currently? I liked that it relied on inserting failing if there are no parent, instead of needing a has_parent_node() hook.

@nox nox added the web-compat label Sep 13, 2015
bors-servo added a commit that referenced this pull request Feb 6, 2017
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 -->
@canova
Copy link
Member

canova commented Feb 11, 2017

We can close this since it's implemented in #249

@canova canova closed this Feb 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants
You can’t perform that action at this time.