Closed Bug 1037724 Opened 11 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: