Closed
Bug 1157432
Opened 9 years ago
Closed 9 years ago
[Browser] Rocketbar functionality breaks after accessing a website that requires authentication upfront
Categories
(Firefox OS Graveyard :: Gaia::Browser, defect)
Tracking
(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master unaffected)
Tracking | Status | |
---|---|---|
b2g-v2.1 | --- | unaffected |
b2g-v2.2 | --- | verified |
b2g-master | --- | unaffected |
People
(Reporter: pcheng, Assigned: apastor)
References
Details
(Keywords: regression, Whiteboard: [3.0-Daily-Testing], [systemsfe])
Attachments
(1 file)
126.73 KB,
text/plain
|
Details |
Description: Browser's rocketbar becomes unresponsive after accessing a website that requires authentication upon accessing. STR: 1) Open browser and access http://tiv-fmz.homeip.net (or the pvt website mentioned below) 2) Long press Home button and kill the process 3) Open browser again 4) Try to use the rocketbar by tapping on it Expected: Rocketbar is usable Actual: Rocketbar is not usable; tapping on it does absolutely nothing. User needs to restart the device to recover from this state. Rocketbar outside of Browser still works when in this state. This issue seems to occur on all websites that requires authentication upon accessing. I've tried https://pvtbuilds.mozilla.org/pvt/mozilla.org/ and it occurs on that as well. Repro rate: 5/5 See video: https://www.youtube.com/watch?v=bDi8gnJbjwM Also attaching a logcat. Device: Flame 2.2 (full flashed 319MB KK) BuildID: 20150422002505 Gaia: 41a85c5f9db291d4f7c0e94c8416b5115b4ee407 Gecko: a87a05e7d0ef Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Reporter | ||
Comment 1•9 years ago
|
||
3.0 and 2.1 are unaffected. Browser rocketbar remains functional after accessing those websites. Device: Flame 3.0 BuildID: 20150422010202 Gaia: 15134b080b5f406e5aa36f5136c17dafb4e31f64 Gecko: 946ac85af8f4 Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b Version: 40.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0 Device: Flame 2.1 BuildID: 20150422001201 Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c Gecko: 685fa69b59dc Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1:
--- → unaffected
status-b2g-v2.2:
--- → affected
status-b2g-master:
--- → unaffected
Flags: needinfo?(ktucker)
Keywords: regression
Whiteboard: [3.0-Daily-Testing], [systemsfe]
Comment 2•9 years ago
|
||
Nominating this 2.2? since this a regression and only affects this particular branch. The rocketbar will break in the browser and the user will have to restart their phone for it to work again. Let's get a fix window on this.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Reporter | ||
Updated•9 years ago
|
QA Contact: pcheng
Updated•9 years ago
|
blocking-b2g: 2.2? → 2.2+
Reporter | ||
Comment 4•9 years ago
|
||
I cannot reproduce this bug anywhere on 3.0 branch. The following is the actual window on v2.2 branch. b2g-37 regression window: Last Working Device: Flame BuildID: 20150417014737 Gaia: 3ee276bd8ede9752054450a30546e7ecbddc6f17 Gecko: 95b685ac8d9a Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 First Broken Device: Flame BuildID: 20150417111639 Gaia: bcaba2b4ab50dd54dc17e58b0ba6e57b6107c852 Gecko: 67376ec9bae0 Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Last Working Gaia First Broken Gecko - issue does NOT repro Gaia: 3ee276bd8ede9752054450a30546e7ecbddc6f17 Gecko: 67376ec9bae0 Last Working Gecko First Broken Gaia - issue DOES repro Gaia: bcaba2b4ab50dd54dc17e58b0ba6e57b6107c852 Gecko: 95b685ac8d9a Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/3ee276bd8ede9752054450a30546e7ecbddc6f17...bcaba2b4ab50dd54dc17e58b0ba6e57b6107c852 Caused by Bug 1150834. I did a local gaia revert of bug 1150834 and issue did not reproduce after the revert.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Comment 5•9 years ago
|
||
Alberto, can you take a look at this please? This looks to have been caused by the uplift for bug 1150834.
Blocks: 1150834
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(apastor)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → apastor
Flags: needinfo?(apastor)
Assignee | ||
Comment 6•9 years ago
|
||
The fact that reverting the bug makes the rocketbar clickable again shows that is obviously related, but given that this is not happening in 3.0 makes me think that there is something else. I noticed that the rocketbar behaves differently after closing the browser on an Auth dialog, and I think that's related. I created bug 1157631 to see if we can find the patch that created this bug in 2.2 (or the one that fixed it in 3.0) Thanks!
Flags: needinfo?(pcheng)
Reporter | ||
Comment 8•9 years ago
|
||
I noticed that bug 1150834 landed on master on 4/8. I'll check master around that timeframe and see if I can repro the bug at all. I tried a build on 4/11 and couldn't repro, so if it ever reproduced on master it'll be a very short timeframe.
Flags: needinfo?(pcheng)
Reporter | ||
Comment 9•9 years ago
|
||
I can confirm that this bug has never occurred on master. My test shows the following central builds don't reproduce the bug: 20150408094109 - no repro 20150408150105 - no repro It is possible that as comment 6 mentioned that something else is the root cause of this bug, and patch for 1150834 revealed the bug. I'll go ahead and work on bug 1157631 to see if it is the root cause.
Updated•9 years ago
|
Target Milestone: --- → 2.2 S11 (1may)
Assignee | ||
Comment 10•9 years ago
|
||
:piwei, could you please check again, now that bug 1157431 has landed? Thanks!
Flags: needinfo?(pcheng)
Reporter | ||
Comment 11•9 years ago
|
||
I assume you meant bug 1157631. 1157631 was marked a dupe of bug 1157128, however it has not been uplifted to v2.2, and this bug is v2.2 only. I'll check this bug once that has been uplifted. Keeping NI.
Assignee | ||
Comment 12•9 years ago
|
||
Adding verifyme to be checked when 1157128 bug lands in 2.2.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 13•9 years ago
|
||
Is this bug ready for verify? I don't understand what's going on with bug 1157128, specifically whether it's been uplifted to v2.2.
Comment 14•9 years ago
|
||
The patch has not been merged to v2.2 yet. I think we need to wait for it.
Comment 15•9 years ago
|
||
Pi Wei, I think it is good to go. ;)
Reporter | ||
Comment 16•9 years ago
|
||
This issue is verified fixed on Flame 2.2. Or rather, verified duplicate of bug 1157128. Rocketbar functionality remains usable after STR. Device: Flame 2.2 BuildID: 20150512002502 Gaia: c4c1bf443f2b01c2ba918780510fd4c639a3c360 Gecko: 70782f19acbf Gonk: ab265fb203390c70b8f2a054f38cf4b2f2dad70a Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(pcheng) → needinfo?(ktucker)
Keywords: verifyme
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•