Closed
Bug 1196194
Opened 9 years ago
Closed 9 years ago
Edge gesture race condition results in incorrect system icon colors (e.g., white icons on a light background)
Categories
(Firefox OS Graveyard :: Gaia::System::Status bar, Utility tray, Notification, defect, P2)
Firefox OS Graveyard
Gaia::System::Status bar, Utility tray, Notification
All
Other
Tracking
(blocking-b2g:2.5+)
People
(Reporter: callahad, Assigned: apastor)
References
Details
(Keywords: foxfood, polish, Whiteboard: [systemsfe])
Attachments
(4 files)
>> Feature Request Summary: Edge gesture race condition results in incorrect system icon colors (e.g., white icons on a light background) >> Description of feature, or problem to be solved This can be tricky to repro, but it is possible. It's possible to trigger a race condition with edge gestures which results in the wrong system icon theme being applied. E.g., the Notes app has a dark background and white icons, while the Browser has a light background and black icons. STR: 1. Have the following apps open in the overview: [Notes, Browser on some webpage] 2. In the browser, press and hold a link. Choose "Open in new window." 3. Immediately swipe "backwards" (from left edge inward) to attempt to switch back to the originating browser window. What should happen: 1. The originating webpage (Site A) is displayed 2. Site A appears correctly. 3. The window overview has the state [Notes, Site A, Site B] What actually happens: 1. The screen flashes and the new webpage (Site B) is displayed 2. Swiping "forwards" (from right edge inward) reveals the Notes app hiding behind the currently displayed page. 3. (Occasionally) Swiping "backwards" switches to Notes with the wrong icon coloration. 4. The window overview has the state [Site A, Notes, Site B] When the bug reproduces, repeating the backwards swipe in step 3 will switch to the Notes application *again,* as if there were two side-by-side instances, but with the right coloration. Swiping forwards will take you to Site B. I've been able to reproduce this in both directions: making the browser icons light instead of dark, and making the Notes icons dark instead of light. See screenshots.
Reporter | ||
Comment 1•9 years ago
|
||
Reporter | ||
Comment 2•9 years ago
|
||
Updated•9 years ago
|
Component: Gaia::System::Window Mgmt → Gaia::System::Status bar, Utility tray, Notification
Comment 3•9 years ago
|
||
We fixed a bunch of bugs in this area. Do you still see this issue?
Flags: needinfo?(dan.callahan)
Updated•9 years ago
|
Whiteboard: [systemsfe]
Reporter | ||
Comment 4•9 years ago
|
||
Yep, I can still repro with build eng.naoki.20151007.074137 / 20151023101519 / sha 410e91dd from 2015-10-23
Flags: needinfo?(dan.callahan)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → apastor
Assignee | ||
Comment 5•9 years ago
|
||
Could you please upload a video? I'm not able to repro with the specified STR. Thanks!
Flags: needinfo?(dan.callahan)
Reporter | ||
Comment 7•9 years ago
|
||
Additional recordings up at http://people.mozilla.org/~dcallahan/tmp/bug1196194/
Reporter | ||
Comment 8•9 years ago
|
||
Potentially related to Bug 1221230
Comment 9•9 years ago
|
||
Assignee | ||
Comment 10•9 years ago
|
||
Dan, thanks for the videos. They helped a lot! The bug is more severe than it seems. Is not that the statusbar colors are wrong, but the appWindowManager thinks that the activeWindow is 'Notes'. That's really bad an can create several problems. Could you please verify that the patch helps? I took a different path, and instead of openning the new window, I open the Notes app (as is the last action the user performed). I need to verify that the order in the task switcher is correct, so that may be wrong with the patch at the moment. Could you also verify if it fixes bug 1221230? Thanks!
Flags: needinfo?(dan.callahan)
Assignee | ||
Comment 11•9 years ago
|
||
[Blocking Requested - why for this release]: Despite the use case is kind of 'edgy' (literally), the results are really bad, as the AppWindowManager will treat a hidden window as the current active.
blocking-b2g: --- → 2.5?
Updated•9 years ago
|
blocking-b2g: 2.5? → 2.5+
Updated•9 years ago
|
Priority: P1 → P2
Reporter | ||
Comment 12•9 years ago
|
||
Woo! I'm able to repro on a Flame. Applying the GitHub patch to that and checking if it still repros.
Reporter | ||
Comment 14•9 years ago
|
||
The GitHub patch appears to resolve this for me on a Flame.
Flags: needinfo?(dan.callahan)
Assignee | ||
Updated•9 years ago
|
Attachment #8683114 -
Flags: review?(etienne)
Assignee | ||
Updated•9 years ago
|
Target Milestone: --- → 2.6 S1 - 11/20
Comment 15•9 years ago
|
||
Comment on attachment 8683114 [details] [review] [gaia] albertopq:1196194-edge-race > mozilla-b2g:master Small nit on github, but this is really good!
Attachment #8683114 -
Flags: review?(etienne) → review+
Assignee | ||
Comment 16•9 years ago
|
||
master: https://github.com/mozilla-b2g/gaia/commit/4019a15121359c470765dd06e94850dd64cdf8d9
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 17•9 years ago
|
||
Alberto, Can you please set the 2.5 uplift request flag and answer questions that follow. Will help uplift the patch. Thanks.
You need to log in
before you can comment on or make changes to this bug.
Description
•