LayoutTests/fullscreen/api/element-ready-check-fullscreen-iframe-child.html - Issue 462103002: Extract "fullscreen element ready check" from requestFullscreen()

Side by Side Diff: LayoutTests/fullscreen/api/element-ready-check-fullscreen-iframe-child.html

Issue 462103002: Extract "fullscreen element ready check" from requestFullscreen() (Closed) Base URL: svn://svn.chromium.org/blink/trunk

Patch Set: Created 6 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 | Annotate | Revision Log

« LayoutTests/fullscreen/api/element-ready-check-fullscreen-element-sibling.html ('K') | « LayoutTests/fullscreen/api/element-ready-check-fullscreen-element-sibling.html ('k') | LayoutTests/fullscreen/api/element-ready-check-iframe-child.html » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 <!DOCTYPE html>

	2 <title>Element ready check for child of a fullscreen iframe</title>

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

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

	5 <script src="../trusted-event.js"></script>

	6 <div id="log"></div>

	7 <iframe><!-- script inserts child here --></iframe>

	8 <script>

	9 // Verify that an iframe can itself go fullscreen, and that this doesn't

	10 // influence the iframe ancestor test of the element ready check.

	11 async_test(function(t)

	12 {

	13 var iframe = document.querySelector("iframe");

	14 document.onfullscreenchange = t.step_func(function()

	15 {

	16 assert_equals(document.fullscreenElement, iframe, "fullscreen element");

	17 var div = document.createElement("div");

	18 iframe.appendChild(div);
	falken 2014/08/13 04:26:57 I might not understand iframes well enough. Why do I might not understand iframes well enough. Why do you appendChild to iframe vs iframe.contentDocument.body? If it's appended to body, can it go fullscreen? philipj_slow 2014/08/13 07:38:36 This is the core of our misunderstanding :) The sp Show quoted text On 2014/08/13 04:26:57, falken wrote: > I might not understand iframes well enough. Why do you appendChild to iframe vs > iframe.contentDocument.body? If it's appended to body, can it go fullscreen? This is the core of our misunderstanding :) The spec change and this test is about a child of the iframe element in the same document, not anything in the iframe's document. The test was originally <iframe><div></div></iframe>, but the HTML parser turns the children of <iframe> into a text node "<div></div>". In order to trigger the case, you'd need to use an XHTML parser or insert children using scripts, as I've done. The children won't be visible. Can I phrase the commit message differently to make this clearer? falken 2014/08/13 07:49:40 Ah, I somewhat suspected that. So wrt the spec tex Show quoted text On 2014/08/13 07:38:36, philipj wrote: > On 2014/08/13 04:26:57, falken wrote: > > I might not understand iframes well enough. Why do you appendChild to iframe > vs > > iframe.contentDocument.body? If it's appended to body, can it go fullscreen? > > This is the core of our misunderstanding :) The spec change and this test is > about a child of the iframe element in the same document, not anything in the > iframe's document. The test was originally <iframe><div></div></iframe>, but the > HTML parser turns the children of <iframe> into a text node "<div></div>". In > order to trigger the case, you'd need to use an XHTML parser or insert children > using scripts, as I've done. The children won't be visible. > > Can I phrase the commit message differently to make this clearer? Ah, I somewhat suspected that. So wrt the spec text "element has no ancestor element whose local name is iframe", an element in an iframe's document is not considered a descendant of the <iframe> element itself? i.e., its root is the iframe document? philipj_slow 2014/08/13 08:12:14 Right, if you click through to the definition of " Show quoted text On 2014/08/13 07:49:40, falken wrote: > On 2014/08/13 07:38:36, philipj wrote: > > On 2014/08/13 04:26:57, falken wrote: > > > I might not understand iframes well enough. Why do you appendChild to iframe > > vs > > > iframe.contentDocument.body? If it's appended to body, can it go fullscreen? > > > > This is the core of our misunderstanding :) The spec change and this test is > > about a child of the iframe element in the same document, not anything in > the > > iframe's document. The test was originally <iframe><div></div></iframe>, but > the > > HTML parser turns the children of <iframe> into a text node "<div></div>". In > > order to trigger the case, you'd need to use an XHTML parser or insert > children > > using scripts, as I've done. The children won't be visible. > > > > Can I phrase the commit message differently to make this clearer? > > Ah, I somewhat suspected that. So wrt the spec text "element has no ancestor > element whose local name is iframe", an element in an iframe's document is > not considered a descendant of the <iframe> element itself? i.e., its root > is the iframe document? Right, if you click through to the definition of "ancestor" in the spec, you'll get to the DOM spec where it's clear that it's all talking about DOM trees, not anything crossing document boundaries. If you have an element in an iframe and follow parentNode up, you'll end up at the iframe's document. falken 2014/08/13 08:45:15 OK, I get it now. I actually had clicked through b Show quoted text On 2014/08/13 08:12:14, philipj wrote: > On 2014/08/13 07:49:40, falken wrote: > > On 2014/08/13 07:38:36, philipj wrote: > > > On 2014/08/13 04:26:57, falken wrote: > > > > I might not understand iframes well enough. Why do you appendChild to > iframe > > > vs > > > > iframe.contentDocument.body? If it's appended to body, can it go > fullscreen? > > > > > > This is the core of our misunderstanding :) The spec change and this test is > > > about a child of the iframe element in the same document, not anything in > > the > > > iframe's document. The test was originally <iframe><div></div></iframe>, but > > the > > > HTML parser turns the children of <iframe> into a text node "<div></div>". > In > > > order to trigger the case, you'd need to use an XHTML parser or insert > > children > > > using scripts, as I've done. The children won't be visible. > > > > > > Can I phrase the commit message differently to make this clearer? > > > > Ah, I somewhat suspected that. So wrt the spec text "element has no ancestor > > element whose local name is iframe", an element in an iframe's document is > > not considered a descendant of the <iframe> element itself? i.e., its root > > is the iframe document? > > Right, if you click through to the definition of "ancestor" in the spec, you'll > get to the DOM spec where it's clear that it's all talking about DOM trees, not > anything crossing document boundaries. If you have an element in an iframe and > follow parentNode up, you'll end up at the iframe's document. OK, I get it now. I actually had clicked through but it wasn't obvious to me.
	19 assert_equals(div.parentNode, iframe, "FIXME bla bla");

	20 assert_equals(div.ownerDocument, document, "FIXME bla blass");
	falken 2014/08/13 04:26:57 FIXMEs :) FIXMEs :) philipj_slow 2014/08/13 07:38:36 Will remove, they're paranoid checks I added while Show quoted text On 2014/08/13 04:26:57, falken wrote: > FIXMEs :) Will remove, they're paranoid checks I added while struggling to understand why my test wasn't working. Turned out that trusted_event was using the wrong document and using iframe.contentDocument.body as the container fixes that, as well as manual testing.
	21 trusted_request(div, iframe.contentDocument.body);

	22 document.onfullscreenchange = t.unreached_func("second fullscreenchange event");

	23 document.onfullscreenerror = t.step_func_done();

	24 });

	25 trusted_request(iframe);

	26 });

	27 </script>

OLD	NEW