This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17005 - <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
Summary: <embed>: "Whenever an embed element that was not potentially active becomes p...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 blocker
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-08 21:20 UTC by contributor
Modified: 2013-04-02 01:00 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2012-05-08 21:20:05 UTC 
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
Comment 1 contributor 2012-07-18 17:26:26 UTC 
This bug was cloned to create bug 18146 as part of operation convergence.
Comment 2 Ian 'Hixie' Hickson 2012-08-25 16:46:53 UTC 
(also "is then" should be "must then", surely...)
Comment 3 Ian 'Hixie' Hickson 2012-10-31 00:15:45 UTC 
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?
Comment 4 Boris Zbarsky 2012-11-26 05:15:49 UTC 
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...
Comment 5 Ian 'Hixie' Hickson 2012-11-26 20:51:26 UTC 
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.
Comment 6 contributor 2013-02-07 19:40:11 UTC 
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
Comment 7 Ian 'Hixie' Hickson 2013-02-07 19:40:23 UTC 
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.
Comment 8 Boris Zbarsky 2013-02-08 17:00:50 UTC 
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...
Comment 9 Ian 'Hixie' Hickson 2013-02-09 06:04:37 UTC 
bz: You bet. I'll reopen this to remind me to do it.
Comment 10 Ian 'Hixie' Hickson 2013-04-01 21:37:33 UTC 
bz: Filed https://bugzilla.mozilla.org/show_bug.cgi?id=856816
Comment 11 Boris Zbarsky 2013-04-02 01:00:25 UTC 
Ian, thanks!