third_party/WebKit/LayoutTests/custom-elements/spec/adopt-node.html - Issue 2170383002: CustomElements: adopt node

Side by Side Diff: third_party/WebKit/LayoutTests/custom-elements/spec/adopt-node.html

Issue 2170383002: CustomElements: adopt node (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: adoptedCallback should be enqueued when doc is different from oldDocument Created 4 years, 4 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« no previous file with comments | « no previous file | third_party/WebKit/LayoutTests/custom-elements/spec/adopt-node-expected.txt » ('j') | third_party/WebKit/LayoutTests/custom-elements/spec/resources/custom-elements-helpers.js » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 <!DOCTYPE html>

	2 <title>Custom Elements: adopt node</title>

	3 <link rel="help" href="https://dom.spec.whatwg.org/#concept-node-adopt">

	4 <script src="../../resources/testharness.js"></script>

	5 <script src="../../resources/testharnessreport.js"></script>

	6 <script src="resources/custom-elements-helpers.js"></script>

	7 <body>

	8 <script>

	9
	dominicc (has gone to gerrit) 2016/07/25 07:56:14 Delete this blank line. You could separate use str Delete this blank line. You could separate use strict from the comment with one blank line if you like.
	10 'use strict'

	11 // 3. If document is not the same as the oldDocument:
	dominicc (has gone to gerrit) 2016/07/25 07:56:14 Could we add tests for what happens to exceptions Could we add tests for what happens to exceptions originating from adoptedCallback?
	12 // 3.2 For each inclusiveDescendant in node’s shadow-including inclusive desce ndants that is

	13 // a custom element, enqueue a custom element callback reaction with inclusive Descendant,

	14 // callback name "adoptedCallback", and an empty argument list.

	15 test_with_window((w) => {

	16 let invocations = [];

	17 let doc = w.document;

	18 let frame = doc.createElement('iframe');
	dominicc (has gone to gerrit) 2016/07/25 07:56:13 Look at how test_with_window is implemented and do Look at how test_with_window is implemented and do something similar with two windows, something like: promise_test((t) => { Promise.all( create_window_in_test(t), create_window_in_test(t)) .then(([w1, w2]) => { // test code }); }, '...'); Promise.all takes a bunch of promises and resolves when they all resolve, with the results in an array; that thing, [w1, w2] is a destructuring bind that takes the array and pulls it apart into two elements.
	19 doc.body.appendChild(frame);

	20 let iframeWindow = frame.contentWindow;

	21 let iframeDoc = iframeWindow.document;

	22 let a = iframeDoc.createElement('a-a');

	23 iframeDoc.body.appendChild(a);

	24 class X extends iframeWindow.HTMLElement {
	dominicc (has gone to gerrit) 2016/07/25 07:56:13 Be consistent with naming; w is an iframe window t Be consistent with naming; w is an iframe window too, so w/iframeWindow is a bit jarring. Maybe v,w or windowA, windowB or something.
	25 constructor() { super(); }
	dominicc (has gone to gerrit) 2016/07/25 07:56:13 Again--the implicit one is all you need; you can o Again--the implicit one is all you need; you can omit this line. davaajav 2016/08/02 07:21:20 Omitting super(); was resulting in "this" being un Show quoted text On 2016/07/25 at 07:56:13, dominicc wrote: > Again--the implicit one is all you need; you can omit this line. Omitting super(); was resulting in "this" being undefined. I guess we should explicitly call super().
	26 adoptedCallback() { invocations.push(['adopted', this, arguments]); }

	27 }

	28 iframeWindow.customElements.define('a-a', X);

	29 doc.adoptNode(a);

	30 let expected_invocations = [ ['adopted', a, []] ];

	31 assert_array_equals_callback_invocations(invocations, expected_invocations);

	32 }, 'adopting a custom element to the same document should enqueue an adoptedCall back reaction');
	dominicc (has gone to gerrit) 2016/07/25 07:56:14 It might be worth adding a test that adopting or m It might be worth adding a test that adopting or moving an element within the same document does not schedule callbacks. I know, it is odd to test a negative, but we could imagine the predictable bug where we cue that callback on every tree change and not just adoption.
	33 </script>

	34 </body>

OLD	NEW