Behavior seen in profile of Homescreen app - user puts finger down - touchstart handled by mouse_event_shim.js - emits mousedown to homescreen - homescreen eats event and calls evt.stopPropagation() - ... but then BrowserElementScrolling processes onTouchStart() In this case, I expect the stopPropagation() on the synthetic mouse event to stop propagation of the original touchstart, and BrowserElementScrolling to not show up in the profile. This puts 20-30ms of unused code on the critical path of responsiveness to touch events. Not sure if this was done on purpose or is NYI.

I don't think we have a way to tell if an event has had propagationStopped called on it. So I don't know how we could forward this. Calling preventDefault() on an event sets event.defaultPrevented. But calling stopPropagation() does not (at least per the standard) set event.propagationStopped.

Hm. Can we inject a wrapper stopPropagation() into the synthetic event?

The problem went away with this commit which removes the shim: https://github.com/mozilla-b2g/gaia/commit/7a505331d9fbdd277e5d1c59a9f230200d494c93#apps/homescreen/index.html And here it is for the 1.0.0 branch: https://github.com/mozilla-b2g/gaia/commit/8d7803635ced3f4507ed82d0a72a3cc12f5d1585#apps/homescreen/index.html I'm not sure what the best way to resolve this is, so I'm going to mark it as a dupe of the bug that removed the shim.

The mouse_event_shim work went away, but we're still not blocking BrowserElementScrolling.