I saw a link to http://mozilla.github.com/pdf.js/features/ on Twitter. This test suite considers it green / “success” for data: URL @font-faces to load synchronously.
The test “passes” in Firefox and IE10 and “fails” in Chrome and Opera. I didn’t test Safari. To me, it seems like a bad idea to 1) have any kind of URL load synchronously when there will always be URLs that won’t load synchronously and 2) to treat the existence of special case URL schemes as a feature rather than a bug. There are two main problems with special-casing data: URLs to load synchronously: 1) The behavior of Web apps may change when the address of a resource is changed from http: to data: or vice versa. Changing the data source shouldn’t fundamentally alter the code flow. 2) Having to have synchronous code paths is an annoying design constraint on the browser side when the common http: case requires asynchronous design anyway. The old HTML parser loaded HTML documents from data: URLs synchronously, but only if the documents had no external scripts. The new HTML parser was designed for off-the-main-thread parsing, so you can never start the parser and get the result during one main-thread task. This broke a bunch of unit tests. We were lucky it didn’t break the Web. It would have been really annoying if it had broken the Web and a synchronous code path had had to be introduced just for data: URLs with no external scripts. Can we, please 1) Make the data: URL event pump always spin the event loop before OnStopRequest to prevent anyone from relying on synchronicity and 2) Stop promoting data: URL synchronicity as green / “success” ? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
