While in Private Window, status bar color repaint is noticeable while expanding Rocketbar from collapsed

RESOLVED DUPLICATE of bug 1132741

Status

RESOLVED DUPLICATE of bug 1132741
4 years ago
4 years ago

People

(Reporter: pcheng, Unassigned)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.5?, b2g-v2.2 unaffected, b2g-master affected)

Details

(Whiteboard: [3.0-Daily-Testing])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 8564396 [details]
logcat on Flame 3.0

Description:
Browser app allows user to expand/collapse the URL bar. While doing this transition, status bar and the top of browser show a unified color. This unified color effect is lost while in Private Window.

STR:
0) Connect to internet
1) Open Browser app and access Private Window
2) Browse to a website
3) While on that website, swipe finger upwards to minimize the rocketbar, and swipe finger downwards to maximize the rocketbar; observe the status bar color while doing so.

Expected: Status bar background color remains the same color as top of browser while doing step 3

Actual: Status bar background color briefly shows black when expanding Rocketbar before it shows purple

Notes:
1) This issue also occurs on regular browsing session, but it's barely noticeable since it shows white/very light gray when transitioning.
2) Repro rate: 8/10
3) Attaching a log cat
4) Video of issue:

https://www.youtube.com/watch?v=KSl3DgakS9I
(Reporter)

Comment 1

4 years ago
This issue occurs on Flame 3.0.

Device: Flame 3.0
BuildID: 20150213010213
Gaia: 2a2b008f9ae957fe19ad540d233d86b5c0b6829e
Gecko: 2f5c5ec1a24b
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

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

This issue does NOT occur on Flame 2.2. Status bar color remains the same as browser color when expanding/collapsing rocketbar.

Device: Flame 2.2
BuildID: 20150213002503
Gaia: ea64caf6d4ab03fc4472eca9f41f20d651d55fa9
Gecko: d04b78eeb536
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.2: --- → unaffected
status-b2g-master: --- → affected
Component: Gaia::Browser → Gaia::System
Flags: needinfo?(ktucker)
Keywords: regression
OS: Linux → Gonk (Firefox OS)
Hardware: x86 → ARM
Whiteboard: [3.0-Daily-Testing]
[Blocking Requested - why for this release]:

This is a regression and looks bad so nominating 3.0?
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
QA Contact: bzumwalt
Central Regression Window:

Unable to finish full window before end of day. Central build window is below. Leaving keyword until I finish Either Mozilla-Inbound or B2G-Inbound window on Tuesday morning.

Last working central:
Device: Flame 3.0
Build ID: 20150211221340
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 3094601af679
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

First broken central:
Device: Flame 3.0
Build ID: 20150212064620
Gaia: 2a2b008f9ae957fe19ad540d233d86b5c0b6829e
Gecko: 81f979b17fbd
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0


Working Gaia with Broken Gecko issue DOES reproduce:
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 81f979b17fbd

Working Gecko with Broken Gaia issue does NOT reproduce:
Gaia: 2a2b008f9ae957fe19ad540d233d86b5c0b6829e
Gecko: 3094601af679


Central Gecko Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3094601af679&tochange=81f979b17fbd
Are we sure this is a regression? I think you are talking about the Yahoo! header here not being aligned? In this case this would probably be a bug with the website, and not rocketbar.
This is actually with the status bar color versus the expanded rocketbar color. It doesn't have anything to day with the site you use since I tested the window with Google search results and the Mozilla website. The private browsing rocketbar/status bar color seems to be hard set as purple.
Mozilla-Inbound Regression Window:

Last working Mozilla-Inbound build:
Device: Flame 3.0
Build ID: 20150211190942
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 6ed69c4d2c15
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

First broken Mozilla-Inbound build:
Device: Flame 3.0
Build ID: 20150211230942
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 07479758ab68
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0


Working Gaia with Broken Gecko issue DOES occur:
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 07479758ab68

Working Gecko with Broken Gaia issue does NOT occur:
Gaia: d5a71cedb37dd45f439f672489db3994b349ac43
Gecko: 6ed69c4d2c15


Mozilla-Inbound Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6ed69c4d2c15&tochange=07479758ab68


Issue appears to occur due to changes made in bug 1127066
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Here is another one Botond that might be caused by the work done on bug 1127066
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Depends on: 1127066
Flags: needinfo?(ktucker) → needinfo?(botond)
Please make regressions block the regressing bug.
Blocks: 1127066
No longer depends on: 1127066
This one is also fixed by the patch on bug 1132741 as it has the same root cause.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(botond)
Resolution: --- → DUPLICATE
Duplicate of bug: 1132741
You need to log in before you can comment on or make changes to this bug.