Open Bug 346627 Opened 14 years ago Updated Last year

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

Categories

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

defect

Tracking

()

REOPENED

People

(Reporter: Waldo, Unassigned)

References

Details

...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.
Should make sure we have tests for this before we ship an alpha...
Blocks: 330677
No longer depends on: 330677
Flags: blocking1.9a1+
See the W3C DOM Level 3 test suite for tests that were used during implementation.
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.
(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.
(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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
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...
(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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Need tests for DOM Level 3 Node.adoptNode → Need tests for adoptNode behaviour not specified in DOM Level 3 Core
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/)
I'm not involved in test automation. davel is the person to talk to.
Can someone (reporter?) please clarify what specific tasks need to be completed in order to close this bug?

Thanks
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.
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?
Flags: blocking1.9-
Whiteboard: [wanted-1.9]
Flags: in-testsuite?
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...
> 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.
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
Assignee: general → nobody
Target Milestone: mozilla1.9alpha1 → ---
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.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.