(Nexus 7 2012) - the tabs button is wrongly displayed after open a link in new tab

VERIFIED FIXED in Firefox 27

Status

()

defect
VERIFIED FIXED
6 years ago
3 years ago

People

(Reporter: cos_flaviu, Assigned: bnicholson)

Tracking

(Depends on 1 bug, {regression})

Trunk
Firefox 29
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox26 wontfix, firefox27 verified, firefox28 verified, firefox29 verified, fennec27+)

Details

Attachments

(4 attachments, 1 obsolete attachment)

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.
tracking-fennec: --- → ?
Regression window would be nice but this should be able to be tackled without one. Mark thoughts on an assignee?
Component: Graphics, Panning and Zooming → Theme and Visual Design
Flags: needinfo?(mark.finkle)
Brian - See if you can reproduce this.
Assignee: nobody → bnicholson
Flags: needinfo?(mark.finkle)
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?
Flags: needinfo?(mark.finkle)
Flags: needinfo?(bnicholson)
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
Flags: needinfo?(mark.finkle)
tracking-fennec: ? → 27+
Status: NEW → ASSIGNED
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.
Flags: needinfo?(bnicholson)
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
Attachment #8360040 - Attachment is obsolete: true
Attachment #8360129 - Flags: review+
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
Attachment #8360129 - Flags: approval-mozilla-beta?
Attachment #8360129 - Flags: approval-mozilla-aurora?
Attachment #8360129 - Flags: approval-mozilla-beta?
Attachment #8360129 - Flags: approval-mozilla-beta+
Attachment #8360129 - Flags: approval-mozilla-aurora?
Attachment #8360129 - Flags: approval-mozilla-aurora+
Keywords: verifyme
Flags: needinfo?(flaviu.cos)
https://hg.mozilla.org/mozilla-central/rev/8f3dad3b3698
https://hg.mozilla.org/mozilla-central/rev/5d245e2369fa
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Firefox 29 → ---
Depends on: 960162
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).
Flags: needinfo?(flaviu.cos)
Keywords: verifyme
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.
https://hg.mozilla.org/mozilla-central/rev/52058b81ff1f
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Flags: needinfo?(flaviu.cos)
Keywords: verifyme
Depends on: 961136
Flags: needinfo?(flaviu.cos)
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).
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.