856083 - Browser links and text boxes can't be selected

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Browser, defect, P1)

Description

[Diego Wilson [:diego]]

I can scroll and zoom, but I can't tap on any link or text box on any page.

This seems to be affecting only 1.0.1 and 1.1, not master

Comment 1

[Daniel Coloma:dcoloma]

Can't repro, which Gaia and Gecko tips are you using?

Comment 2

[Daniel Coloma:dcoloma]

Works for me on Unagi with Gecko a9e27af and Gaia ddb38ac

Comment 3

[David Palomino [:dpalomino]]

Hi, 

This has been observed again with ikura, first candidate version for certification in Spain. 

It is not possible to click on any link displayed in the web browser. Tested with several sites, and click on the same links many times. It seems not to be a peformance issue, but just links not working. 

Reopen the bug, adding Spain certification meta dependency, nominating for tef+.

Thanks!
David

Comment 4

[David Palomino [:dpalomino]]

Attachment: log trying to click on links

adding some logs about the issue described in previous comment

Comment 5

[Ben Francis [:benfrancis]]

I can't reproduce on Otoro/Unagi and I don't have an Ikura.

Comment 6

[Ben Francis [:benfrancis]]

Could you say which versions of Gecko and Gaia you are using?

Also can you reproduce this on devices other than the Ikura? I would be surprised if this issue was hardware-specific.

Comment 7

[Beatriz Rodríguez [:brg]]

I agree with you, maybe this issue will not be HW dependant.
The commits used for the certification had been:
gecko 
commit b5183c99228bdc5be33340e359efd1b4f0859e92 
gaia： 
commit 577d13088ebdbd353d13910d3317e713a140415b

Comment 8

[Diego Wilson [:diego]]

Found the root cause. This problem is fixed when I revert the patch from bug 833795

https://bugzilla.mozilla.org/show_bug.cgi?id=833795#c43

Comment 9

[Diego Wilson [:diego]]

Can someone back out the patch while we figure this out? The jitter mentioned in the bug is probably better than unusable links

Comment 10

[Diego Wilson [:diego]]

Just to clarify: this is only an issue on the v1.0.1 and gecko-18 (v1-train?) branches of gecko. It is *not* an issue in master.

So I think the patch from bug 833795 should be backed out from those branches for now.

Do I need to attach new patch files for this or is there a quicker back out process?

Comment 11

[Michael Vines [:m1] [:evilmachines]]

(clearly tef+)

Comment 12

[Daniel Coloma:dcoloma]

Hey Diego, 

 I cannot reproduce this with latest build in 1.0.1 

  * Gecko: f3206d8
  * Gaia: daea430

 Can you please double check before we back-out something that might not be required?

Thanks!

Comment 13

[Diego Wilson [:diego]]

I have checked on several builds and multiple devices. I have confirmation from test teams and it looks like the TID guys can reproduce it too.

How are you testing it? I just open a site (like cnn.com) and try to follow any of the links.

Comment 14

[Daniel Coloma:dcoloma]

