Clicking on links near the right edge of the display does not work

VERIFIED FIXED in Firefox 17

Status

()

defect
--
major
VERIFIED FIXED
7 years ago
2 years ago

People

(Reporter: AdrianT, Assigned: mcomella)

Tracking

({regression})

Trunk
Firefox 17
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15 unaffected, firefox16 unaffected, firefox17 verified, fennec17+)

Details

()

Attachments

(3 attachments)

Reporter

Description

7 years ago
Posted file logs
Nightly 17.0a1 2012-08-20
Device: Samsung Galaxy Tab (Android 3.1)

Steps to reproduce:
1. Open the Add-ons Manager
2. Tap on the addons.mozilla.org icon at the top right of the Add-on Manager - the shopping bag icon

Expected results:
addons.mozilla.org/en-US/android is opened in a new tab

Actual results:
Nothing happens. There is heptic feedback but a new tab is never opened.

Notes: The issue is not reproducible on Aurora 16.0a2 2012-08-20 or Firefox Mobile 15 beta 5
Reporter

Comment 1

7 years ago
I am unable to reproduce the issue on Motorola Droid 3 running Android 2.3.4
WFM (GN, 4.1.1) (Nightly 08/20).
Also fails for me on an Acer 10.1 tablet running ICS
Fails on the Tab 2 7"
Summary: Unable to open addons.mozilla.org from the Add-ons Manager → [Tablet] - Tapping the AMO and Marketplace buttons from the AMO/Apps manager is broken
Summary: [Tablet] - Tapping the AMO and Marketplace buttons from the AMO/Apps manager is broken → [Tablet] - Tapping the AMO and Marketplace buttons from the Addons/Apps manager is broken
I was having trouble uninstalling addons as well on the Galaxy Tab. I suspect the entire right side of that page is dead to touch events somehow.
When I reproduce this on a debug build my log has a lot of these warnings:

08-21 17:23:05.470 I/Gecko   (21513): WARNING: Overflowed nscoord_MAX in conversion to nscoord width: file ../../dist/include/nsRect.h, line 128
08-21 17:23:05.470 I/Gecko   (21513): WARNING: Overflowed nscoord_MAX in conversion to nscoord height: file ../../dist/include/nsRect.h, line 141

I attached gdb to see the call stack that was generating this warning and got the attached back trace. I'm not sure if this is the cause of the problem, but the touch events don't seem to be getting delivered to browser.js at all so it's likely that this is the problem.
(In reply to Kartikaya Gupta (:kats) from comment #5)
> I was having trouble uninstalling addons as well on the Galaxy Tab. I
> suspect the entire right side of that page is dead to touch events somehow.

The dead zone for this bug seems to be the same as the dead zone when trying to close the options overflow menu as per bug 775272. Note that this is not the case on phones.

Interestingly, long pressing the marketplace logo activates the correct context menu.
(In reply to Kartikaya Gupta (:kats) from comment #6)
> but the touch events don't seem to be getting delivered to
> browser.js at all so it's likely that this is the problem.

Whoops, this part is not true, I was using the wrong build. The touch events are getting delivered (but the assertion warnings are also still happening). I think the mouse events that we generate as a result of the touch events are causing the assertion errors as well, and perhaps not getting delivered properly. That would explain why the context menu is correct (since we don't need to deliver touch events for that).
(In reply to Kartikaya Gupta (:kats) from comment #8)
> (since we don't
> need to deliver touch events for that).

And by touch events of course I mean mouse events.
Duplicate of this bug: 784898
This is also happening on normal content pages (see duped bug 784898). In general, links on the right side of the content are not clickable. I created a simple test page at http://people.mozilla.org/~kgupta/bug/784016.html with a bunch of links and the ones on the right side of the screen highlight but do not trigger. In all cases we seem to be dispatching the touch events properly, picking them up in browser.js properly, and dispatching the mouse events to what appear to be the right coordinates. However the mouse events do not trigger activation of the link for some as-yet-unknown reason.
Severity: normal → major
Summary: [Tablet] - Tapping the AMO and Marketplace buttons from the Addons/Apps manager is broken → Clicking on links near the right edge of the display does not work
(Btw, above was on a Galaxy Nexus running 4.1). I will bisect to find a regression range.
Assignee: nobody → bugmail.mozilla
Also the assertion errors in comment #6 seem to be unrelated because I don't see them on my new test page.
Assignee: bugmail.mozilla → nobody
tracking-fennec: ? → 17+
Assignee: nobody → michael.l.comella
(In reply to Kartikaya Gupta (:kats) from comment #11)
> ... and dispatching the mouse
> events to what appear to be the right coordinates. However the mouse events
> do not trigger activation of the link for some as-yet-unknown reason.

Mouse events are sent by this method:
https://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#3612

Which will call the associated Gecko method, if I am not mistaken:
https://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#483

It does not seem Margaret's changeset created the issue because it's semi-unrelated and I also backed it out and nothing changed. The changeset before Margaret's, however, modifies these nsDOMWindowUtils so I think the root cause is there. I could not find a tbpl build exclusively for this changeset, however. The last working build kats listed does not have this change. Here is the changeset:
https://hg.mozilla.org/integration/mozilla-inbound/rev/67d9cf5ea455
Status: NEW → ASSIGNED
Posted patch PatchSplinter Review
Some parameters in the patch causing this bug (https://hg.mozilla.org/integration/mozilla-inbound/rev/67d9cf5ea455) were reversed.

jimm: Does everything else look okay?
Attachment #654878 - Flags: review?(jmathies)
Blocks: 781977
No longer blocks: 780906
Duplicate of this bug: 784847
Comment on attachment 654878 [details] [diff] [review]
Patch

oops, sorry my bad.
Attachment #654878 - Flags: review?(jmathies) → review+
Nice catch! My bad on the regression-finding, I should have been more careful with that.
https://hg.mozilla.org/mozilla-central/rev/7112cff6bdbf
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 17
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.