Closed Bug 1151152 Opened 10 years ago Closed 9 years ago

PointerEvents are not fired when the pointer is dragged out of the document

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Version:
40 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla42
Tracking Flags:
Tracking Status
firefox42 --- fixed

People

(Reporter: dev, Assigned: alessarik)

References

Details

Attachments

(4 files, 2 obsolete files)

print-pointer-events.html
875 bytes, text/html
Details
workaround.html
1.85 KB, text/html
Details
out_of_doc_ver3.diff
3.75 KB, patch
smaug
: review+
Details | Diff | Splinter Review
out_of_doc_issues_ver1.diff
1017 bytes, patch
smaug
: review+
Details | Diff | Splinter Review
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150403030204 Actual results: With dom.w3c_pointer_events.enabled set to true, PointerEvents are not fired when the pointer is held down on the page and and then moved outside the document (over the browser chrome or outside the window.) I have attached an HTML document which prints pointer and mouse event info to the page. After pressing the pointer down, mousemove events are fired as normal as the mouse leaves the document. However, a pointerout is fired instead of a pointermove outside the document and while the pointer stays outside, no PointerEvents are fired (including move, up, out, etc.) Moving the pointer back over the documents triggers a pointerover and then PointerEvents are fired as normal. Expected results: When the pointer is pressed and moved before before being releasing, PointerEvents should be fired even when the pointer is outside the document as happens with MouseEvents. IE seems to set an implicit pointer capture to accomplish this.
At, first. I have tested "print-pointer-events.html" and I have found behavior discribed in bug. At, second. According to pointer events specification: http://www.w3.org/TR/pointerevents/#the-pointerout-event 5.2.9 The pointerout event A user agent MUST fire a pointer event named pointerout when any of the following occurs: A pointing device is moved out of the hit test boundaries of an element. Looks like, actual behavior is in accordance with specification.
Flags: needinfo?(dev)
Yes, it's in accordance with the specification but a similar requirement exists for mouseout and that is not followed exactly: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-type-mouseout "A user agent MUST dispatch this event when a pointing device is moved off of the boundaries of an element." My desired behaviour could be achieved by manually setting pointer capture on pointerout of <html> and then releasing on pointerover and calling stopImmediatePropagation on those events. However, to avoid overriding a previous capture, I would need to listen to all gotpointercapture and lostpointercapture events to ensure that I'm setting pointer capture only when necessary (or is there a better way to check which element (if any) has captured a pointer?). Having the browser do this automatically would be a great convenience.
Flags: needinfo?(dev)
1. If FF has wrong behavior of mouse events, why we try to change pointer events behavior, maybe we should change mouse events behavior? 2. If we explicity call setPointerCapture on any element, in this case we get expected behavior of pointer events. 3. If you can propose something to pointer events specification, may be better way is asking about it in W3C community? http://lists.w3.org/Archives/Public/public-pointer-events/
I guess the spec needs to be clarified, but we also need to change the behavior to follow mouse event's behavior (and to behave like IE)
Comment 4 seems to confirm this bug report so I'm updating the status to NEW.
Status: UNCONFIRMED → NEW
QA Whiteboard: [triaged]
Ever confirmed: true
The V1 spec already has a note that "technically" allows implementations to do what IE does here (implicit capture on the HTML element when leaving the window while the pointer is down): http://www.w3.org/TR/pointerevents/#implicit-pointer-capture Browsers have also done this for mouse events I think for some time in some fashion. Google wants to consider making implicit capture the default in all cases (not just leaving the window). So this is something we can talk about further for the V2 spec if we want to get more specific. But the current spec certainly allows IE’s behavior (albeit in a non-normative way).
(In reply to jrossi from comment #6) > The V1 spec already has a note As I know all "notes" in spec has non-informative mark. > So this is something we can talk about further > for the V2 spec if we want to get more specific. Explicity thing always is more better than implicity thing.
Attached file workaround.html —
Let me introduce some workaround for current issue. We can add two listeners on HTML element, which can explicity set and release pointer capture on HTML window: First listener for pointerout - it checks bounding rect and pressed buttons. Second for pointerover - it checks state of explicity setPointerCapture. Let me notice, that if pointer capture was set on another element - in this case pointerout will not be fired on our element - because event will be suppressed according to current pointer events specification.
Flags: needinfo?(dev)
Thank you for the workaround. It works very well, though I'd much prefer that the Chrome team's proposition of implicit pointer capture by default were set as the standard. However, the discussions I've read seem to only mention touch and pen input but not mouse. I'd expect the behaviour to be identical for all input types.
Flags: needinfo?(dev)
Blocks: 1122211
Attached patch out_of_doc_ver1.diff (obsolete) — — Splinter Review
+ Add checking for pointer events while getting capturingContent
Attachment #8596550 - Flags: feedback?(dev)
Attachment #8596550 - Flags: feedback?(bugs)
Comment on attachment 8596550 [details] [diff] [review] out_of_doc_ver1.diff MOZ_ASSERT(false); is odd, but yeah, just follow what we do for mouse events.
Attachment #8596550 - Flags: feedback?(bugs) → feedback+
Could you test this on touch input? What happens if one touch downs, then moves touch to be over some iframe. What does IE do?
Also, test mouse initiated pointer events on IE. What happens when mouse is moved to be on top of an iframe. (I think we should try to make pointer events work like mouse events, but better to test what IE does.)
Hi Everyone, I've tested behavior on IE11 and Nightly with patch applied: In a page mode (i.e. using print-pointer-events.html directly) the behavior in IE and Nightly is identical. For mouse, touch and pen mousemove and pointermove events are risen for moving outside of body (in case left or right mouse button pressed, pen is put on digitizer). In iframe mode (i.e. print-pointer-events.html is loaded in iframe) the behavior is different. IE doesn't rise pointermove events when pointer out of the iframe border but Nightly does. Note that print-pointer-events.html should be added touch-action:none style to body tag in both cases to prevent pointer cancel on IE.
(In reply to Dmitriy Barkalov from comment #14) > In iframe mode (i.e. print-pointer-events.html is loaded in iframe) the > behavior is different. IE doesn't rise pointermove events when pointer out > of the iframe border but Nightly does. IE11 doesn't dispatch any events in that case? Sounds like a bug in IE11 then. Or did I misunderstand the comment?
IE doesn't dispatch pointer events (pointermove). Mouse events (mousemove) are risen as expected. Can't say for IE if it is a bug or expected behavior.
Attached patch out_of_doc_ver2.diff (obsolete) — — Splinter Review
+ Added implicit capturing content at NS_POINTER_DOWN. + Added pointer event check at detection activeShell. Suggestions and comments and objections are very welcome.
Attachment #8596550 - Attachment is obsolete: true
Attachment #8596550 - Flags: feedback?(dev)
Attachment #8611173 - Flags: review?(bugs)
Attachment #8611173 - Flags: feedback?(dev)
Some suggestion: It is not main, which behavior IE has. If we plan to implement behavior, which is not described in specification, we should understand which behavior is right, and implement it everywhere (at iframe and simple page, at FF and IE, for mouse and for touch, and for others ...).
Comment on attachment 8611173 [details] [diff] [review] out_of_doc_ver2.diff Why do we wnat to handle pointer events differently to mouse events? When ESM handles NS_MOUSE_BUTTON_DOWN, we call SetActiveManager. Could we do that for primary pointer too, and then in presshell when it checks for the activeESM have if (aEvent->mClass == ePointerEventClass || aEvent->HasMouseEventMessage()) check - at least for the primary pointer. Please change the patch, or explain why capturing content should be used in case of pointer events. (using SetCapturingContent is possibly more regression prone, since in case we fire both mousedown and pointerdown, that ends up changing the current behavior.)
Attachment #8611173 - Flags: review?(bugs) → review-
(In reply to Maksim Lebedev from comment #18) > https://treeherder.mozilla.org/#/jobs?repo=try&revision=421aea1e8f8e Sorry, I can't test this build. Please give a link to build that contains Windows version (Win 8 Opt prefered).
Flags: needinfo?(v-dmbark) → needinfo?(alessarik)
(In reply to Dmitriy Barkalov from comment #21) > (In reply to Maksim Lebedev from comment #18) > > https://treeherder.mozilla.org/#/jobs?repo=try&revision=421aea1e8f8e > > Sorry, I can't test this build. Please give a link to build that contains > Windows version (Win 8 Opt prefered). Looks like the builds failed...
- Removed implicit capturing content at NS_POINTER_DOWN in ESM Suggestions and comments and objections are very welcome.
Assignee: nobody → alessarik
Attachment #8611173 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8611173 - Flags: feedback?(dev)
Attachment #8622560 - Flags: review?(bugs)
Could anybody please check expected behavior in that build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=de7a3adfab60 Some couple of tests will be better for this bug than nothing.
Flags: needinfo?(v-dmbark)
Flags: needinfo?(dev)
Flags: needinfo?(alessarik)
Attachment #8622560 - Flags: review?(bugs) → review+
(In reply to Maksim Lebedev from comment #24) > Could anybody please check expected behavior in that build: > https://treeherder.mozilla.org/#/jobs?repo=try&revision=de7a3adfab60 > > Some couple of tests will be better for this bug than nothing. I've tested on Windows 7 and 8 with different combinations of pan-zoom, multi-process and touch settings. Seems the behavior of pointer events is the same as mouse events.
Flags: needinfo?(v-dmbark)
This patch provides the behaviour that I had expected originally. Thank you.
Flags: needinfo?(dev)
Thanks for testing. If there are no objections, I put checkin-needed flag.
Keywords: checkin-needed
OS: Linux → All
Hardware: x86_64 → All
sorry had to back this out for test failures like https://treeherder.mozilla.org/logviewer.html#?job_id=10959955&repo=mozilla-inbound
Flags: needinfo?(alessarik)
+ Increase assertions counts in test_mousecapture.xul Suggestions and comments and objections are very welcome.
Attachment #8625472 - Flags: review?(bugs)
PATCH + FIX: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d40f3f56bf01 Very strange, but looks like failed test works only for debug builds.
Comment on attachment 8625472 [details] [diff] [review] out_of_doc_issues_ver1.diff I don't understand how this can fix the issue "test_pointerevent_pointerleave_descendant_over-manual.html | pointerleave shouldn't be received on descendant's pointerover - got 1, expected 0 " See comment 29. And what are the assertions you're trying to hide here?
Attachment #8625472 - Flags: review?(bugs) → review-
And yeah, for those assertions that change is ok, but the issue in comment 29 need to be still fixed, right?
(In reply to Olli Pettay [:smaug] from comment #37) > but the issue in comment 29 need to be still fixed, right? That issues are related with bug 1000870, and I prefere make changes in that bug. So I wait you positive review on current bug only on changes with assertions count. (Testing is at comment 34).
Flags: needinfo?(bugs)
Flags: needinfo?(bugs)
Attachment #8625472 - Flags: review- → review+
If there are no objections, I put checkin-needed flag.
Flags: needinfo?(alessarik)
Keywords: checkin-needed
Whoops, I should have pinned those on bug 1000870 I guess.
Why all bugs backed out if troubles do happen only at one bug?
Flags: needinfo?(ryanvm)
If there are no objections, I put checkin-needed flag again. But at current time try to checkin both bug at different sessions.
Keywords: checkin-needed
(In reply to Maksim Lebedev from comment #43) > Why all bugs backed out if troubles do happen only at one bug? Because I was busy and the trees were closed, so relanding wasn't an option at the time.
Flags: needinfo?(ryanvm)
https://hg.mozilla.org/mozilla-central/rev/edd7e1174537
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox42: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Depends on: 1191299
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: