Closed Bug 1160277 Opened 5 years ago Closed 4 years ago
[Homescreen] Edit Mode Screen Color transition is slow to normalize
Description: When the user is attempting to move icons around on their homescreen (hold-tap to move and enter 'Edit Mode'), they will observe that the 'group-window' colors that contain all icons will 'glow' blue when an icon being shifted is hovering over that group. When an icon is released into a group of this nature, the user will observe the color of the screen transition back to the matte gray of the 'Edit Mode'. However, the transition seems to lag behind the actual actions taken by the user. Repro Steps: 1) Update a Flame to 20150430010201 2) Hold tap on an icon on homescreen 3) Observe 'Edit Mode' group color (glow blue) 4) Release icon to drop into group 5) Observe group color transition from blue to gray Actual: Group Color transition lags behind actual action of user Expected: Group Color transition enacts quickly following the actions taken by user Environmental Variables: ------------------------------- Device: Flame 3.0 Build ID: 20150430010201 Gaia: db8ea705c0fd1b1684807f5a8e837bb9a36a6f96 Gecko: 4b9b12c248dc 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.2 BuildID: 20150430002504 Gaia: aa1da5036f9425c25d515d14243d3473bfefb4fd Gecko: 38b2838d43e1 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 ------------------------------- Issue DOES NOT REPRO on 2.1 for flame devices: Results: Screen color does not transition in edit mode when moving icons; no manueverable groups. Device: Flame 2.1 BuildID: 20150430001201 Gaia: 7cd76434b58be2cfef7d23451e668c76591f05c3 Gecko: b5d2472c2940 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 ------------------------------- Repro frequency: 5/5 See attached: video- https://youtu.be/PUAeyess45E logcat
QA Whiteboard: [QAnalyst-Triage?]
Although a minor performance regression, it adds to the slow to respond feel for user actions. Requesting a window.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][systemsfe]
Nevermind, not a regression the highlighting is a new feature for 2.2. NI on component owner for nomination decision.
This bugs me actually, I'll try to get it fixed.
Assignee: nobody → chrislord.net
Status: NEW → ASSIGNED
Unassigning now that verticalhome isn't the default. My thoughts on fixing this: The colour transition is slow because we're transitioning background-color, which doesn't run on the compositor. Instead of doing this, I'd add an extra element with the blue background colour that transitions opacity - this should run smoothly (and once the transition finishes, the layer should be flattened, so shouldn't be an overdraw issue).
Assignee: chrislord.net → nobody
Status: ASSIGNED → NEW
Mass update: Resolve wontfix all issues with legacy homescreens. As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.