908385 - First button / input on a page is hard to press

Status: RESOLVED WORKSFORME

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

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: logcat.txt

"gecko" revision="2ab07dec6404"
"gecko" revision="506173515d7eb416d2184518e7cd4369ef7135e1"
"gaia" revision="abd81ff5e49bf0c9479cdc5c5eb6975cc776f632"
Build ID: 2013-08-22-04-02-02
MC/master build
Buri

1. launch browser
2. go to http://people.mozilla.com/~nhirata/html_tp/js_dialog_test.html
3. click on the button

Expected: JS dialogs
Actual: nothing happens

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hi Blassey, this is blocking me from verifying Bug 839194

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

Dale, what were you using to test when you fixed bug 839194?

Comment 3

[Dale Harvey (:daleharvey)]

http://junk.arandomurl.com/test.html

Comment 4

[Dale Harvey (:daleharvey)]

This I think is an interesting thing I noticed while I was testing my version

I had to put an empty button at the top as I could only reliably click on the second and after buttons, the first one was impossibly hard to press, I just managed it with Naoki's now but it took quite a few clicks.

Forgot to file, apologies

Comment 5

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Could this also be a dup of bug 907977?

I was able to tap the button...

Comment 6

[Dale Harvey (:daleharvey)]

Nope, this was fairly strange in that it was only the first button in a page that was hard to press, updating the description

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

Jason, why did you nominate this?

Comment 8

[Jason Smith [:jsmith]]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #7)
> Jason, why did you nominate this?

Looked like a touch events regression with an input button (which might be a APZC regression in kats area of expertise), which seems quite basic that an operator would likely block on in IOT if it's a confirmed regression from 1.1 (we've also had a lot of regressions this area recently). I'm switching to qawanted here to find out if this reproduces on 1.1. If it does reproduce, then we probably don't need to block. If it does reproduce, then we probably do need to block.

Comment 9

[sarsenyev]

The issue still reproduces on Leo MOZ RIL 1.1
The link button doesn't work when pressing the first time on the original size page, if before tapping the link enlarge the page first and then tap, the issue doesn't reproduce, but if tapping the link on the original size page and then enlarge it the issue still reproduces
Repro frequency: about 3 of 5 times 75%

Build ID: 20130916041201
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/bebaca30ea30
Gaia: 8b20ff956f8e366a17a7ef5f64935a6a6a8cb0c0
Platform Version: 18.1
Firmware revision: D300f10a

Comment 10

[Jason Smith [:jsmith]]

(In reply to sarsenyev from comment #9)
> The issue still reproduces on Leo MOZ RIL 1.1
> The link button doesn't work when pressing the first time on the original
> size page, if before tapping the link enlarge the page first and then tap,
> the issue doesn't reproduce, but if tapping the link on the original size
> page and then enlarge it the issue still reproduces
> Repro frequency: about 3 of 5 times 75%
> 
> Build ID: 20130916041201
> Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/bebaca30ea30
> Gaia: 8b20ff956f8e366a17a7ef5f64935a6a6a8cb0c0
> Platform Version: 18.1
> Firmware revision: D300f10a

Okay, then that makes this a non-blocker if it's being shipped as a known bug in 1.1.

Comment 11

[Gregor Wagner [:gwagner]]

Does this still reproduce?