Closed Bug 978438 Opened 11 years ago Closed 9 years ago

MDN documentation should not imply touchenter/touchleave events still exist

Categories

(Developer Documentation Graveyard :: API: DOM, defect)

Product:
Developer Documentation Graveyard
Component:
API: DOM
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: remi.ducceschi, Assigned: teoli)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 Iceweasel/28.0 (Beta/Release) Build ID: 20140215005646 Steps to reproduce: I try to handle a "touchleave" event on a DOM element. Actual results: The event "touchleave" is never fired Expected results: I expected that the event is sent when I move my finger out of the DOM element considered... you can try it on the official mozilla touchevent example: https://mdn.mozillademos.org/en-US/docs/Web/Guide/API/DOM/Events/Touch_events$samples/Example?revision=493243 the function "handleEnd()" should be called when your finger go outside the canvas, but it is never the case. it has been tested with: - firefox for android 27 and 28 beta - firefox 28 beta on Linux amd64 and firefox 27 on windows 64 bits, both with the simulated touch events (not directly with a touch screen)
I can confirm the problem with FFOS on a peak phone.
Kevin, Naoki, would either of you be the right people to ask to replicate or confirm this bug? Thanks!
Component: Untriaged → DOM: Events
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(kbrosnan)
Product: Firefox → Core
I get the same behavior from Firefox for Android and Chrome for Android. touchleave is sent on finger up not when exiting that test case. I don't see any mention of touchleave in http://www.w3.org/TR/touch-events/
Flags: needinfo?(kbrosnan)
If it is not yet implemented, or if it is an experimental feature, it *should* be written in the mozilla documentation. i.e. here https://developer.mozilla.org/fr/docs/Web/API/TouchEvent and here https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Touch_events#Example
It does seem documented in https://developer.mozilla.org/fr/docs/Web/API/TouchEvent: "touchleave" Sent when a touch point exits an element. Note: These events don't bubble.
oh... that's what "bubble" means... I'm really sorry, I thought it meant that the event *is* sent to the element where the action occurs, but doesn't bubble to the parents of the element... Whereas, it means that the event is just never sent... sorry for your loss of time :s maybe a "not implemented yet" could be more accurate (?)
Touchend/Touchleave does work for me on B2G 1.4 which is Gecko 30.0a2; so I think maybe Rémi is correct... that it's not implemented in 28 but is implemented in 30. Can you try in 30 + please? ie aurora or nightly? :)
Flags: needinfo?(nhirata.bugzilla) → needinfo?(remi.ducceschi)
I'm running android with an intel processor. I haven't found the Aurora i386 version, so I tried with the nightly version for android (31.0a1). and it still does not work... maybe it only works on B2G?
Flags: needinfo?(remi.ducceschi)
Possibly. I spoke w/ kbrosnan and he mentioned that Firefox for Android doesn't use APZ, whereas b2g does.
Finally, is it a bug? or not? maybe the documentation page should be updated to be more explicit? anyway, thank you for your answers :)
Android Kit-Kat FireFox 29.0.1 (Also fails on nightly) Neither the touchcancel nor the touchleave events are ever fired regardles of the swipe leaving the element or screen. Pretty hard to work out what's happening when touchstart/end is all you've got to go on and touchend tells you the target was just where the element started :-( Why so little interest in this?
QA Whiteboard: qawanted
This won't work on Firefox for Android until we move from JavaAPZ to the APZ used on B2G and Metro. Which is bug 776030.
Status: UNCONFIRMED → NEW
QA Whiteboard: qawanted
Depends on: apz-fennec
Ever confirmed: true
OS: Linux → Android
Hardware: x86_64 → ARM
This bug is unrelated to 776030. touchenter/touchleave have been removed from the W3C spec and are not supported in Firefox. In fact I recently landed bug 1036444 to remove the events from the code because they were not being used anywhere. Any documentation that says they still exist should be updated to reflect this. Morphing this bug to be a documentation bug. The following pages (at least) need updating: https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Touch_events#Example https://developer.mozilla.org/en-US/docs/Web/Events/touchenter https://developer.mozilla.org/en-US/docs/Web/Events/touchleave https://developer.mozilla.org/en-US/docs/Web/API/TouchEvent#touchenter
Assignee: nobody → jypenator
Component: DOM: Events → API: DOM
No longer depends on: apz-fennec
Product: Core → Developer Documentation
Version: 28 Branch → unspecified
Summary: event touchleave is never fired → MDN documentation should not imply touchenter/touchleave events still exist
But surely Touchcancel still exists? Your example does not work. Also please be aware that in every other browser Chrome, Opera, Android, IE (pointerend), Safari, a preventDefault() call on a touchend event prevents the mouse emulation. FireFox is failing again :-(
Please refrain from posting the same comment in multiple bugs. The touchcancel event does still exist, and it's not clear to me what behaviour you are expecting. Can you please provide clear steps to reproduce the problem you believe is happening, as well as describe the behaviour you expect to happen instead?
If you touchdown on an element and swipe off it before lifting then I expect FireFox to deliver a touchstart/touchcancel sequence not a touchstart/touchend. Granted that the standard appears to be ill-defined or non-prescriptive when it comes to what should trigger a touchcancel but the jury looks to be in for all other browsers. (Safari may be an oddball. Not 100% certain yet with disabling default gesture) What do you do if a 2nd finger is added. touchstart->touchcancel->touchstart with 2 points?
The spec actually is pretty clear on this topic http://www.w3.org/TR/touch-events/#the-touchmove-event "The target of this event must be the same Element on which the touch point started when it was first placed on the surface, even if the touch point has since moved outside the interactive area of the target element." The same is true for touchend and touchcancel.
Yes Kartikaya, but what you refer to as "this topic" is not what I'm discussing. I don't care what you do with your touchmove events or even your touchend events (which also adhere to that dictum thus necessitating the timely delivery of touchCANCEL) Please see: - http://www.w3.org/TR/touch-events/#the-touchcancel-event Do you maintain that "implementation specific" means the same as "pretty clear"??? How about just do what Chrome does and get on with it?
I understand you're frustrated by Firefox's behavior. Believe me, I understand frustration. I feel every time somebody comes along complaining (rightly or wrongly) about something we're doing, but doesn't actually provide us the information we need to fix it. Since you didn't provide a test case, I tried to write one based on your description in comment 16. You can find it at http://people.mozilla.org/~kgupta/bug/978438.html In Chrome, as in Firefox, the touchmove events continue when you move your finger outside the box, and then you get a touchend event. If this is not what you meant, please take the testcase and adapt it to illustrate what you did mean. Without a clear understanding of what you're complaining about it's impossible for me to fix it. The code that governs this is highly complex, more so than most people realize. Changing it is non-trivial and carries a high risk of breaking other things which just continues the cycle of pain and frustration.
Hi Kartikaya, Well it gets even more frustrating for me as you are correct that Chrome now also no longer delivers the touchcancel. I believe this to be a regression due to a fix to scroll behaviour. See: - https://code.google.com/p/chromium/issues/detail?id=411122 and https://groups.google.com/a/chromium.org/forum/#!topic/input-dev/Ru9xjSsvLHw The behaviour change occurred between 35.0.1916.138 and 36.0.1985.135 For the "correct" behaviour please run your example (very similar to mine and sorry for not including it) with Opera or the Android browser. Cheers Richard Maher (And thanks for persisting)
Based on the response you got at https://code.google.com/p/chromium/issues/detail?id=411122 it sounds like the behaviour is now consistent between Firefox and Chrome.
Hi Kartkaya, Yes that is Chrome 36's position and my comments and example there make my position clear. IF Mozilla is happy with ALL of those facts then there's not much more to say. Cheers Richard
I fixed the documentation.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.