1220774 - Provide a flag or the original target to retargeted events by PositionedEventTargeting.cpp

Status: RESOLVED INCOMPLETE

(Core :: DOM: Events, defect)

Description

[Julien Wajsberg [:julienw]]

In bug 1210201 we discovered that the logic introduced in bug 1181763 could have bad side-effects in very specific situations, but that are completely legit.

Therefore I wonder if we could have a specific flag on the event to warn about this situation, or even the original target before it's been retargeted (I know `originalTarget` is already used in XUL environments).

See [1] for the code used to workaround the issue in this situation.

[1] https://github.com/julienw/gaia/blob/52388cd14a7a69e4299f61dc141cedc4f4c0f941/apps/calendar/js/views/hour_double_tap.js#L53-L56

Kats, what do you think ?

Comment 1

[Kartikaya Gupta (email:[e-mail])]

It's not clear to me what you're asking for here. It sounds like you want web content to be able to tell when the content retargeting happened so that web content can undo the effects and recover the original target. Is that right? If so I would suggest instead that we implement bug 1091889 so that touch events don't get retargeted, and then you can use the target from the touch event rather than the click event. How does that sound?

Comment 2

[Julien Wajsberg [:julienw]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #1)
> It's not clear to me what you're asking for here. It sounds like you want
> web content to be able to tell when the content retargeting happened so that
> web content can undo the effects and recover the original target. Is that
> right? 

Yep.

The goal is to give the web developers the power to decide what they want to do with this event.

If we standardize this it would even be cross-platform.

> If so I would suggest instead that we implement bug 1091889 so that
> touch events don't get retargeted, and then you can use the target from the
> touch event rather than the click event. How does that sound?

This would kind of work. But in bug 1210201 it would still not be that easy to fix with this.
And this difference between touch and mouse events is IMO too hidden, could lead to cross-browser incompatibilities and simply could change over time.

However with such a property we could change the implementation like we wanted.

Maybe it's better to have this in pointer events though, maybe we don't want to evolve the old legacy API now. But I would find this definitely valuable.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

(In reply to Julien Wajsberg [:julienw] from comment #2)
> (In reply to Kartikaya Gupta (email:[e-mail]) from comment #1)
> > It's not clear to me what you're asking for here. It sounds like you want
> > web content to be able to tell when the content retargeting happened so that
> > web content can undo the effects and recover the original target. Is that
> > right? 
> 
> Yep.
> 
> The goal is to give the web developers the power to decide what they want to
> do with this event.
> 
> If we standardize this it would even be cross-platform.

I guess this is an option but I would like to see how much support there is from other browser implementors before proceeding.

> > If so I would suggest instead that we implement bug 1091889 so that
> > touch events don't get retargeted, and then you can use the target from the
> > touch event rather than the click event. How does that sound?
> 
> This would kind of work. But in bug 1210201 it would still not be that easy
> to fix with this.
> And this difference between touch and mouse events is IMO too hidden, could
> lead to cross-browser incompatibilities and simply could change over time.

Last time I checked other browsers also had this same behavior; presumably we can try to get it added to the spec to reduce the chances of it changing over time. That's one of the reasons I suggested it - it will make us more compatible rather than adding a new thing.

Comment 4

[Julien Wajsberg [:julienw]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #3)
> (In reply to Julien Wajsberg [:julienw] from comment #2)
> > (In reply to Kartikaya Gupta (email:[e-mail]) from comment #1)
> > > It's not clear to me what you're asking for here. It sounds like you want
> > > web content to be able to tell when the content retargeting happened so that
> > > web content can undo the effects and recover the original target. Is that
> > > right? 
> > 
> > Yep.
> > 
> > The goal is to give the web developers the power to decide what they want to
> > do with this event.
> > 
> > If we standardize this it would even be cross-platform.
> 
> I guess this is an option but I would like to see how much support there is
> from other browser implementors before proceeding.

yes this makes sense.

> > > If so I would suggest instead that we implement bug 1091889 so that
> > > touch events don't get retargeted, and then you can use the target from the
> > > touch event rather than the click event. How does that sound?
> > 
> > This would kind of work. But in bug 1210201 it would still not be that easy
> > to fix with this.
> > And this difference between touch and mouse events is IMO too hidden, could
> > lead to cross-browser incompatibilities and simply could change over time.
> 
> Last time I checked other browsers also had this same behavior; presumably
> we can try to get it added to the spec to reduce the chances of it changing
> over time. That's one of the reasons I suggested it - it will make us more
> compatible rather than adding a new thing.

Same behavior but possibly not with the same radius values, for example...

Comment 5

[Kartikaya Gupta (email:[e-mail])]

(In reply to Julien Wajsberg [:julienw] from comment #4)
> > Last time I checked other browsers also had this same behavior; presumably
> > we can try to get it added to the spec to reduce the chances of it changing
> > over time. That's one of the reasons I suggested it - it will make us more
> > compatible rather than adding a new thing.
> 
> Same behavior but possibly not with the same radius values, for example...

That's true, they probably have different heuristics for finding a nearby target. But on the other hand, we probably wouldn't want to put the specific heuristics in a spec because some heuristics might be appropriate for some devices and not others.

Comment 6

[Julien Wajsberg [:julienw]]

Yes, that's exactly what I mean :)

That's why I think the web developer should know that event retargeting happened :) I think this is the best way to be cross-browser and cross-devices.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Fair enough. I'm still on the fence about whether or not it's a good idea to expose this - my feeling is that if the browser can't do this transparently so that it "just works" then maybe it shouldn't do it at all. But feel free to bring it up on the W3C mailing list. Since this proposal affects mouse events which are covered by the UI events spec [1] I think the www-dom mailing list would probably the one to start the conversation on.

[1] http://www.w3.org/TR/DOM-Level-3-Events/

Comment 8

[Julien Wajsberg [:julienw]]

Note: I see some Gaia uses explicitOriginalTarget...

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Even though the PositionedEventTargeting code is in layout/base/ this is conceptually a DOM events feature request.

Comment 10

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

We wouldn't implement this for web content before this is well defined in some spec.

(And we should try to get rid of exposing .explicitOriginalTarget and .originalTarget to web content, but those have very little to do with this, since those are about event retargeting in DOM level and this is about hit testing.)

But for now this is incomplete. Please file a spec bug if you want something like this in the web platform.


However, if there is a good reason to expose to the chrome only, we could add [ChromeOnly] property to the events. If that is wanted, please reopen this bug.