Closed Bug 936905 Opened 7 years ago Closed 7 years ago

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

Categories

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

26 Branch
x86_64
Windows 8.1
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Whiteboard: [block28] feature=defect c=graphic_display_features u=metro_firefox_user p=0)

Attachments

(1 obsolete file)

Attached file draw.html (obsolete) —
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
Whiteboard: [release28]
Summary: Taps on chrome elements that overlay content that consume touch go to content → Taps on chrome elements that overlay content that consume touch go to content (when zoomed)
Summary: Taps on chrome elements that overlay content that consume touch go to content (when zoomed) → Defect - Taps on chrome elements that overlay content that consume touch go to content (when zoomed)
Whiteboard: [release28] → [release28] feature=defect c=graphic_display_features u=metro_firefox_user p=0
This doesn't appear to be related to event sending or apzc. Appears to be some sort of a event targeting bug.
No longer blocks: metro-apzc
Component: Widget: WinRT → DOM: Events
Hmm, how do we paint the back button? Is it somehow part of the content?
Component: DOM: Events → Event Handling
(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
Sounds like a hit testing issues, or are we doing some event dispatch in JS?
Blocks: 940952
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.
Blocks: metro-apzc
Whiteboard: [release28] feature=defect c=graphic_display_features u=metro_firefox_user p=0 → [block28] feature=defect c=graphic_display_features u=metro_firefox_user p=0
smaug, any suggestions on where to start looking for this?
Flags: needinfo?(bugs)
Summary: Defect - Taps on chrome elements that overlay content that consume touch go to content (when zoomed) → Defect - Touch events on chrome elements that overlay zoomed content go to content
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?
Flags: needinfo?(bugs)
Assignee: nobody → jmathies
(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.
Attachment #829876 - Attachment is obsolete: true
After a checkout of latest tip this weekend, this bug appears to be fixed. Including the original draw / overlay button bug. :)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
No longer blocks: metrov1backlog
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.