Closed Bug 922546 Opened 6 years ago Closed 6 years ago
Open app from card view is flicking
STR: 1. Open any app 2. Long press home button 3. Click the app in cardview Actual: The app flicks several times when coming from cardview to the whole view.
No longer depends on: 920890
See http://youtu.be/SijWOc_K22w Note: this is not a regression of 920890.
Can this be reproduced on a target production device?
Able to repro on Buri 1.2 mozilla RIL using the STR. The app title either flickers or is slow to appear when reappearing from cardview. Build ID: 20131001004003 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/5689e4237ab7 Gaia: 5e0d0df6a762cf1e1812eeb735fba72e2539dc0c Platform Version: 26.0a2
QA Contact: ckreinbring
I was able to narrow down the regression window to between June 24 and June 29. Unfortunately, there are no builds available for us between those dates so I was unable to narrow the window further. 6/24 - No repro Build ID: 20130624031223 Gecko: http://hg.mozilla.org/mozilla-central/rev/76820c6dff7b Gaia: 59c7f4a59157a0bc1c45d705294395f988c509b2 Platform Version: 24.0a1 6/29 - Repro Build ID: 20130629031257 Gecko: http://hg.mozilla.org/mozilla-central/rev/c5ce065936fa Gaia: a8252a4a096431ca7f39b0ce9307957945f77075 Platform Version: 25.0a1
Tim Please review for Systems Platform
Probably a graphic issue (not a Gaia issue).
Component: Gaia::System → General
Component: General → Graphics
Product: Boot2Gecko → Core
Version: unspecified → 26 Branch
If you change the gfx.canvas.azure.accelerated preference to false, does the problem go away?
QA Wanted - Can you try reproducing the bug with the pref mentioned above in comment 7 set to false? Note - https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Changing_preferences shows you how to switch preference son device.
Checked this issue on the latest buri 1.3 build with gfx.canvas.azure.accelerated preference set to false in the prefs.js file. Seems that the issue is somewhat better. I'm not seeing the black flashing on every app, but some apps will flash white for a moment on certain elements. Seeing the white flashing on some marketplace icons and often on the headers in apps like Contacts or Calendar. Environmental Variables: Device: Buri v1.3 Mozilla RIL BuildID: 20131014040204 Gaia: f240abf567325d486c3d0434791b1d132cfa327a Gecko: 211337f7fb83 Version: 27.0a1 Base Image: 20130912
QA Contact: ckreinbring → jzimbrick
koi+ as it is reproducible in 1.2 and 1.3
blocking-b2g: koi? → koi+
6 years ago
Assignee: nobody → sotaro.ikeda.g
I do not see this problem when I could ROMs of v1.2 hamachi and master hamachi and flash them by "./flash.sh -f".
(In reply to ckreinbring from comment #4) > 6/24 - No repro > Build ID: 20130624031223 > Gecko: http://hg.mozilla.org/mozilla-central/rev/76820c6dff7b > Gaia: 59c7f4a59157a0bc1c45d705294395f988c509b2 > Platform Version: 24.0a1 > > 6/29 - Repro > Build ID: 20130629031257 > Gecko: http://hg.mozilla.org/mozilla-central/rev/c5ce065936fa > Gaia: a8252a4a096431ca7f39b0ce9307957945f77075 > Platform Version: 25.0a1 How can I get there ROMs? I do not know from where I could get these old ROMs.
J Zimbrick, does the problem happens on partner's ROM?
(In reply to Sotaro Ikeda [:sotaro] from comment #11) > I do not see this problem when I could ROMs of v1.2 hamachi and master > hamachi and flash them by "./flash.sh -f". It was not correct, I did not see the problem only on master hamachi. On v1.2 hamachi, I saw a problem.
From comment 11, I checked the recent master hamachi's ROM. I still did not saw the problem on hamachi v1.3 Mozilla RIL ROM. Then narrow down the fix range until the following. 10/14 - repro Device: hamachi v1.3 Mozilla RIL Build ID: 20131014080339 Gecko: fadd0d241381ad70ec7d6e357d83f7cce490addb Gaia: 74e7e69d98206bda5c517c0ada57d43de662913e 10/15 - No Repro Device: hamachi v1.3 Mozilla RIL Build ID: 20131015 Gecko: c079fe98d21fc2c24dbf333d1341855c9280f3d0 Gaia: 17e871ae1f82699793e3cd28acda805ba724a8b6
From comparing gecko and gaia's git log, Bug 926535 seems to related to this bug.
By applying a patch in Bug 926535, the problem seems fixed.
Alive, how do you think about comment 17?
Oh, no. But I don't see why yet..the app is crashing because of getScreenshot call? It's calling |drawWindow| only.
Ignore my previous comment. Sotaro, I think this issue does happen before that commit.
https://bugzilla.mozilla.org/show_bug.cgi?id=922546#c0 Bug filed at 10/01 https://bugzilla.mozilla.org/show_bug.cgi?id=926535#c0 The commit at 10/14
Alive, is there no problem to uplift attachment 816686 [details] [diff] [review] in Bug 926535? By applying the patch, the problem was fixed on v1.2 hamachi.
Looks like I misunderstood again.... Yes I think the patch is not harmful.
From comment 24, change to system app category and un-assign myself from the bug.
Assignee: sotaro.ikeda.g → nobody
Component: Graphics → Gaia::System
Product: Core → Firefox OS
Version: 26 Branch → unspecified
Alive, comment 24, can this bug be handled by system app?
But why does that fix the flicking? It only changes the way from wait for NextPaint to getScreenshot(canvas.drawWindow).
(In reply to Alive Kuo [:alive][11/4-11/8 at SFO ww.] from comment #27) > But why does that fix the flicking? It only changes the way from wait for > NextPaint to getScreenshot(canvas.drawWindow). Rendering with reflow seems to make a rendering unstable. Bug 926535 changed to wait an app fully repainted.
I checked v1.1 hamachi. On v1.1 hamachi, no flickeing and no wait. It is ideal. But v1.2 is already almost fixed. Therefore for v1.2, it is better to apply Bug 926535. But for v1.3, we have to achive no wait and no flickering. I am going to create a bug for it. It is already talked with Andrew Overholt.
For 1.2, bug 926535 will be the somewhat paper-over fix (so clearing the koi+ here). This can be closed once bug 926535 lands and the fix is verified. For 1.3, bug 936200 will be the proper fix.
blocking-b2g: koi+ → ---
In that case, I'm going to dupe this to bug 926535 which is tracking the fix for the regression and I'll treat bug 936200 as a followup to that bug. Probably not worthwhile at this point to keep this bug around.
No longer blocks: 936200
Status: NEW → RESOLVED
Closed: 6 years ago
No longer depends on: 926535
Resolution: --- → DUPLICATE
Duplicate of bug: 926535
You need to log in before you can comment on or make changes to this bug.