Closed Bug 1030172 Opened 10 years ago Closed 10 years ago

The first touch after newly launching an app in B2G is lost

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Platform:
All
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
b2g-v1.3 --- affected
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.1 --- affected

People

(Reporter: cwiiis, Unassigned)

References

(
URL
)

Details

STR.

1. Launch the browser
2. Tap the URL bar

Expected:

The awesome screen is displayed.

Actual:

Nothing happens. A second touch brings up the awesome screen.
QA Wanted to do branch checks.
Keywords: qawanted
QA Contact: ddixon
I used the STR in Comment 0. 

I found that after opening the Browser App, the user must tap the Search field immediately to reproduce the issue.  

Video of the bug: https://www.youtube.com/watch?v=Isw_xXHNe9A

----------------------------------------------------------------
Flame 2.0   Issue DOES occur here. 

Environmental Variables:
Device: Flame 2.0
Build ID: 20140625124605
Gaia: c478c43229883cee2afd09c6edb42d29a46cc500
Gecko: 8940337ccb5c
Version: 32.0a2 (2.0)
Firmware Version: v122
----------------------------------------------------------------
Flame 2.1  Issue DOES occur here. 

Environmental Variables:
Device: Flame Master
Build ID: 20140626051603
Gaia: 87a7746568ac5708e828026160c0732ba252300f
Gecko: bd03647cca20
Version: 33.0a1 (Master)
Firmware Version: v122
----------------------------------------------------------------
Flame 1.4 Issue DOES occur here. 

Environmental Variables:
Device: Flame 1.4
Build ID: 20140610034016
Gaia: c39db439202b29897bee9896bc789e6782809f3a
Gecko: edd648be2b07
Version: 30.0 (1.4)
Firmware Version: v122
----------------------------------------------------------------
Buri 2.1  Issue DOES occur here. 

Environmental Variables:
Device: Buri Master
Build ID: 20140626063403
Gaia: 87a7746568ac5708e828026160c0732ba252300f
Gecko: 4c9d8c885791
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg
----------------------------------------------------------------
Bur 1.4  Issue DOES occur here. 

Environmental Variables:
Device: Buri 1.4
Build ID: 20140610034016
Gaia: c39db439202b29897bee9896bc789e6782809f3a
Gecko: edd648be2b07
Version: 30.0 (1.4)
Firmware Version: v1.2device.cfg
----------------------------------------------------------------
Buri 1.3  Issue DOES occur here. 

Environmental Variables:
Device: Buri 1.3
Build ID: 20140502004836
Gaia: 667539f1ed4becc45b182a5f1046221d3eeb9e7c
Gecko: 084f8c2adae5
Version: 28.0 (1.3)
Firmware Version: v1.2device.cfg
URL: https://www.youtube.com/watch?v=Isw_x...
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Not a regression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
QA Wanted - the branch checking might be incorrect above. According to No-Jun, the speed for touch interaction has become worse between 1.4 --> 2.0. Can we check to see if the first touch interaction between 1.4 & 2.0 has become worse.
QA Whiteboard: [QAnalyst-Triage+][lead-review+]
status-b2g-v1.3: affected → ---
status-b2g-v1.4: affected → ---
Keywords: qawanted
Just to add, this is most prominent immediately after rebooting the phone and entering the homescreen.  Same symptom is shown when doing Homescreen icon touch and settings menu selection.  once first touch is lost, it is fine for a while.  Looks like to me the touch could be lost while the phone is busy doing background works.
Also happens right after a lot of homescreen scrolling, then tapping the icon.
(In reply to No-Jun Park [:njpark] from comment #6)
> Also happens right after a lot of homescreen scrolling, then tapping the
> icon.

This is probably the (intentional) result of bug 1022956.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #7)
> (In reply to No-Jun Park [:njpark] from comment #6)
> > Also happens right after a lot of homescreen scrolling, then tapping the
> > icon.
> 
> This is probably the (intentional) result of bug 1022956.

I think you're right.  now that i look at it, I don't think it's the regression.  Jsmith, I think we can clear the qawanted flag on it?
Flags: needinfo?(jsmith)
These are my findings despite the flags here being possible removed. 

I do not notice any significant difference between the 1.4 and 2.0 Flame concerning how this bug behaves. 

I reproduced the bug after flashing, after rebooting, on eng. builds, and non-eng. builds. 

Environmental Variables:
Device: Flame 2.0
Build ID: 20140703085751
Gaia: 5725321dd1aef29077b6fc5c4c49b43dccf208dc
Gecko: 13aa5be377b0
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/30.0

Environmental Variables:
Device: Flame 1.4
Build ID: 20140703063016
Gaia: 71aa8a3697e8daacdaee3d447a38ee10f13d5b54
Gecko: 1bae550358a6
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Flags: needinfo?(jmitchell)
Keywords: qawanted
Sure.
status-b2g-v1.3: --- → affected
status-b2g-v1.4: --- → affected
Flags: needinfo?(jsmith)
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
blocking-b2g: 2.0? → ---
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Can anybody still reproduce this on master or 2.0? I tried just now but it seems to have been fixed.
Duane - can you see if this repros in the latest 2.0 and Master?
Keywords: qawanted
Actual Results: Immediately after opening Browser App, user can tap multiple times in search bar and Awesome Screen does not appear.  

Tested on the latest Flame 2.0 and Flame Master builds. 

Video link: https://www.youtube.com/watch?v=Isw_xXHNe9A

Environmental Variables:

Device: Flame Master
Build ID: 20140715124212
Gaia: 0910be495385d90acdeaddbeaf1fba315aff57b0
Gecko: 7883d8e9f210
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Device: Flame 2.0
Build ID: 20140715121110
Gaia: db0358b53488a941ced352d890802342d7ced00e
Gecko: c6fa05ca9775
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flags: needinfo?(jmitchell)
Keywords: qawanted
The video in comment 13 shows a slightly different issue from what this bug was originally filed about. This bug was originally tracking a problem where the first tap after opening the app (and ONLY the first tap) had no effect at all.

In the video the first tap brings up the keyboard without opening the awesomescreen, so there is *some* effect, and it persists across multiple taps. This looks more like the browser glitches into a bad state where it thinks the awesomescreen is displayed but isn't really.

Nonetheless I'll leave this bug open for now and re-evaluate once bug 1009733 lands.
Flags: needinfo?(jmitchell)
I tested some more on the latest master build and conferred with Chris (who filed this bug) on IRC. We agreed that this bug isn't happening any more. At least not the same behaviour that this bug was filed for. there might still be a browser-specific bug that is triggered in some scenarios such as the comment 13 video shows.

I'm going to close this one as WFM for now.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.