Closed Bug 1043022 Opened 5 years ago Closed 5 years ago
Clicking on links in the browser doesn't seem to work
STR: 1. On a master B2G build (Flame) load a page like https://bugzilla.mozilla.org/show_bug.cgi?id=989403 2. Zoom in and scroll down to the attachments section 3. Click on the attachment for the "standalone test case" Expected: - The link activates and the browser navigates Actual: - The link might flash active for a split second but quickly goes inactive again. It doesn't navigate to the page though. If I long-press on the link it does give me the context menu and I can successfully open the link in a new tab. This might be a platform bug but filing it in browser for now because that's the only place I'm seeing it. I haven't looked into it yet but I can do that tomorrow if nobody else gets to it first.
QA Wanted for branch checks.
Regression from 1016481.
5 years ago
Basically the problem is that on a page that allows double-tap, the notification at http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp?rev=c452b1384965#1913 happens before the SetSingleTapOccurred() call at http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/AsyncPanZoomController.cpp?rev=9bc64b0290c2#1432 and so mTouchIsClick ends up having a value of IsNotClick.
This screams out for automated testing.
Last I checked we don't have any test frameworks that can simulate actual user input from the hardware side. Not on B2G anyway.
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
(In reply to Jason Smith [:jsmith] from comment #7) > [Blocking Requested - why for this release]: Functional regression with basic functionality of browser content.
I backed out bug 1016481 to fix this, since I couldn't immediately think of a good fix. https://hg.mozilla.org/integration/mozilla-inbound/rev/bf3d32fac6b3
Approval Request Comment [Feature/regressing bug #]: bug 1016481 (landed recently on 33) [User impact if declined]: often clicking links in the B2G browser doesn't work [Describe test coverage new/current, TBPL]: this is a backout of bug 1016481, so it restores the old tested behavior [Risks and why]: low-risk, it was a recent landing. backout was clean. [String/UUID change made/needed]: none
Attachment #8461461 - Flags: approval-mozilla-aurora?
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #9) > I backed out bug 1016481 to fix this, since I couldn't immediately think of > a good fix. > > https://hg.mozilla.org/integration/mozilla-inbound/rev/bf3d32fac6b3 https://hg.mozilla.org/mozilla-central/rev/bf3d32fac6b3
5 years ago
Attachment #8461461 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Switching the 2.1?->2.1+, on these fixed bugs as these are regression. Nothing to land here, its just flag-cleanup of 2.1? list. Please Ni me if there is confusion/disagreement.
blocking-b2g: 2.1? → 2.1+
Issue verified as fixed on Flame 2.1 and Flame 2.2 Device: Flame 2.1 KK (319mb) (Full Flash) BuildID: 20141011000201 Gaia: f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1 Gecko: d813d79d3eae Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.2 Master KK (319mb) (Full Flash) BuildID: 20141011040204 Gaia: 95f580a1522ffd0f09302372b78200dab9b6f322 Gecko: 3f6a51950eb5 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 User clicking on browser links opens new page. Tested URL from Comment 0 as well as multiple other urls. Double-checked current master to ensure verification
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
You need to log in before you can comment on or make changes to this bug.