Closed Bug 949458 Opened 7 years ago Closed 7 years ago
(Nexus 7 2012) - the tabs button is wrongly displayed after open a link in new tab
198.88 KB, image/png
74.77 KB, image/png
197.83 KB, image/png
1.31 KB, patch
|Details | Diff | Splinter Review|
Environment: Device: Google Nexus 7 (Android 4.4) Build: Nightly 29.0a1 (2013-12-12) Steps to reproduce: 1. Start fennec; 2. Tap on the url bar; 3. Long tap on a site from the Top sites; 4. Select 'Open in New Tab'; 5. Repeat steps 3 and 4. 6. Check if the tabs button is correctly displayed. Expected result: The tabs button, back button, refresh button and options button are correctly displayed. Actual result: The tabs button, back button, refresh button and options button are messed out. Note: Can not reproduce on other device. Might be reproducible only on android 4.4. Please check the video: https://www.youtube.com/watch?v=PcAMK6LPzSk Please check the file attached.
I tried reproducing this on my Nexus 7 2013 (Android 4.4.2) and could not.
Summary: The tabs button is wrongly displayed after open a link in new tab → (Nexus 7 2012) - the tabs button is wrongly displayed after open a link in new tab
Component: Theme and Visual Design → Graphics, Panning and Zooming
(In reply to flaviu.cos from comment #0) > Please check the video: https://www.youtube.com/watch?v=PcAMK6LPzSk FWIW, I reproduced this on my 2012 Nexus 7 running a CM11 Nightly, specifically: - cm-11-20131212-NIGHTLY-grouper (4.4.2) - https://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013-12-12-03-02-02-mozilla-central-android/ I followed the actions in the video exactly. Attachment 8346541 [details] shows the second broken state, and I've attached a screenshot showing the first broken state, assuming it even helps.
Also FWIW, This is also reproducible on: https://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013/11/2013-11-05-03-02-06-mozilla-central-android/ Which is the oldest build moznightly gives me by date that doesn't just FC straight away.
Regression window would be nice but this should be able to be tackled without one. Mark thoughts on an assignee?
Brian - See if you can reproduce this.
Assignee: nobody → bnicholson
I don't have an N7, but I see something similar using the emulator (Nexus 7 settings, 4.4). I sometimes hit it after repeatedly using "Open in New Tab" and hitting the URL bar, though STR aren't reliable.
Last good build 09.09.2013; From 09.10.2013 to 11.04.2013.build1 nightly is not working (Android 4.4 gives the following error: "Unfortunately nightly has stopped working"). Bug reproducible from build 11.04.2013.build2. Pushlog for 09.09.2013 to 09.10.2013: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c7cc85e13f7a&tochange=e5ca10a2b3d0 Pushlog for 11.04.2013.build1 to 11.04.2013.build2: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b4143e04bea1&tochange=fadc8a168bbc
Those regression ranges are not correct. The regression range would be from e5ca10a2b3d0 to fadc8a168bbc which is about two months worth of checkins. We would need to build with the patch from bug 934514 to find a range for this. Is a range truly needed?
Brian would possibly bisect it himself if needed. But I think trying to look for root cause could be a good start too. Brian - Put in a request for an N7 as soon as you can. That might make testing faster. s/might/will
This is a bug I don't think we can ship with (similar to 26.0.1).
I put in a request for an N7, so hopefully the STR will be more reliable on a device instead of the emulator. Using the emulator, the bug happens very intermittently for me, so it would be pretty difficult to debug this (or hunt for the regression) without more consistency.
Any update yet?
I noticed that the corruption only seems to happen when changing the alpha level of the tab counter while it is simultaneously animating. Disabling the alpha level change when entering editing mode fixes the issue; disabling the tab count animation also fixes the issue. With both enabled, however, the entire toolbar gets corrupted as shown in the screenshots. Just as an experiment, I tried using setLayerType() on the tab counter view, and it worked. Setting both LAYER_TYPE_HARDWARE and LAYER_TYPE_SOFTWARE fix the animation; the bug happens only for LAYER_TYPE_NONE (the default). Brad says there's likely an Android bug with the flattening that takes place with LAYER_TYPE_NONE.
Attachment #8360040 - Flags: review?(blassey.bugs)
Attachment #8360040 - Flags: review?(blassey.bugs) → review+
Overlooked that setLayerType was introduced an API 11, so I updated the patch to include the API check. Pushed follow-up to fx-team: https://hg.mozilla.org/integration/fx-team/rev/5d245e2369fa
Comment on attachment 8360129 [details] [diff] [review] Give the tab counter view its own rendering layer, v2 [Approval Request Comment] Bug caused by (feature/regressing bug #): unknown User impact if declined: toolbar corruption (see screenshots) Testing completed (on m-c, etc.): tested fix locally on Nexus 7 Risk to taking this patch (and alternatives if risky): very low risk String or IDL/UUID changes made by this patch: none
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
https://hg.mozilla.org/releases/mozilla-aurora/rev/e7d4d91519a0 https://hg.mozilla.org/releases/mozilla-beta/rev/d86a8ee4d3de I folded the two patches together.
There is strong reason to believe that this is causing bug 960162 (the timing appears to line up perfectly). After talking it over with Brian, I'm backing this out from trunk. If the crashes stop there, I will also back out from Aurora/Beta. https://hg.mozilla.org/mozilla-central/rev/1f835fe670d7
Indeed, the crashes stopped on Trunk after backing out. Backed from Aurora/Beta as well. https://hg.mozilla.org/releases/mozilla-aurora/rev/fe8d463a6adf https://hg.mozilla.org/releases/mozilla-beta/rev/5b8515518959
The bug is still reproducible on builds: - Nightly 29.0a1 (2014-01-16); - Aurora 28.0a2 (2014-01-16); - 27 beta 6; - 26; Device: Google Nexus 7 (Android 4.4.2).
Trying again with LAYER_TYPE_SOFTWARE: https://hg.mozilla.org/integration/fx-team/rev/52058b81ff1f If this sticks, we can try uplifting to aurora and beta again. I'll also file a follow-up for tracking down the LAYER_TYPE_HARDWARE crash.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
No oddball robocop crashes on trunk since this landed again AFAICT. https://hg.mozilla.org/releases/mozilla-aurora/rev/6abe246786be https://hg.mozilla.org/releases/mozilla-beta/rev/3fe1886a46c8
Verified as fixed on builds: - 28.0a2 (2014-01-19); - 29.0a1 (2014-01-19). Device: Google Nexus 7 (Android 4.4.2). I will mark the bug as verified after verifying it in the next beta (beta 8).
Verified as fixed on build 28 beta 1. Device: Google Nexus 7 (Android 4.4.2).
You need to log in before you can comment on or make changes to this bug.