474867 - EMBED nodes with no wmode or wmode="window" don't propagate mouse events

Status: RESOLVED DUPLICATE of bug 329547

(Core :: DOM: Events, defect)

Description

[Jorge Villalobos [:jorgev] (he/him)]

Attachment: Minimal HTML test case

I've tested this on Windows, Mac and Linux, with Firefox 3.0 and 3.1b2, and it happens on Windows and Linux, but not on Mac.

On Windows and Linux, an EMBED node that doens't have a wmode attribute or has it set to "window" will not propagate mouse events such as "click", "mouseup" and "mousedown". That is, setting handlers in or around these nodes will not capture any events when they occur on the EMBED nodes, not even if the listener is added for the "capturing" phase.

I'm attaching a testcase that demonstrates this by adding a red border around an EMBED node when it's clicked. Here are my test results ("Yes" means the border was drawn):

                 Windows XP  Mac OS X  Ubuntu Linux
No wmode             No         Yes       No
wmode="window"       No         Yes       No
wmode="opaque"       Yes        Yes       Yes  
wmode="transparent"  Yes        Yes       Yes

I'm not sure which is the expected behavior, but I hope it's the one for Mac OS X, which makes the most sense to me. Having this inconsistency is a problem for extension developers that add special behavior when clicking on the content, so it'd be great that it was fixed.

Comment 1

[carglue a t ya hoo do tcom]

I remember this particular mozilla regression vividly, since I had to implement a horrendous fix in our addon to work around the issue.

It involved checking if we needed strip off the outer OBJECT tag from inner EMBED tag--just to hear the click or other events.  This involved modifying the document's DOM source (as soon as the DOMContentLoaded event fired) to physically strip off the outer "OBJECT" parent DOM node (needed only for IE) and reconnect the inner EMBED node to its (the removed OBJECT's) parent node.

Just horrific.  Yet, this approach was fraught with still further issues because:
- some web sites generate their DOM content via JavaScript and/or Ajax logic, so we also had to listen for DOMNodeInserted events to watch for any embedded object that was dynamically added to the DOM (after the original page load)
- there were issues with some Flash sites because the act of detaching and reattaching the EMBED object sometimes caused a Gecko reflow and a reload of the (partially loaded) Flash object, which may have already begun loading some of its own resources or setting state, so this sometimes didn't play well on the flash server end.

Yes, this is a particularly nasty issue that we've had to deal with for several years now and it still remains to be fixed.  There are other bugs open for this issue--something about the outer OBJECT tag blocking propagation of the inner EMBED tag.  Unfortunately I don't recall the specific numbers.  Also, the technique web developers use to wrap the EMBED tag with an OBJECT tag to make it compatible between both IE and Mozilla-based browsers just happens to be the standard.  Yay.

Comment 2

[carglue a t ya hoo do tcom]

Sorry, I should clarify one thing:
We also had to modify the wmode of the source web page document as this bug describes as part of the fix, but in addition to that, we found that if the EMBED tag was not wrapped with an OBJECT tag, we could just detach and reattach the EMBED TAG to its same parent (to force gecko to reflow the changes--which we required because we had to modify the incoming source page dynamically).  But if the EMBED tag was wrapped by an OBJECT tag, we had to physically strip off the OBJECT tag and attach the EMBED tag to the OBJECT's parent, otherwise the events would still not propagate.  Ask me how fun this was.  :)

Comment 3

[carglue a t ya hoo do tcom]

Found it:  https://bugzilla.mozilla.org/show_bug.cgi?id=329547