info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Please Read: breaking change to mouse events
113 views
Skip to first unread message
David Flanagan
Jan 5, 2013, 3:18:31 AM1/5/13
to <dev-gaia@lists.mozilla.org>
Bug 823619 will be landing soon, and when it does, it will make a
major change to the way touch events are converted to mouse events in
FirefoxOS. Apps will continue to see mouse events when the user taps,
but will not receive mouse events when the user scrolls, swipes or
pans. For these gestures, only touch events will be delivered.
There are three things you must know:
1) Bug 823619 changes gecko and gaia: if you update one without
the other, nothing will work right.
2) We've tried very hard not to break any core Gaia apps with this
change. But please be on the lookout for regressions and please report them.
3) If your non-core app does not work correctly after this
change, try adding the shared/js/mouse_event_shim.js script to it and
see if that fixes things. There is much more about this script below.
You can stop reading here if none of the above is interesting to you.
Background
------------
The de-facto standard for how HTML mouse events should work on mobile
devices with touch screens was established by Apple and the
iPhone. Safari on the iPhone sends mouse events only when the user
taps. All other gestures are touch events only. Furthermore, the mouse
events are not generated until after that tap gesture is complete. In
this event model a tap gesture generates a sequence of events like
this:
touchstart touchend mousemove mousedown mouseup click
The FirefoxOS browser follows this event model so mobile websites that
work for the iPhone and Android (and Fennec) will also work on FirefoxOS.
Our apps have always been different, however, probably because we want
them to work on the desktop as well as on the phone. When running on
the desktop, apps get only mouse events. So when running on the phone,
we made Gecko simulate a full set of mouse events for the apps. In
this model, every touchstart event generates a mousedown event and
every touchmove generates a mousemove event.
This is what is changing now: FirefoxOS apps will no longer use the
mouse event model of the desktop, and will now use the standard mouse
event model of the mobile web.
(Note that Bug 823619 does not change the system app or the on-process
Browser app: both of those apps will continue to receive mouse events
as they always have, at least for now. Also, Bug 823619 does not
affect contextmenu events: these are delivered as usual from long
press events.)
Why Now?
---------
It is very late in the game to be making a change of this
magnitude. But we really don't want to launch FirefoxOS with a mouse
event model that is different from the one that all other mobile
devices use. And the truth is that we haven't really been able to get
our current mixed touch and mouse event model to work right. Bug
823619 blocks many important scrolling and keyboard bugs. Changing
event models will make it easy to resolve those issues.
What Does this Mean for Me?
----------------------------
As part of Bug 823619, we've tried to adapt all of the core Gaia apps
so that they work correctly under the new event model. Please be on
the lookout for changes in behavior, and if you find event-related
bugs, please report them and cc me.
If you are the author of an app that is not a core Gaia app, you may
need to modify your app:
1) If your app only responds to tap gestures, then you probably don't
have to change anything. If you use only click and contextmenu event
handlers they should continue to just work as expected. If you use a
mousedown event handler for taps, it will probably continue to work,
but you won't get the mousedown event until after the user has lifted
her finger, which may not be what you want.
2) If your app uses mousemove, mouseover, mouseout, mouseenter, or
mouseleave events then it won't work as is, but you may be able to fix
it by simply adding a single tag to your html:
<script src="shared/js/mouse_event_shim.js"></script>
This script, developed as part of Bug 823619, simulates mouse events
based on the touch events that gecko delivers to your app. The
simulation is not perfect, but it is good enough to make a number of
the core Gaia apps work. There are some details you need to understand
about the shim, and they are covered below.
3) If the shim doesn't work for you or if your app depends on dblclick
events, then you may need to convert your app to use touch events. One
of the main differences between mouse events and touch events is that
touchmove and touchend events are always delivered to the same target
element that the touchstart event was delivered to. There are no
touchenter and touchleave events as there are for mouse events:
touches are always targeted at the element they started on. Often this
makes them easier to work with than mouse events.
The Shim
----------
The mouse_event_shim.js module described above works by listening for
touch events and simulating the corresponding mouse events, just like
Gecko used to do. To make this work it must also capture any mouse
events that Gecko does send when the user taps. By the time those
events arrive, they are duplicates, so the shim prevents them from
propagating.
As noted above, touch events are always targeted at the element on
which the started. To simulate mouse events, therefore, the shim must
figure out what element the a touch is actually over, and it does this
by calling elementFromPoint() on each touchmove event. This works
well, except when your code uses element.setCapture() to redirect
mousemove and mouseup events. If your app uses the shim, you must
follow each call to element.setCapture() with
MouseEventShim.setCapture(element).
If you don't care about mouseover/mouseout and mouseenter/mouseleave
events and would like mouse events to always be delivered to the
element on which they started (like touch events are) you can avoid
the overhead of repeated calls to elementFromPoint() by setting
MouseEventShim.trackMouseMoves to false.
Finally, if you use the timeStamp property of mouse events (to
determine the velocity of a swipe, for example) there is one more
thing to be aware of. Normal events have a millisecond timestamp. For
some reason synthetic events like those generated by the shim have a
microsecond timestamp. So if your code subtracts one mouse event
timestamp from another, the result with the shim will be 1000 times as
large as you expect. The workaround is to use
MouseEventShim.getEventTimestamp(). Pass an event to that function and
it will return a millisecond timestamp, even for synthetic events with
microsecond timestamps.
major change to the way touch events are converted to mouse events in
FirefoxOS. Apps will continue to see mouse events when the user taps,
but will not receive mouse events when the user scrolls, swipes or
pans. For these gestures, only touch events will be delivered.
There are three things you must know:
1) Bug 823619 changes gecko and gaia: if you update one without
the other, nothing will work right.
2) We've tried very hard not to break any core Gaia apps with this
change. But please be on the lookout for regressions and please report them.
3) If your non-core app does not work correctly after this
change, try adding the shared/js/mouse_event_shim.js script to it and
see if that fixes things. There is much more about this script below.
You can stop reading here if none of the above is interesting to you.
Background
------------
The de-facto standard for how HTML mouse events should work on mobile
devices with touch screens was established by Apple and the
iPhone. Safari on the iPhone sends mouse events only when the user
taps. All other gestures are touch events only. Furthermore, the mouse
events are not generated until after that tap gesture is complete. In
this event model a tap gesture generates a sequence of events like
this:
touchstart touchend mousemove mousedown mouseup click
The FirefoxOS browser follows this event model so mobile websites that
work for the iPhone and Android (and Fennec) will also work on FirefoxOS.
Our apps have always been different, however, probably because we want
them to work on the desktop as well as on the phone. When running on
the desktop, apps get only mouse events. So when running on the phone,
we made Gecko simulate a full set of mouse events for the apps. In
this model, every touchstart event generates a mousedown event and
every touchmove generates a mousemove event.
This is what is changing now: FirefoxOS apps will no longer use the
mouse event model of the desktop, and will now use the standard mouse
event model of the mobile web.
(Note that Bug 823619 does not change the system app or the on-process
Browser app: both of those apps will continue to receive mouse events
as they always have, at least for now. Also, Bug 823619 does not
affect contextmenu events: these are delivered as usual from long
press events.)
Why Now?
---------
It is very late in the game to be making a change of this
magnitude. But we really don't want to launch FirefoxOS with a mouse
event model that is different from the one that all other mobile
devices use. And the truth is that we haven't really been able to get
our current mixed touch and mouse event model to work right. Bug
823619 blocks many important scrolling and keyboard bugs. Changing
event models will make it easy to resolve those issues.
What Does this Mean for Me?
----------------------------
As part of Bug 823619, we've tried to adapt all of the core Gaia apps
so that they work correctly under the new event model. Please be on
the lookout for changes in behavior, and if you find event-related
bugs, please report them and cc me.
If you are the author of an app that is not a core Gaia app, you may
need to modify your app:
1) If your app only responds to tap gestures, then you probably don't
have to change anything. If you use only click and contextmenu event
handlers they should continue to just work as expected. If you use a
mousedown event handler for taps, it will probably continue to work,
but you won't get the mousedown event until after the user has lifted
her finger, which may not be what you want.
2) If your app uses mousemove, mouseover, mouseout, mouseenter, or
mouseleave events then it won't work as is, but you may be able to fix
it by simply adding a single tag to your html:
<script src="shared/js/mouse_event_shim.js"></script>
This script, developed as part of Bug 823619, simulates mouse events
based on the touch events that gecko delivers to your app. The
simulation is not perfect, but it is good enough to make a number of
the core Gaia apps work. There are some details you need to understand
about the shim, and they are covered below.
3) If the shim doesn't work for you or if your app depends on dblclick
events, then you may need to convert your app to use touch events. One
of the main differences between mouse events and touch events is that
touchmove and touchend events are always delivered to the same target
element that the touchstart event was delivered to. There are no
touchenter and touchleave events as there are for mouse events:
touches are always targeted at the element they started on. Often this
makes them easier to work with than mouse events.
The Shim
----------
The mouse_event_shim.js module described above works by listening for
touch events and simulating the corresponding mouse events, just like
Gecko used to do. To make this work it must also capture any mouse
events that Gecko does send when the user taps. By the time those
events arrive, they are duplicates, so the shim prevents them from
propagating.
As noted above, touch events are always targeted at the element on
which the started. To simulate mouse events, therefore, the shim must
figure out what element the a touch is actually over, and it does this
by calling elementFromPoint() on each touchmove event. This works
well, except when your code uses element.setCapture() to redirect
mousemove and mouseup events. If your app uses the shim, you must
follow each call to element.setCapture() with
MouseEventShim.setCapture(element).
If you don't care about mouseover/mouseout and mouseenter/mouseleave
events and would like mouse events to always be delivered to the
element on which they started (like touch events are) you can avoid
the overhead of repeated calls to elementFromPoint() by setting
MouseEventShim.trackMouseMoves to false.
Finally, if you use the timeStamp property of mouse events (to
determine the velocity of a swipe, for example) there is one more
thing to be aware of. Normal events have a millisecond timestamp. For
some reason synthetic events like those generated by the shim have a
microsecond timestamp. So if your code subtracts one mouse event
timestamp from another, the result with the shim will be 1000 times as
large as you expect. The workaround is to use
MouseEventShim.getEventTimestamp(). Pass an event to that function and
it will return a millisecond timestamp, even for synthetic events with
microsecond timestamps.
Josh Carpenter
Jan 6, 2013, 3:00:16 AM1/6/13
to David Flanagan, <dev-gaia@lists.mozilla.org>
This sounds great, David. It sounds like it might resolve one of our scrolling quirks: when initiating a scroll, if the user starts their swipe on an interactive element (eg a button), the element briefly displays it's press state. Three cheers if this is one of issues addressed by 823619. :)
-
Josh
Sent from my iPhone
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
-
Josh
Sent from my iPhone
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
Tim Taubert
Jan 6, 2013, 6:32:31 AM1/6/13
to dev-...@lists.mozilla.org
On 01/06/2013 09:00 AM, Josh Carpenter wrote:
> This sounds great, David. It sounds like it might resolve one of our scrolling quirks: when initiating a scroll, if the user starts their swipe on an interactive element (eg a button), the element briefly displays it's press state. Three cheers if this is one of issues addressed by 823619. :)
Seems like this is unfortunately not fixed, I wonder why. Initiating the
> This sounds great, David. It sounds like it might resolve one of our scrolling quirks: when initiating a scroll, if the user starts their swipe on an interactive element (eg a button), the element briefly displays it's press state. Three cheers if this is one of issues addressed by 823619. :)
scroll on a button highlights it, seems to steal focus and hides the
keyboard.
Is there a bug for that, yet?
- Tim
Tim Taubert
Firefox Engineer
ttau...@mozilla.com
David Flanagan
Jan 6, 2013, 10:44:57 PM1/6/13
to Tim Taubert, dev-...@lists.mozilla.org
Tim,
If you report this as a bug, you'll want to check whether that app
you're observing this in uses shared/js/mouse_event_shim.js or not. It
could be that the shim isn't suitable for use in apps that have
scrollable regions with highlightable elements.
David
If you report this as a bug, you'll want to check whether that app
you're observing this in uses shared/js/mouse_event_shim.js or not. It
could be that the shim isn't suitable for use in apps that have
scrollable regions with highlightable elements.
David
Josh Carpenter
Jan 7, 2013, 2:12:45 AM1/7/13
to David Flanagan, dev-...@lists.mozilla.org, Tim Taubert
I'm seeing it in:
Settings
Browser (tabs drawer)
Contacts
Email, etc.
But I suspect it's more widespread. The behavior seems to be identical in each instance.
—
Josh Carpenter
UX Designer
Mozilla
Settings
Browser (tabs drawer)
Contacts
Email, etc.
But I suspect it's more widespread. The behavior seems to be identical in each instance.
—
Josh Carpenter
UX Designer
Mozilla
Josh Carpenter
Jan 7, 2013, 2:53:26 AM1/7/13
to David Flanagan, dev-...@lists.mozilla.org, Tim Taubert
UX filed the following bug a while back:
Scrolling through a list triggers button highlights
https://bugzilla.mozilla.org/show_bug.cgi?id=804315
It was marked a dupe of 766066, but fixing that has not fixed the 804315 issue.
—
Josh Carpenter
UX Designer
Mozilla
Scrolling through a list triggers button highlights
https://bugzilla.mozilla.org/show_bug.cgi?id=804315
It was marked a dupe of 766066, but fixing that has not fixed the 804315 issue.
—
Josh Carpenter
UX Designer
Mozilla
0 new messages