936905 - Defect - Touch events on chrome elements that overlay zoomed content go to content

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Jim Mathies [:jimm]]

Attachment: draw.html

STR:

1) load test case
2) zoom in the blue are on the right
3) tap on the overlay back button

result: taps show up in the canvas drawing app

Comment 1

[Jim Mathies [:jimm]]

This doesn't appear to be related to event sending or apzc. Appears to be some sort of a event targeting bug.

Comment 2

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

Hmm, how do we paint the back button? Is it somehow part of the content?

Comment 3

[Jim Mathies [:jimm]]

(In reply to Olli Pettay [:smaug] from comment #2)
> Hmm, how do we paint the back button? Is it somehow part of the content?

it's a div element defined in browser.xml [1].

In debugging this a little bit, I noticed that the overlay button handler [2] didn't receive any events when the canvas was below it. I confirmed widget was sending the right events too.

[1] http://mxr.mozilla.org/mozilla-central/source/browser/metro/base/content/browser.xul#206
[2] http://mxr.mozilla.org/mozilla-central/source/browser/metro/base/content/NavButtonSlider.js

Comment 4

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

Sounds like a hit testing issues, or are we doing some event dispatch in JS?

Comment 5

[Jim Mathies [:jimm]]

Found another situation where this manifests. We have selection monocles that users can drag to change in page selection, these elements are in the chrome doc and capture touch input events. When content is zoomed, the event targets in the touch events misidentify the target. Events that should target the chrome xul elements target elements in content instead. I checked aEvent.target, aEvent.originalTarget, and aEvent.explicitOriginalTarget, all of which help the wrong target.

Definitely seems like some sort of hit testing bug associated with changing window resolutions.

Comment 6

[Jim Mathies [:jimm]]

smaug, any suggestions on where to start looking for this?

Comment 7

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

That is all about hit testing. So I'd start somewhere in PresShell::HandleEvent to see why events
are targeted where they are.
Also, is this only about touch events or also mouse events?

Comment 8

[Jim Mathies [:jimm]]

(In reply to Olli Pettay [:smaug] from comment #7)
> That is all about hit testing. So I'd start somewhere in
> PresShell::HandleEvent to see why events
> are targeted where they are.
> Also, is this only about touch events or also mouse events?

Not sure, I don't have an easy way to test this since our touch selection monocles aren't coded such that they work with mouse events.

Comment 9

[Jim Mathies [:jimm]]

After a checkout of latest tip this weekend, this bug appears to be fixed. Including the original draw / overlay button bug. :)