Closed Bug 1037724 Opened 10 years ago Closed 10 years ago

[B2G][Browser]Selecting the status bar while in the Browser app will cause the Browser app to be non-responsive

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.4 unaffected, b2g-v2.0 affected, b2g-v2.1 unaffected)

RESOLVED DUPLICATE of bug 1042009
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- affected
b2g-v2.1 --- unaffected

People

(Reporter: jschmitt, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [2.0-daily-testing])

Attachments

(1 file)

Attached file log.txt
Description:
After selecting the Status bar while on a website the Browser app then becomes non-responsive.

Repro Steps:
1) Update a Flame to 20140711000201
2) Connect to Data/Wifi network
3) Load Browser app
4) Load any webpage e.g. cnn.com
5) Tap on the Status bar
6) Attempt to scroll on the page or select a link

Actual:
The Browser app is non-responsive.

Expected:
The Browser app is can still be interacted with after selecting the Status bar.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0)
Firmware Version: v122

User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Notes:
Repro frequency: 100%
Link to failed test case:
See attached: Logcat
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Qawanted for branch checks.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
This bug had previously been reported, however when I updated my base image I could no longer reproduce it 

https://bugzilla.mozilla.org/show_bug.cgi?id=1036012
it still reproduces on my dogfood device which has not been updated, but works on both central and aurora on my dev devices which has the most up to date gonk
This issue no longer reproduces on the latest 2.0 Flame build.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140718114522
Gaia: 9ef6afcf1d2ffd14631f13330bbe5a309687924b
Gecko: 943e0e47d815
Version: 32.0a2 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

The browser does not become unresponsive after pressing the status bar.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: jmercado
Multiple parties have been unable to Repro this in the latest. Closing as WFM. Please re-open if it shows back up.
Status: NEW → RESOLVED
Closed: 10 years ago
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Resolution: --- → WORKSFORME
Issue still repros on 2.0 Flame. Per on Comment 2 I am currently on Base v122.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140721000201
Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko: 4bd4b0ae7bbe
Version: 32.0a2 (2.0)
Firmware Version: v122

User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Status: RESOLVED → REOPENED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Resolution: WORKSFORME → ---
QAWanted to confirm comment 6.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
QA Contact: jmercado → ckreinbring
The bug repros on Flame 2.0 and Buri 2.0

Flame 2.0
Build ID: 20140721000201
Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko: 4bd4b0ae7bbe
Platform Version: 32.0a2
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 2.0
Build ID: 20140721000201
Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko: 4bd4b0ae7bbe
Platform Version: 32.0a2
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual result: After navigating to a site that will require scrolling, the user will be unable to scroll if they tap the status bar for about a second.  Long enough for the date to appear and remain on the status bar.

--------------------------------------------------------------------------------------------------------

The bug does not repro on Flame 2.1 or Flame 1.4

Flame 2.1
Build ID: 20140721062116
Gaia: Unknown due to bug 1039739
Gecko: 0dc711216018
Platform Version: 33.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Flame 1.4
Build ID: 20140721000201
Gaia: 621d152f89347c79619aa909ad62cc2ac9d3ab5b
Gecko: 83b7be7fb33f
Platform Version: 30.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Actual results: After navigating to a site that will require scrolling, the user will still be able to scroll if they tap the status bar for about a second.  The status bar date will appear, but disappear once the status bar is no longer being tapped.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: regression
These two bugs seem to be caused by the same issue.  When the status bar freezes in 1042009 the notification try, the date can be seen and the browser no longer functions.  The user can fix this by touching the draw down, hidden by the status bar.

When reproducing this bug, the user can press the home button but will not be able to interact with the homescreen just as in bug 1042009 until the notification tab is dismissed.
Depends on: 1042009
Why wouldn't this be a dupe of bug 1042009?
Flags: needinfo?(jmitchell)
It does indeed seem to be the same bug and since bug 1042009 already has a regression window complete, is marked a blocker and is generally further along I'll close this as a 'future-dupe' Sorry Josh S!
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Flags: needinfo?(jmitchell)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: