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

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Theme and Visual Design, defect)

Description

[Flaviu Cos]

Attachment: The file attached is a screen capture

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.

Comment 1

[Aaron Train [:aaronmt]]

I tried reproducing this on my Nexus 7 2013 (Android 4.4.2) and could not.

Comment 2

[:Cykesiopka]

Attachment: Screenshot of first broken state

(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.

Comment 3

[:Cykesiopka]

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.

Comment 4

[Kevin Brosnan [Ex-Mozilla]]

Regression window would be nice but this should be able to be tackled without one. Mark thoughts on an assignee?

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Brian - See if you can reproduce this.

Comment 6

[Brian Nicholson (:bnicholson)]

Attachment: Screenshot in emulator

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.

Comment 7

[Flaviu Cos]

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

Comment 8

[Kevin Brosnan [Ex-Mozilla]]

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?

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 10

[Aaron Train [:aaronmt]]

This is a bug I don't think we can ship with (similar to 26.0.1).

Comment 11

[Brian Nicholson (:bnicholson)]

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.

Comment 12

[Aaron Train [:aaronmt]]

Any update yet?

Comment 13

[Brian Nicholson (:bnicholson)]

Attachment: Give the tab counter view its own rendering layer

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.

Comment 14

[Brian Nicholson (:bnicholson)]

https://hg.mozilla.org/integration/fx-team/rev/8f3dad3b3698

Comment 15

[Brian Nicholson (:bnicholson)]

Attachment: Give the tab counter view its own rendering layer, v2

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 16

[Brian Nicholson (:bnicholson)]

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

Comment 17

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8f3dad3b3698
https://hg.mozilla.org/mozilla-central/rev/5d245e2369fa

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e7d4d91519a0
https://hg.mozilla.org/releases/mozilla-beta/rev/d86a8ee4d3de

I folded the two patches together.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

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

Comment 20

[Ryan VanderMeulen [:RyanVM]]

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

Comment 21

[Flaviu Cos]

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).

Comment 22

[Brian Nicholson (:bnicholson)]

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.

Comment 23

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/52058b81ff1f

Comment 24

[Ryan VanderMeulen [:RyanVM]]

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

Comment 25

[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).

Comment 26

[Flaviu Cos]

Verified as fixed on build 28 beta 1.
Device: Google Nexus 7 (Android 4.4.2).