Re: [whatwg] about:blank synchronicity
On 1/27/10 3:53 AM, Ian Hickson wrote: Would it have other problems? Are there cases other than navigation where about:blank being synchronous is detectable? (I couldn't find any.) I'm not sure what you're asking here... I mean, like, does it matter if about:blank is synchronous in, or in CSS in a url(), or something like that? Oh. I don't think about:blank should be special in any of those contexts, no. -Boris
Re: [whatwg] about:blank synchronicity
On Wed, 13 Jan 2010, Henri Sivonen wrote: > > This has turned out to be a test suite compatibility problem with > about:blank. Mozilla's Mochitest test suite has tests that depend > about:blank in iframe having a document.body immediately upon iframe > insertion to document without a trip through the event loop. > > At first look, this seems like a clear case: the spec says that > about:blank is navigated to synchronously. However, this is not what > Gecko does (with the old parser). The parser isn't even invoked in this case in the spec actually. Just creating an and inserting in the document synchronously creates a Document object with the right elements, without parsing anything. > Gecko (with the old parser) has these two characteristics: > 1) If a browsing context that has no document object is asked to return > its document object, an about:blank-like DOM is generated into the > browsing context synchronously. This is compatible with what the spec requires. > 2) When a browsing context is navigated to about:blank, a task is > posted to the task queue. When that task is run, about:blank is parsed > to completion during the single task queue task. I've changed the spec to make actual navigation to about:blank async. On Wed, 13 Jan 2010, Maciej Stachowiak wrote: > > I am not sure what the exact constraints are, but I believe the > following are required: > > - Accessing the document of a frame with missing, empty or about:blank > src has to always give you an HTML document with a body, even if there > hasn't been a chance for the event loop to run. > - A newly created iframe with missing, empty or about:blank src has to have an > accessible document right away, without even cycling the event loop. I believe this is guaranteed in the spec, at least for newly created browsing contexts. > There are at least three particular scenarios that are relevant here: > > 1) Some sites document.write or otherwise poke at the DOM of their > about:blank frames or iframes in inline script, without waiting for the > load event or anything. > > 2) Some sites load multiple frames, yet one expects to poke at the > other's DOM during its load. Since load order is not guaranteed, this > would be a race condition, if the not-yet-loaded frame had no DOM, but > synchronous about:blank lets such sites muddle on through. Before we had > sufficiently synchronous loading of the initial empty frame document, we > actually encountered sites like this that broke in Safari but not IE or > Firefox. > > 3) Some sites make a new iframe element using DOM calls in an event > handler, and expect it to have an empty document that's immediately > ready for DOM manipulation, without any intervening returns to the event > loop. Those should all work, since they all can access the initially created document (the one that doesn't involve a parser). On Wed, 13 Jan 2010, Boris Zbarsky wrote: > On 1/13/10 11:52 AM, Maciej Stachowiak wrote: > > Question: if you generate a document on the fly via early access, does > > it get replaced when the about:blank task actually completes? > > Yes. More precisely, the document is replaced, but the inner window is > not (the latter required for pages that set variables on the window > before the load is complete). This is in fact required by the spec, too: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#create-a-document-object > I believe Gecko treats a document.write the same way it treats a > location set in terms of network traffic: any loads that are happening > in that navigation context are canceled. This is not specific to > pending about:blank loads. For example, if you insert an iframe with > some http URI as @src into the DOM and then document.write into it > immediately, then the http load will be canceled. Nothing special about > about:blank here. This is currently step 8 of the document.open() algorithm. > > > > > function doTheTest() { > alert(window.frames[0].document.documentElement.textContent); > } > > > > > > var doc = window.frames[0].document; > doc.documentElement.appendChild(doc.createTextNode("foopy")); > > > > > This alerts empty string in Gecko (and doesn't show the string "foopy" > in the iframe). The "" URL resolves to the same as "./", which in IE (though no other browsers) means loading up an actual page. Currently the spec agrees with IE on this, though there is an open issue about whether to change this that I haven't looked at yet. If we have src="about:blank", though, the spec says that the gets a Document object with its created synchronously, and the navigation is never done; the DOM manipulation is thus persistent (and the test alerts "foopy") On Thu, 14 Jan 2010, Henri Sivonen wrote: > > Which leads to the question: Are there known Web compat constraints on > navigating a non-framed browsing
Re: [whatwg] about:blank synchronicity
On Jan 15, 2010, at 12:05, Henri Sivonen wrote: > I've located a Mozilla test case that seems to depend on the event loop task > mapping of data: URL loads > (http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/chrome/test_bug533845.xul). This was most likely a misdiagnosis. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] about:blank synchronicity
On 1/18/10 6:02 PM, Ian Hickson wrote: In case it wasn't clear from the relevant Gecko thread, I would personally be fine with this. That said, would "initial about:blank load" only include (no src at all), or also or also? I suspect it doesn't matter that much, actually, but would welcome confirmation. It would include any browsing context creation, including, e.g. window.open(), pointing to an HTML file before the HTML file is loaded, etc. That wasn't quite my question. If I have an in my source, would there be a sync about:blank document creation followed by an about:blank load? Or would the @src value just get ignored if it's "about:blank"? -Boris
Re: [whatwg] about:blank synchronicity
On Mon, 18 Jan 2010, Boris Zbarsky wrote: > On 1/13/10 4:56 PM, Ian Hickson wrote: > > The spec currently distinguishes between the initial about:blank load > > (creation of a new browsing context), which actually doesn't involve > > navigation, and navigating to about:blank. > > > > It seems like simply making the first one synchronous, but making the > > latter asynchronous, would satisfy your use case. Would other vendors be > > ok with this? > > In case it wasn't clear from the relevant Gecko thread, I would personally be > fine with this. That said, would "initial about:blank load" only include > (no src at all), or also or also src="about:blank"/>? I suspect it doesn't matter that much, actually, but > would welcome confirmation. It would include any browsing context creation, including, e.g. window.open(), pointing to an HTML file before the HTML file is loaded, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] about:blank synchronicity
On 1/13/10 4:56 PM, Ian Hickson wrote: The spec currently distinguishes between the initial about:blank load (creation of a new browsing context), which actually doesn't involve navigation, and navigating to about:blank. It seems like simply making the first one synchronous, but making the latter asynchronous, would satisfy your use case. Would other vendors be ok with this? In case it wasn't clear from the relevant Gecko thread, I would personally be fine with this. That said, would "initial about:blank load" only include (no src at all), or also or also ? I suspect it doesn't matter that much, actually, but would welcome confirmation. Would it have other problems? Are there cases other than navigation where about:blank being synchronous is detectable? (I couldn't find any.) I'm not sure what you're asking here... -Boris
Re: [whatwg] about:blank synchronicity
On 1/15/10 5:05 AM, Henri Sivonen wrote: I've located a Mozilla test case that seems to depend on the event loop task mapping of data: URL loads (http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/chrome/test_bug533845.xul). Er... it does? Where? Does anyone happen to have data on whether the Web already depends on data: URLs that don't block the parser loading as a single event loop task? I don't think the web depends on data: URLs at all, really, so I would guess "no". -Boris
Re: [whatwg] about:blank synchronicity
I've located a Mozilla test case that seems to depend on the event loop task mapping of data: URL loads (http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/chrome/test_bug533845.xul). Does anyone happen to have data on whether the Web already depends on data: URLs that don't block the parser loading as a single event loop task? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] about:blank synchronicity
On Jan 13, 2010, at 19:08, Boris Zbarsky wrote: > On 1/13/10 11:52 AM, Maciej Stachowiak wrote: >> It seems like if Gecko truly wanted to make about:blank synchronous, it >> should be possible simply by special-casing its load and performing a >> series of DOM calls right then and there, without ever involving the >> parser. > > Turns out this actually breaks at least some things that expect > (asynchronous) onload events and the like for the about:blank load, at least > when Henri tried doing exactly that. I _think_ this was for cases where an > explicit about:blank was listed as the src. I did it after absent or empty src had been defaulted to about:blank: so empty, absent and explicit about:blank were all covered. Also, I did it for all browsing contexts--not just iframes. The most obvious test case that broke was testing history navigation in a top-level browsing context (i.e. created in XUL--not as an iframe). It is plausible that my attempt to fix was too naïve and additional tweaking of the events could work. (It is indeed very likely that my attempted fix was too naïve.) Also, making the change only for frames but not for top-level browsing contexts might be worth considering if changing this for top-level browsing contexts is too disruptive. Which leads to the question: Are there known Web compat constraints on navigating a non-framed browsing context to about:blank via window.open() or window.location.href in a previously open()ed window? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] about:blank synchronicity
On Wed, 13 Jan 2010, Henri Sivonen wrote: > > Gecko (with the old parser) has these two characteristics: > 1) If a browsing context that has no document object is asked to return > its document object, an about:blank-like DOM is generated into the > browsing context synchronously. > 2) When a browsing context is navigated to about:blank, a task is > posted to the task queue. When that task is run, about:blank is parsed > to completion during the single task queue task. The spec currently distinguishes between the initial about:blank load (creation of a new browsing context), which actually doesn't involve navigation, and navigating to about:blank. It seems like simply making the first one synchronous, but making the latter asynchronous, would satisfy your use case. Would other vendors be ok with this? Would it have other problems? Are there cases other than navigation where about:blank being synchronous is detectable? (I couldn't find any.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] about:blank synchronicity
On 1/13/10 11:52 AM, Maciej Stachowiak wrote: Question: if you generate a document on the fly via early access, does it get replaced when the about:blank task actually completes? Yes. More precisely, the document is replaced, but the inner window is not (the latter required for pages that set variables on the window before the load is complete). It seems like if Gecko truly wanted to make about:blank synchronous, it should be possible simply by special-casing its load and performing a series of DOM calls right then and there, without ever involving the parser. Turns out this actually breaks at least some things that expect (asynchronous) onload events and the like for the about:blank load, at least when Henri tried doing exactly that. I _think_ this was for cases where an explicit about:blank was listed as the src. There is probably also various non-web code that expects various network events (start of network load, end of network load, etc) and the like in this circumstance... We could try to hunt it all down and change it, but it's not exactly a trivial endeavor. If it's necessary, it's necessary, of course. - Accessing the document of a frame with missing, empty or about:blank src has to always give you an HTML document with a body, even if there hasn't been a chance for the event loop to run. Agreed. This is an absolute requirement. - A newly created iframe with missing, empty or about:blank src has to have an accessible document right away, without even cycling the event loop. Yes. 1) Some sites document.write or otherwise poke at the DOM of their about:blank frames or iframes in inline script, without waiting for the load event or anything. Yep. I believe Gecko treats a document.write the same way it treats a location set in terms of network traffic: any loads that are happening in that navigation context are canceled. This is not specific to pending about:blank loads. For example, if you insert an iframe with some http URI as @src into the DOM and then document.write into it immediately, then the http load will be canceled. Nothing special about about:blank here. 2) Some sites load multiple frames, yet one expects to poke at the other's DOM during its load. Since load order is not guaranteed, this would be a race condition, if the not-yet-loaded frame had no DOM, but synchronous about:blank lets such sites muddle on through. Before we had sufficiently synchronous loading of the initial empty frame document, we actually encountered sites like this that broke in Safari but not IE or Firefox. 3) Some sites make a new iframe element using DOM calls in an event handler, and expect it to have an empty document that's immediately ready for DOM manipulation, without any intervening returns to the event loop. Fully agreed on these use cases. One question is whether in case 3 the sites expect the same DOM to be available later on. It seems to be in Safari and Opera. It's not in Gecko at the moment, as expected based on code inspection. Testcase: function doTheTest() { alert(window.frames[0].document.documentElement.textContent); } var doc = window.frames[0].document; doc.documentElement.appendChild(doc.createTextNode("foopy")); This alerts empty string in Gecko (and doesn't show the string "foopy" in the iframe). -Boris
Re: [whatwg] about:blank synchronicity
On Jan 13, 2010, at 5:22 AM, Henri Sivonen wrote: The HTML5 parser in Gecko loads all streams very asynchronously. That is, to loading a stream never finishes from the same event queue task that starts the load. This is fine for loading HTTP streams, since the general expectation is that the process of loading something from the network makes multiple trips through the event loop. This has turned out to be a test suite compatibility problem with about:blank . Mozilla's Mochitest test suite has tests that depend about:blank in iframe having a document.body immediately upon iframe insertion to document without a trip through the event loop. At first look, this seems like a clear case: the spec says that about:blank is navigated to synchronously. However, this is not what Gecko does (with the old parser). Gecko (with the old parser) has these two characteristics: 1) If a browsing context that has no document object is asked to return its document object, an about:blank-like DOM is generated into the browsing context synchronously. 2) When a browsing context is navigated to about:blank, a task is posted to the task queue. When that task is run, about:blank is parsed to completion during the single task queue task. As a result, in Gecko (with the old parser enabled), asking for document.body of an iframe never returns null even if navigation to about:blank isn't complete. If the navigation hasn't completed yet, a body element generated by #1 above is returned. If navigation has completed, a body element generated by #2 above is returned. Since #2 happens as a single task, it's never possible to see a browsing context that is being navigated to about:blank in an intermediate state of the parse. (The HTML5 parser breaks this by making the state where the document object has been created by nothing has been tokenized yet observable.) Question: if you generate a document on the fly via early access, does it get replaced when the about:blank task actually completes? It seems like if Gecko truly wanted to make about:blank synchronous, it should be possible simply by special-casing its load and performing a series of DOM calls right then and there, without ever involving the parser. Now, consider the following demo: http://hsivonen.iki.fi/test/bz-about-blank-data.html This makes it look like Opera and Safari were doing what the spec says and navigating the iframe synchronously to about:blank. (The use of the data: URL scheme makes the demo not work in IE.) However, if the data: URL is changed to an http: URL, Safari no longer appears to navigate to about:blank synchronously: http://hsivonen.iki.fi/test/bz-about-blank.html I think your test case demonstrates something that we would consider a bug. Though I am not sure what exactly is happening internally that causes it. We certainly make our best effort to load about:blank synchronously, though there may be unusual circumstances where that doesn't happen. Let's take a more careful look: http://hsivonen.iki.fi/test/bz-about-blank-check-body.html Opera indeed navigates to about:blank synchronously. IE doesn't support window.stop, so let's try testing without it: http://hsivonen.iki.fi/test/bz-about-blank-check-body-no-stop.html IE7 neither does IE 8 doesn't appear to actually navigate synchronously. So it appears that only Opera is doing what the spec requires. Since IE, Firefox or Safari aren't doing what the spec requires, what the spec requires can't be exactly necessary for Web compat. What's the actual Web compat constraint when it comes to navigating to about:blank (including loading about:blank as the initial page into a newly-inserted iframe)? I am not sure what the exact constraints are, but I believe the following are required: - Accessing the document of a frame with missing, empty or about:blank src has to always give you an HTML document with a body, even if there hasn't been a chance for the event loop to run. - A newly created iframe with missing, empty or about:blank src has to have an accessible document right away, without even cycling the event loop. There are at least three particular scenarios that are relevant here: 1) Some sites document.write or otherwise poke at the DOM of their about:blank frames or iframes in inline script, without waiting for the load event or anything. 2) Some sites load multiple frames, yet one expects to poke at the other's DOM during its load. Since load order is not guaranteed, this would be a race condition, if the not-yet-loaded frame had no DOM, but synchronous about:blank lets such sites muddle on through. Before we had sufficiently synchronous loading of the initial empty frame document, we actually encountered sites like this that broke in Safari but not IE or Firefox. 3) Some sites make a new iframe element using DOM calls in an event handler, and expect it to have