346627 - Need tests for adoptNode behaviour not specified in DOM Level 3 Core

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P5)

Description

[Jeff Walden [:Waldo]]

...since presumably tests were written during implementation to ensure correct behavior (and thus they shouldn't be difficult to add to the unit tests), and also because code should tested just on general principle.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Should make sure we have tests for this before we ship an alpha...

Comment 2

[Peter Van der Beken [:peterv]]

See the W3C DOM Level 3 test suite for tests that were used during implementation.

Comment 3

[Peter Van der Beken [:peterv]]

And I'd much rather have us improve and extend that testsuite (and run it regularly) than write our own little testsuite for the standard W3C DOM. So IMO this bug is either about adding tests to that suite or WONTFIX.

Comment 4

[Bob Clary [:bc] (inactive)]

(In reply to comment #3)
> And I'd much rather have us improve and extend that testsuite (and run it
> regularly) than write our own little testsuite for the standard W3C DOM. So IMO
> this bug is either about adding tests to that suite or WONTFIX.
> 

We definitely should run the W3C's suite regularly (which I don't currently do), but in the long run we should have our own tests to test behavior which is not part of the standard.

There are about 38 adoptNode tests in the version of the W3C DOM Test Suite available on test.bclary.com.

So, this bug is a WONTFIX and any other tests of the standard which are not already part of the official W3C DOM Test Suite should be contributed there. See http://www.w3.org/DOM/Test/ for information about how to get involved. _I am not interested in working with the DOM TS group_. Been there, done that.

Comment 5

[Peter Van der Beken [:peterv]]

(In reply to comment #4)
> So, this bug is a WONTFIX and any other tests of the standard which are not
> already part of the official W3C DOM Test Suite should be contributed there.
> See http://www.w3.org/DOM/Test/ for information about how to get involved. _I
> am not interested in working with the DOM TS group_. Been there, done that.

Hmm, way back my experience about getting tests corrected (filing bugs at http://www.w3.org/Bugs/) was good, but I'm not sure if it's still the case. I know contributing to the harness was painful, but we can use our own harness but still contribute tests.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So what directory in our source tree can I run "make check" in to run the DOM test suite?  If none, how do we go about making this possible?  The goal is that before 1.9 ships we are running these tests in an automated way on a daily basis.  Might help us with our regression rate.  :(

Also, the standard says nothing about adopting frames into child documents of themselves and we definitely need tests for that...

Comment 7

[Peter Van der Beken [:peterv]]

(In reply to comment #6)
> So what directory in our source tree can I run "make check" in to run the DOM
> test suite?  If none, how do we go about making this possible?  The goal is
> that before 1.9 ships we are running these tests in an automated way on a daily
> basis.  Might help us with our regression rate.  :(

It'd be nice, sure. That's not what this bug is about though. I run them from http://www.propagandism.org/tests/domts/ and there's also http://test.bclary.com/

> Also, the standard says nothing about adopting frames into child documents of
> themselves and we definitely need tests for that...

Ok, but then we need a better summary. My point is that we should avoid rewriting tests that others have already written. We have enough other tests and automation to write/run.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Sure.  I agree that duplicating tests is not what we should aim for.

Could we wiki up the locations of those DOM test suite tests somewhere where we list our tests?

(And for what it's worth, I get an "Encoding error" when I try to use, say, the DOM 1 HTML tests at http://www.propagandism.org/tests/domts/)

Comment 9

[Bob Clary [:bc] (inactive)]

I'm not involved in test automation. davel is the person to talk to.

Comment 10

[Dave Liebreich [:davel]]

Can someone (reporter?) please clarify what specific tasks need to be completed in order to close this bug?

Thanks

Comment 11

[Boris Zbarsky [:bzbarsky]]

This bug is about adding tests for adoptNode behavior not specified by the DOM to some automated test suite that we have.

For the "child document" test we can't use the content unit tests because we need to be able to load subframes, etc (so we need to run in the browser).

I'm not sure what other aspects we need to test outside the DOM test suite.

We should probably have a separate bug on making it easy (possible?) for developers and automated test systems to run the DOM test suite.

Comment 12

[Dave Liebreich [:davel]]

bz, thanks for the clarification.  I suggest the following:

1. Someone (not me) writes tests for adoptNode behavior not specified by the DOM.  I suggest using jsunit as the test harness, and I am willing to help he test writer get this working.

2. Someone (probably me) ensures these tests run for each build (or reasonable subset of each)

Comments?  Volunteers for writing the tests?

Comment 13

[Alex Vincent [:WeirdAl]]

We do have mochitest now, seems perfect for this.

bz: on the child document test (as yet unwritten), I'd like clarification on something.  The adoptNode code explicitly disallows contentDocument.adoptNode() for nodes in the parent document.  That said, what's the Right Way to append a node into an inline frame's document's DOM?  I didn't see a specific comment in bug 330677 suggesting what the DOM user should do...

Comment 14

[Boris Zbarsky [:bzbarsky]]

> The adoptNode code explicitly disallows contentDocument.adoptNode()
> for nodes in the parent document.

No.  That's not the case.  It disallows adoption of any node that is an ancestor of the contentDocument.window.frameElement.  Think about why, for a second.

We should definitely test to make sure that that throws, including testing across multiple levels of frame hierarchy.  We should also test that something no on the ancestor chain can be adopted.

Comment 15

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 16

[Anne (:annevk)]

No longer needed with web-platform-tests.