17005 2012-05-08 21:20:05 +0000 <embed>: "Whenever an embed element that was not potentially active becomes potentially active, and whenever a potentially active embed element's src attribute is set, changed, or removed, and whenever a potentially active embed element's type attribute i 2013-04-02 01:00:25 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#mime-types P3 blocker Unsorted 1 contributor ian bzbarsky ian johns mike contributor oldest_to_newest 67505 0 contributor 2012-05-08 21:20:05 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#mime-types Complete: http://www.whatwg.org/c#mime-types Comment: <embed>: "Whenever an embed element that was not potentially active becomes potentially active, and whenever a potentially active embed element's src attribute is set, changed, or removed, and whenever a potentially active embed element's type attribute is set, changed, or removed, the appropriate set of steps from the following is then applied" — that should be done async via a task, i think (at a minimum in the case of the 'being rendered' state changing, anyway). Posted from: 216.239.45.4 by ian@hixie.ch User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/536.10 (KHTML, like Gecko) Chrome/20.0.1123.4 Safari/536.10 70759 1 contributor 2012-07-18 17:26:26 +0000 This bug was cloned to create bug 18146 as part of operation convergence. 72771 2 ian 2012-08-25 16:46:53 +0000 (also "is then" should be "must then", surely...) 77481 3 ian 2012-10-31 00:15:45 +0000 Testing Chrome here is pointless, it even fails tests like: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1874 Firefox and Opera seem to resolve the URL in the queued task, not before: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1875 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1876 But it seems they give that task a lower priority than timeout tasks (you can even increase the timeout to more than 10ms and still have it take effect, though anything larger than about 25ms is too much on my machine for Opera, and greater than 150ms is too large for me in Firefox): http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1877 I don't really understand that last part. bz: Any input here? Does Gecko really just wait for a over a hundred milliseconds before deciding to actually figure out what's going on with the <embed> element? 78814 4 bzbarsky 2012-11-26 05:15:49 +0000 I would guess that the issue is that the fetch of the src is not done until after the Flash plug-in has been instantiated for that <embed>. And that won't happen until at least after CSS box construction, whatever IPC is involved in setting up the plug-in, whatever thumb-twiddling Flash itself decides to do, and so forth. It's a bit surprising to me if that takes 100+ms, but not surprising enough to rule out... 78866 5 ian 2012-11-26 20:51:26 +0000 Well I don't see this leading to much in the way of interop, but it's just plugins, so I can't say I'm overly concerned. I guess I can try to spec that you resolve the URL that late, since it's what browsers are doing anyway. It'll only break people doing really weird things. 82709 6 contributor 2013-02-07 19:40:11 +0000 Checked in as WHATWG revision r7703. Check-in comment: Better match reality, however weird it is. http://html5.org/tools/web-apps-tracker?from=7702&to=7703 82710 7 ian 2013-02-07 19:40:23 +0000 bz: Actually it can't be that the flash plugin is instantiated before the URL is resolved, because until you fetch the URL, you've no idea what plugin you have to instantiate. In fact on my Gecko instance on this (much faster) computer, Flash isn't installed and I still get different results based on whether the timeout is 30ms (new base URL affects result) or 40ms (new base URL doesn't affect result). Anyway, I've tried to fix this, as per the diff above. 82762 8 bzbarsky 2013-02-08 17:00:50 +0000 Ian, mind filing a Gecko bug for your issue so we can actually sort out what's going on there? Something here is very very fishy... 82831 9 ian 2013-02-09 06:04:37 +0000 bz: You bet. I'll reopen this to remind me to do it. 85329 10 ian 2013-04-01 21:37:33 +0000 bz: Filed https://bugzilla.mozilla.org/show_bug.cgi?id=856816 85353 11 bzbarsky 2013-04-02 01:00:25 +0000 Ian, thanks!