Closed Bug 961749 Opened 11 years ago Closed 11 years ago

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

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox26 wontfix, firefox27+ wontfix, firefox28+ verified, firefox29+ verified, firefox30 verified, firefox31 verified, fennec+)

VERIFIED FIXED
Firefox 29
Tracking Status
firefox26 --- wontfix
firefox27 + wontfix
firefox28 + verified
firefox29 + verified
firefox30 --- verified
firefox31 --- verified
fennec + ---

People

(Reporter: cos_flaviu, Assigned: bnicholson)

Details

(Keywords: reproducible)

Attachments

(3 files, 2 obsolete files)

Environment: Device: Google Nexus 7 (Android 4.4.2); Build: Nightly 29.0a1 (2014-01-20). Steps to reproduce: 1. Start fennec; 2. Long tap on a site from the Top sites; 3. Select 'Open in New Tab'; 4. Switch to the new opened tab; 5. Tap on the url bar; 6. Go to bookmarks page; 7. Long tap on a bookmark; 8. Select 'Open in New Tab'; 9. Repeat steps 7 and 8; 9. 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: The bug is similar with bug 949458 but with different steps.
Can you attach a screenshot or describe what you mean by messed out? When you're in about:home, the tabs button, back button, and refresh are purposely disabled until you return back to content.
Attached image The file is a screen capture (deleted) —
This bug have the same actual result as the bug 949458 but the steps to reproduce are a bit different.
tracking-fennec: --- → ?
Ugh. I guess the fix in bug 949458 was just a lucky fix for those particular STR. I've been experimenting with tweaking random properties on View today to see if anything helps, but I haven't had any luck. Honestly, I have no idea how to tackle graphical glitches like this other than guess-and-checking until something magically works.
As described at https://bugzilla.mozilla.org/show_bug.cgi?id=949458#c13, one thing I did find in bug 949458 is that the glitch seems to be caused by the combination of the animation and alpha setting of the tabs counter. Disabling either the animation or the alpha made bug 949458 go away, and that seems to be the case here, too.
AAron, Brian, do we know if versions prior to FX27 are affected or if this is a new regression?
Same story as bug 949458: (In reply to Cykesiopka from https://bugzilla.mozilla.org/show_bug.cgi?id=949458#c3) > 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.
Reproduced on my 2012 Nexus 7 (Android 4.3) * Firefox 26, 27, 28 and 29 are affected. The UI never recovers through interacting with navigation and buttons. The UI recovers on next launch (swipe to close, re-open browser).
Component: Theme and Visual Design → General
Keywords: reproducible
Assigning to Brian since he is familiar with it. What are the consequences of the tweaks in comment 4? Not meaning we should turn one of the off and call it fixed, but what is it about those changes that could affect the rendering? Does toggling the alpha "fix" this too?
Assignee: nobody → bnicholson
tracking-fennec: ? → +
Attached patch Part 1: Back out bug 949458 (deleted) — Splinter Review
Bug 949458 doesn't fix this problem, so we should back it with whatever fix we go with here.
Just a recap: this bug appears to be caused by the compounding of alpha values at [1] and [2]. Removing either "fixes" the bug, but the combination of them causes the glitch. [1] http://hg.mozilla.org/mozilla-central/file/066c526104ef/mobile/android/base/toolbar/BrowserToolbar.java#l867 [2] http://hg.mozilla.org/mozilla-central/file/066c526104ef/mobile/android/base/toolbar/TabCounter.java#l111 One solution proposed by Mark was to remove the transparency whenever animating the tab counter. That means if we're in editing mode, the tab counter turns white, animates, then turns back to semi-transparent. This patch does this. After testing bug 949458 and this bug's STR, this fix seemed to work. Unfortunately, I found yet another set of STR that doesn't get fixed even by this patch: 1) Long press thumbnail, click Open in New Tab 2) Tap the URL bar during the animation I might be able to fix this with more trial and error, but let's first get some feedback to determine whether this approach is even worth pursuing to begin with. Build here: https://dl.dropboxusercontent.com/u/35559547/fennec/fennec-tab-alpha-toggle.apk
Attachment #8364740 - Flags: feedback?(lucasr.at.mozilla)
Attached patch Remove alpha animation for tab counter (obsolete) (deleted) — Splinter Review
Another approach, which is much simpler, is to just remove the AlphaAnimation from TabCounter altogether. This fixes all STR I've tried, with the downside that the animation is a little less pretty. Build: https://dl.dropboxusercontent.com/u/35559547/fennec/fennec-counter-alpha-off.apk
Attachment #8364745 - Flags: feedback?(lucasr.at.mozilla)
One more solution, which I haven't posted here, is to keep the animation the way it is, but to not gray out the tab counter when entering editing mode. P.S.: I'm developing a raging hatred for this bug, so if you have any idea how to fix the corruption the correct way rather than resorting to these workarounds, I would be a happy Brian. Ian: TLDR version: there's a graphical glitch that only appears to be fixed by tweaking the tab counter. There are a couple builds above that use different workarounds, and we'll need to go with the lesser of the two evils. Can you try them out on a tablet and see which you prefer?
Flags: needinfo?(ibarlow)
Finally, Flaviu, can you play around with the build in comment 11 and make sure this bug, in all its hideous forms, is gone? If you could try any other STR you can think of, that would be really helpful.
Flags: needinfo?(flaviu.cos)
(In reply to Brian Nicholson (:bnicholson) from comment #13) > Finally, Flaviu, can you play around with the build in comment 11 and make > sure this bug, in all its hideous forms, is gone? If you could try any other > STR you can think of, that would be really helpful. I tried all kinds of STR on the build from comment 11 and could not reproduce the bug. Tested on Google Nexus 7 (Android 4.4.2).
Flags: needinfo?(flaviu.cos)
As Mark suggested, let's just disable these tab count animations whenever we're in editing mode.
Attachment #8364740 - Attachment is obsolete: true
Attachment #8364745 - Attachment is obsolete: true
Attachment #8364740 - Flags: feedback?(lucasr.at.mozilla)
Attachment #8364745 - Flags: feedback?(lucasr.at.mozilla)
Attachment #8366371 - Flags: review?(lucasr.at.mozilla)
Flags: needinfo?(ibarlow)
This is a cleanup of the sketch we were talking about yesterday, which proposes to actually hide all the title bar icons in edit mode, and also add a button to cancel edit mode and take you back to the page you were on previously (part of another bug that I can't find at the moment). There is a phone version here as well. This might not be in scope for this bug, but I'd like us to look at this as soon as we can, as it answers a fair bit of feedback we've been hearing about the title bar behaviour. Mockup: http://cl.ly/image/0S1c3M3C0Q1m
Comment on attachment 8366371 [details] [diff] [review] Disable tab count animation in editing mode Review of attachment 8366371 [details] [diff] [review]: ----------------------------------------------------------------- Ok, maybe show the end result to ibarlow?
Attachment #8366371 - Flags: review?(lucasr.at.mozilla) → review+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Comment on attachment 8366371 [details] [diff] [review] Disable tab count animation in editing mode [Approval Request Comment] Regression caused by (bug #): unknown User impact if declined: action bar can become glitchy and unusable on Nexus 7 Testing completed (on m-c, etc.): m-c Risk to taking this patch (and alternatives if risky): Very low risk; disables the tab count animation whenever the user is in editing mode String or IDL/UUID changes made by this patch: none Also requesting approval for release in case there's a re-spin.
Attachment #8366371 - Flags: approval-mozilla-release?
Attachment #8366371 - Flags: approval-mozilla-beta?
Attachment #8366371 - Flags: approval-mozilla-aurora?
Comment on attachment 8366371 [details] [diff] [review] Disable tab count animation in editing mode Approving for Aurora, we're about to merge and final Beta (RC) is already shipped so no need to approve for beta. Will leave the mozilla-release nomination for consideration should we have a chemspill and want to take this as a ride-along.
Attachment #8366371 - Flags: approval-mozilla-beta?
Attachment #8366371 - Flags: approval-mozilla-beta-
Attachment #8366371 - Flags: approval-mozilla-aurora?
Attachment #8366371 - Flags: approval-mozilla-aurora+
Comment on attachment 8366371 [details] [diff] [review] Disable tab count animation in editing mode Actually, we already wontfixed this for 26 so since this has already been around a while it's not a valid candidate for the level of urgency (and lack of churn) we'd want in a respin. This can ride the trains from 28.
Attachment #8366371 - Flags: approval-mozilla-release? → approval-mozilla-release-
Verified as fixed in builds: - 31.0a1 (2014-04-15); - 30.0a2 (2014-04-15); - 29 beta 8; - 28; Device: Google Nexus 7 (Android 4.4.2).
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: