Closed Bug 900742 Opened 11 years ago Closed 11 years ago

[Browser] Touch events do not register in content

Categories

(Core :: Graphics: Layers, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla26
Tracking Status
b2g18 --- unaffected

People

(Reporter: nhirata, Assigned: kats)

References

Details

(Keywords: qablocker, regression)

Attachments

(1 file, 1 obsolete file)

## Environment : "gecko" revision="05d3797276d3" "gecko.git" revision="df5101f5fcc1157582d51a43ed5c006821ccd0ff" "gaia" revision="c1620a242c937c7fcb171b88c85ef63561165081" Build ID: 2013-08-01-03-02-24 MC/master build Unagi 1. go to http://people.mozilla.com/~nhirata/html_tp 2. try to scroll down Expected: it scrolls Actual: does not scroll Note: - landscape mode allows for some scrolling; it's rather difficult to scroll in landscape mode. - touch events don't seem to be registering at all. Clicking on a link doesn't seem to work either.... Not sure if I have to file a separate bug.
setting to qablocker because it prevents me from getting to portions of a web page to do other testing.
Flags: needinfo?(blassey.bugs)
Maybe I should put touch events doesn't register in content... tapping in a field doesn't do anything either. Touching the chrome seems to work fine. ie going back a web site, share via bluetooth, bookmarking...
Summary: [Browser] scrolling doesn't work in portrait mode → [Browser] Touch events do not register in content
What's the difference between the "gecko" revision and the "gecko.git" revision? Is bug 866232 in the regression range?
Flags: needinfo?(blassey.bugs) → needinfo?(nhirata.bugzilla)
gecko revision = hg repo; gecko.git revision = git repo https://hg.mozilla.org/releases/mozilla-b2g18/ vs https://git.mozilla.org/?p=releases/gecko.git;a=summary git is a clone off of hg if I understood things correctly. I'll have to get back to you on the regression range. I will try to take care of that this afternoon.
Hi Kats, I confirmed that the bug 866232 is in the regression range. This is fine in the 7/30 build 2013-07-30-03-02-00 <project name="mozilla-central" path="gecko" remote="hgmozillaorg" revision="3d40d270c031"/> <project name="gecko.git" path="gecko" remote="mozillaorg" revision="f69b55f44661de3dce069a275f1854e8b2265cd5"/> <project name="gaia.git" path="gaia" remote="mozillaorg" revision="ba5ff211fbf6a930326cc6a0d4a1205a7528630b"/> and is broken in the 7/31 build 2013-07-31-03-02-05 <project name="mozilla-central" path="gecko" remote="hgmozillaorg" revision="c2b375f3a909"/> <project name="gecko.git" path="gecko" remote="mozillaorg" revision="313f74bcad2b13f2b4ea18d9abfce75b9f0e372d"/> <project name="gaia.git" path="gaia" remote="mozillaorg" revision="9bfceaa90e8b92a379432b67121afa3cd3f14c90"/>
Flags: needinfo?(nhirata.bugzilla)
Attached patch Patch to correct hit-testing (obsolete) (deleted) — Splinter Review
I only need one reviewer; whoever gets to it first. After discussion with Matt I realized the code I wrote was wrong because it doesn't account for the "interleaving" of CSS transforms and async transforms that the layer goes through when it gets rendered to the screen. After spending some time sketching things out I realized I need to keep the raw rect and CSS transforms on the APZC instance so that I can untransform the input events correctly for hit testing.
Assignee: nobody → bugmail.mozilla
Attachment #785443 - Flags: review?(matt.woodrow)
Attachment #785443 - Flags: review?(bgirard)
I tried applying this patch locally and the patch in bug 899810 and it doesn't resolve the button problem in http://everlong.org/mozilla/notifications/. However now I can pan and zoom in http://ratp.fr. Should I file another bug ?
Yes please. I believe I know what is causing the clicking problem there. The click offset is wrong when the browser URL bar is visible.
Comment on attachment 785443 [details] [diff] [review] Patch to correct hit-testing Review of attachment 785443 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/ipc/AsyncPanZoomController.h @@ +653,3 @@ > > + bool VisibleRegionContains(const LayerPoint& aPoint) const { > + return mVisibleRect.Contains(aPoint); If we do our hit testing on bouding rects we could hit cases where the bounds of a layer isn't what we want if we have a layer with an irregular shape such as two rects in the topleft and bottomright. But then again I think scrollable frames have to be squared so we're most likely ok.
Attachment #785443 - Flags: review?(matt.woodrow)
Attachment #785443 - Flags: review?(bgirard)
Attachment #785443 - Flags: review+
Changes from v1: - Update an error in the test where it was expecting layers[3] instead of layers[4]. I introduced this error in https://hg.mozilla.org/mozilla-central/rev/a960ee129d91 (bug 866232 part 10). Also add a comment - Remove some no-longer-needed calls to recompute the effective transform in the test since the code doesn't use the effective transform any more. - Added a couple of APZC_LOG statements that I used for debugging and will be handy in the future
Attachment #785443 - Attachment is obsolete: true
Attachment #786447 - Flags: review?(bgirard)
Comment on attachment 786447 [details] [diff] [review] Patch to correct hit-testing (v2) Review of attachment 786447 [details] [diff] [review]: ----------------------------------------------------------------- LGTM
Attachment #786447 - Flags: review?(bgirard) → review+
Component: Gaia::Browser → Graphics: Layers
Product: Boot2Gecko → Core
Version: unspecified → Trunk
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Verified : "gecko" revision="8c240c67f76c" "gecko" revision="4dd254baf424523d3256ae47bdc20f9b2b8d5217" "gaia" revision="b527d7406b4eed3bacdee78597bb4ff21bf9f7d0" Build ID: 2013-08-13-04-02-22 MC/master build Unagi
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: