1909584 - Click event not fired on the parent element if the click is within its child <object> element

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Ksenia Berezina [:ksenia]]

We've got a report in bug1905278, where a popup is not triggered when clicking on licence plates.

I've attached a reduced test case. Looks like the click event is not fired on the parent element (.plateCont) if the click is within its child <object> element (it works if I click outside of the image within the blue border).

It is fired in both Chrome and Safari, but not in Firefox. Not sure which behaviour is correct, so filing this bug to track the difference.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Could you attach the test case?

Comment 2

[Ksenia Berezina [:ksenia]]

Attachment: 1905278.html

Oh sorry, attaching.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It seems that an image of <object> is loaded like as a image document in <iframe>. So, that creates a document boundary, thus events in it are isolated from the parent document.

Smaug, do you know why did we implement <object> as so rather than like an <img>? And do you know who can handle this?

Comment 4

[Robert Longson [:longsonr]]

Attachment: fixed testcase

You'd need to set pointer-events: none; on the object so it doesn't swallow the events. SVG within <object> rather relies on that.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Didn't bug 1595491 change the behavior here.

Comment 6

[Robert Longson [:longsonr]]

Attachment: iframe for comparison

Comment 7

[Robert Longson [:longsonr]]

Chrome with an iframe behaves the same as Firefox and the same as Firefox does for the object tag.

Comment 8

[Robert Longson [:longsonr]]

https://issues.chromium.org/issues/41286601 and https://issues.chromium.org/issues/40740247 may be relevant on the Chrome side

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

nsSubDocumentFrame::BuildDisplayList could check if the relevant browsing context is for image document. I think BrowsingContext::GetSyntheticDocumentContainer() could work there.

Hmm, focus handling is still unclear.

Comment 10

[Ksenia Berezina [:ksenia]]

(In reply to Robert Longson [:longsonr] from comment #4)

You'd need to set pointer-events: none; on the object so it doesn't swallow the events. SVG within <object> rather relies on that.

I'll add an intervention with pointer-events: none; for the affected site for now.

Comment 11

[Andreas Farre [:farre]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #9)

nsSubDocumentFrame::BuildDisplayList could check if the relevant browsing context is for image document. I think BrowsingContext::GetSyntheticDocumentContainer() could work there.

Hmm, focus handling is still unclear.

I poked around a bit, and it doesn't seem to be that easy. We also have mIsInObjectOrEmbed that one could inspect but neither that nor the browsing context has the data expected. This is a hard requirement for ORB, which is what was introduced in:

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #5)

Didn't bug 1595491 change the behavior here.

We load images in a synthetic document that has the same origin as the image to ensure that it isn't possible to start loading arbitrary data into an object or embed element.

I'm guessing that Emilio is the one that would know more?

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1909584 - Don't propagate clicks into synthetic image documents. r=farre!,smaug

This seems to work and seems fairly straight-forward.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

I'm confused, the object element should have all the info, right? A quick patch seems to work, if that seems reasonable I can write a test...

Comment 14

[Andreas Farre [:farre]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #13)

I'm confused, the object element should have all the info, right? A quick patch seems to work, if that seems reasonable I can write a test...

\o/

Yeah, this is exactly what I expect. It's my understanding of nsSubDocumentFrame that's lacking, thanks Emilio!

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/db0d69dbd62b
Don't propagate clicks into synthetic image documents. r=farre

Comment 16

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/47511 for changes under testing/web-platform/tests

Comment 17

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 18

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/db0d69dbd62b