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

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Adrian Tamas (:AdrianT)]

Attachment: 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

Comment 1

[Adrian Tamas (:AdrianT)]

I am unable to reproduce the issue on Motorola Droid 3 running Android 2.3.4

Comment 2

[Aaron Train [:aaronmt]]

WFM (GN, 4.1.1) (Nightly 08/20).

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Also fails for me on an Acer 10.1 tablet running ICS

Comment 4

[Aaron Train [:aaronmt]]

Fails on the Tab 2 7"

Comment 5

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Attachment: back trace of assertion failure

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.

Comment 7

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

(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).

Comment 9

[Kartikaya Gupta (email:[e-mail])]

(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.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

(Btw, above was on a Galaxy Nexus running 4.1). I will bisect to find a regression range.

Comment 13

[Kartikaya Gupta (email:[e-mail])]

Regression on m-c nightlies provided this range:

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=22288130fea2&tochange=86ee4deea55b

Gonna dive into inbound builds.

Comment 14

[Kartikaya Gupta (email:[e-mail])]

https://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1344953262/ is the last build that passes.
https://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1344954523/ is the last build that fails.

This is a regression from https://hg.mozilla.org/integration/mozilla-inbound/rev/295552661955 (bug 780906)

Comment 15

[Kartikaya Gupta (email:[e-mail])]

Also the assertion errors in comment #6 seem to be unrelated because I don't see them on my new test page.

Comment 16

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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

Comment 17

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: Patch

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?

Comment 19

[Jim Mathies [:jimm]]

Comment on attachment 654878 [details] [diff] [review]
Patch

oops, sorry my bad.

Comment 20

[Kartikaya Gupta (email:[e-mail])]

Nice catch! My bad on the regression-finding, I should have been more careful with that.

Comment 21

[Jim Mathies [:jimm]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7112cff6bdbf

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/7112cff6bdbf