[Browser] Rocketbar functionality breaks after accessing a website that requires authentication upfront

VERIFIED DUPLICATE of bug 1157128

Status

defect
VERIFIED DUPLICATE of bug 1157128
4 years ago
4 years ago

People

(Reporter: pcheng, Assigned: apastor)

Tracking

({regression})

unspecified
2.2 S11 (1may)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master unaffected)

Details

(Whiteboard: [3.0-Daily-Testing], [systemsfe])

Attachments

(1 attachment)

Posted file logcat on Flame 2.2
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

4 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?]
Flags: needinfo?(ktucker)
Keywords: regression
Whiteboard: [3.0-Daily-Testing], [systemsfe]
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)
(Reporter)

Updated

4 years ago
QA Contact: pcheng
blocking-b2g: 2.2? → 2.2+
Ben, can you take a look?
Flags: needinfo?(bfrancis)
(Reporter)

Comment 4

4 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)
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

4 years ago
Assignee: nobody → apastor
Flags: needinfo?(apastor)
(Assignee)

Updated

4 years ago
Depends on: 1157631
(Assignee)

Comment 6

4 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)
Thanks for taking this Alberto!
Flags: needinfo?(bfrancis)
(Reporter)

Comment 8

4 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

4 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.
Target Milestone: --- → 2.2 S11 (1may)
(Assignee)

Comment 10

4 years ago
:piwei, could you please check again, now that  bug 1157431 has landed? Thanks!
Flags: needinfo?(pcheng)
(Reporter)

Comment 11

4 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

4 years ago
Adding verifyme to be checked when 1157128 bug lands in 2.2.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1157128
(Assignee)

Updated

4 years ago
Keywords: verifyme
(Reporter)

Comment 13

4 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.
The patch has not been merged to v2.2 yet. I think we need to wait for it.
Pi Wei, I think it is good to go. ;)
(Reporter)

Comment 16

4 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
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.