Personal tools

Firefox/Projects/Multitouch

From MozillaWiki

Jump to: navigation, search

Contents

Updated on 7/25

This project page was updated with current status of all the important UX and API bugs that were being worked on. The current info can be found on the sections UX front, API front, and Future. Timeline/Dependencies are kept as original for reference.

Pitch

This project aims to improve Firefox support for touchscreen devices. These improvements include making the browser experience better for users of touch screens (on desktop and mobile) and making it possible for webpages to make use of this new form of user input.

Goals

  • Allow users to interact with the browser via touchscreens
  • Provide good usability for surfing the web
  • Feature a new form of input method and allow web developers to make use of it
  • Support this API in Desktop and Mobile

Non Goals

  • Implement advanced form of interactions such as custom gestures
  • Alter any behavior for non-touchscreen users

Status

  • IN FLIGHT - Approaching airport, getting ready to land
    • project lead: felipe
    • project members:
    • started implementation, working on two fronts
    • tracking bugs: bug 548100

UX front

Current status:

  • bug 547997 – Perform hit target detection/correction on tap clicks

- Finished: platform support and front-end implementation on Fennec - Also relevant: hit-area measurements of new theme in bug 572472. tl;dr results: the sizes are bigger making Firefox 4 more easily clickable


  • bug 547996 – Be able to tell when a click was generated by touch

- Done: mouseEvent.mozInputSource attribute


  • bug 548005 – Browser zoom should stay centered when coordinates are available

- Wrote a patch for it, but after getting feedback a better approach on layout/ is needed. I want to revisit this soon.


  • bug 548012 – Browser zoom should be cancelable to be handled by webpage

- This handling is possible to do with the multitouch API, and therefore an special and non-standard way to do it (as was the intent of the original bug) won't be needed.


  • bug 549446 - Possibility to hide brower's scrollbars

- This should be targeted for the future when we revamp our full-screen UI to be friendly for tablet-sized devices.

Multitouch API front

- Implemented a Moz* API for Windows 7. Patches on final review line.

- Implementation ready for Landing 1 described on the timeline - expose multitouch data from hardware to web content, letti

- All original Constraints / Dependencies were taken care of:

    • get rid of manual multitouch switch
    • make the work compatible with native widget removal bug 130078

Future

  • deliver touch API in a beta (with demos and example code) and get feedback from web developers

More to the future:

  • work on standards
  • work on gestures

Timeline / Milestones

The following set of steps represent the main plan to be able to ship the new API by taking into account the 2 issues above


  • Get rid of the manual document.multitouchData switch and work on switching modes when the page requests any touch events [how to do this on Dependencies section]
    • This deactivates page scrolling and win7 gesture recognition on pages with touch events
  • Work on our events implementation for desktop and mobile to get them close to a possible spec (following smaug's proposal?)


  • [LANDING 1] Deliver the raw events input first
  • Check on using windows gesture processors or implement our own gesture engine
  • [LANDING 2] Deliver the gesture events
  • Re-implement [kinetic] panning on our engine for the pages using the touch events
  • [LANDING 3] Deliver panning on our engine


Note 1: for pages that will not make use of the touch apis, nothing will change, and we will continue to use window's own gesture and scrolling processors. If, after LAND 3 or later we think our own stack is good enough to replace windows's one we can make the full switch

Note 2: Most demos out there related to touch (e.g. [1]) never combine it with a page with scrolling, so disabling it as a first step doesn't seem to be a big problem.

Constraints and Dependencies

  • Most of the work right now is focused on Win7 only for being the only OS to provide a standard API for multitouch
  • Keep an eye on the native widget removal project because it directly impacts this one
    • Steps needed to get rid of manual switch:
      • Hook-up counters of listeners of touch events, calling RegisterTouchWindow on 0 -> 1, and UnregisterTouchWindow on 1 -> 0 and setting a flag
      • Since child widgets will be removed, on any tab/page change we will need to check the flag and call UnregisterTouchWindow/RegisterTouchWindow

Testing

  • TBD - We would need the regular testing schemes for events, plus some manual testing or simulation of multitouch events from the OS
  • [perf]
  • [compatibility]
  • [security]

Related Projects