(In reply to Diego Wilson [:diego] from comment #13)
> I have checked on several builds and multiple devices. I have confirmation
> from test teams and it looks like the TID guys can reproduce it too.
> 
> How are you testing it? I just open a site (like cnn.com) and try to follow
> any of the links.

The TID folks might be referring to the Ikura build under certification that is quite old (15 days or so), I have checked this with cnn.com and with google.com, both links and forms are working properly. I am using English and Cellular Connection. 

Which are the tips of the most recent build you are using?

Comment 15

[Diego Wilson [:diego]]

Daniel,

I tested using the tip of v1.0.1 as of yesterday
gecko commit f3206d8aa6195772856e940c5e4759d6580bec81
gaia commit daea430624ec02f8d36a12d581fc4a3278c27cb7

I even tested with the commits that worked for you in comment 2

I'm using an inari. And it seems you're using an ikura. May it *is* hardware specific? Do you have access to an inari?

Comment 16

[Daniel Coloma:dcoloma]

(In reply to Diego Wilson [:diego] from comment #15)
> Daniel,
> 
> I tested using the tip of v1.0.1 as of yesterday
> gecko commit f3206d8aa6195772856e940c5e4759d6580bec81
> gaia commit daea430624ec02f8d36a12d581fc4a3278c27cb7
> 
> I even tested with the commits that worked for you in comment 2
> 
> I'm using an inari. And it seems you're using an ikura. May it *is* hardware
> specific? Do you have access to an inari?

Definitely it seems to be Hardware specific, I have tested using an Unagi. I am having trouble in order to update my ikura, but my colleagues that reproduced where using that device. 

Could it be something related with screen sensibility?

Comment 17

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

I can reproduce it on otoro on cnn.com and facebook.com.

Comment 18

[Diego Wilson [:diego]]

(In reply to Anthony Jones (:kentuckyfriedtakahe) from comment #17)
> I can reproduce it on otoro on cnn.com and facebook.com.

Ok, I'm not crazy after all!

Can you help me back it out or figure out what's missing from v1.0.1 and gecko-18 ?

Comment 19

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Nothing obvious. I will just have to debug the issue.

Comment 21

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Attachment: Add mScreenPoint to SingleTouchData;

Comment 22

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Comment on attachment 733729 [details] [diff] [review]
Add mScreenPoint to SingleTouchData;

Should attach patch to bug 833795.

Comment 23

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Backed out 833795.

Comment 24

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Backed out the backout:

https://hg.mozilla.org/integration/mozilla-inbound/rev/bbad31208ebd

Comment 25

[Ryan VanderMeulen [:RyanVM]]

(This shouldn't have been resolved until it hit m-c anyway).

This was backed out because curiously, the original was causing toolkit/content/tests/chrome/test_bug451286.xul to *not* assert anymore when it had previously been asserting 2-5 times. This annotation was done in bug 683159. I backed this out again with the annotation removed, but be wary of possibly tripping this again when you look to re-land.

https://hg.mozilla.org/integration/mozilla-inbound/rev/84d0583cc8cb

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Backed out on the branches.
https://hg.mozilla.org/releases/mozilla-b2g18/rev/38a237247841
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/e66f76c0e4f2

Comment 27

[Ryan VanderMeulen [:RyanVM]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #25)
> This was backed out because curiously, the original was causing
> toolkit/content/tests/chrome/test_bug451286.xul to *not* assert anymore when
> it had previously been asserting 2-5 times. This annotation was done in bug
> 683159. I backed this out again with the annotation removed, but be wary of
> possibly tripping this again when you look to re-land.

*sigh* The joy of bugfixes landing on bustage. I'm pretty sure the test_bug451286 stuff was unrelated to this push and due to another patch that landed around the same time. Make sure you have a green debug mochitest-other in your Try run, but I think you'll be OK.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/84d0583cc8cb

Comment 29

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #25)
> (This shouldn't have been resolved until it hit m-c anyway).

I wasn't sure what to do but now I know for the future. The patch just needs to be backed out. The new patch fixes the problem in a better way.

Comment 30

[Michael Vines [:m1] [:evilmachines]]

Reseting b2g status flags cause I'm pretty sure the new patch for this bug has not landed in v1.1 or v1.0.1 yet.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

*This* issue (a regression caused by bug 833795) is fixed for v1.1 and v1.0.1 via the backout that was performed in comment 26. The status of a new patch for bug 833795 has no bearing on this at this point (except to avoid re-regressing it).

Comment 32

[Diego Wilson [:diego]]

I can confirm this is fixed in 1.0.1. Thanks!

Comment 33

[Jeni]

Verfied fixed on 
Unagi Build ID: 20130409070202
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/3b51ced33215
Gaia: f80afc35f8c63e713b88ec26a0ee7c5af50f4096

and on 

Unagi Build ID: 20130409070205
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/cfef36c0c8bc
Gaia: a80be95f553de517e5d8a159e04511cda5e38be4

User is now able to click on links on www.news.google.com, www.cnn.com, www.facebook.com.

Comment 34

[John Hammink]

Attachment: Another log trying to click on links

Comment 35

[John Hammink]

Attachment: Trying to click on links