Overview: TWO beforeload events are fired by <object> elements instead of ZERO when their fallback content is used. Steps to Reproduce: Open the attached HTML file. It contains an instance of YouTube's standard embedding code, and alerts for beforeload events. Expected result: The <object> tag is ignored because it has neither the type nor the data attribute. The enclosed <embed> tag is used and fires a beforeload event. Total events fired: 1. Actual result: The <object> tag is ignored because it has neither the type nor the data attribute. The enclosed <embed> tag is used and fires a beforeload event. BUT, the unused <object> tag also fires two beforeload events. Total events fired: 3. Tested in OS X 10.6.4 with WebkKit 6533.18.5, r71367. Notes: The same happens with any other kind of fallback content (<video>, <img>, ...)
Created attachment 73162 [details] An HTML file that reproduces the bug
Note that I'm getting entirely different behavior with Safari 5.0.2: the movie apparently just loads from the object element, and there is just one beforeload event. With a debug build: ASSERTION FAILED: !m_inBeforeLoadEventHandler (/Users/ap/Safari/OpenSource/WebCore/html/HTMLObjectElement.cpp:282 virtual void WebCore::HTMLObjectElement::updateWidget(bool))
Yeah I forgot to mention that. Safari 5.0.2 and earlier treat the <object>/<embed> combination in a special way, but that was fixed a few weeks ago in the nightlies (now the <embed> is just like any other fallback). But the problem is already there for other kind of fallback content. I'm attaching an example with <video> fallback.
Created attachment 73166 [details] Another example with <video> fallback
I believe this is a dupe of https://bugs.webkit.org/show_bug.cgi?id=44575, although this technically is documenting two separate issues: 1) beforeload is fired twice on object tags (dupe of 44575). 2) beforeload is fired on object tags that will never fire a load event (new bug AFAIK). For #2, I'm not sure whether its correct to fire a beforeload event for objects with fallback content that that we know we won't load. That warrants its own discussion that is separate from #1, IMO. *** This bug has been marked as a duplicate of bug 44575 ***