Closed Bug 681805 Opened 13 years ago Closed 11 years ago

[TABLETUI] Hide forward button when there is not forward shistory...

Categories

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

ARM
Android
enhancement

Tracking

(firefox20 verified)

VERIFIED FIXED
Firefox 20
Tracking Status
firefox20 --- verified

People

(Reporter: romaxa, Assigned: wesj)

References

Details

Attachments

(2 files, 14 obsolete files)

21.76 KB, patch
lucasr
: review+
Details | Diff | Splinter Review
15.41 KB, patch
lucasr
: review+
Details | Diff | Splinter Review
I think it does not make any sense to display dimmed forward button all the time in tablet UI, because it dimmed in 70% tab usage cases...

worth to do the same with back button, but not sure..
Summary: Hide forward button when there is not forward shistory... → [TABLETUI] Hide forward button when there is not forward shistory...
Severity: normal → enhancement
OS: Linux → Android
Priority: -- → P1
Hardware: x86 → ARM
The current tablet design doesn't show/hide back/forward buttons. Madhava, Brian, Ian, what do you think?
Lucas, it would be great to add this functionality, as it is something we're working toward on desktop as well. 

I'll post some designs for this soon.
There are plans afoot to do this on desktop as well, with a forward button that animates out into place when there are actually pages to go forwards to. I think we should keep our back button in place, tbh, even when not applicable just because it is such a visual anchor in the browser and the most used button. It's part of what tells you you're in a browser. Ian has some preliminary designs for this, I think.
Attached image mockup (obsolete) —
Here's a mockup of the transition that Madhava described, with the tablet look applied. 

Note the new styling of the back button and its connection to the URLbar. Should I file a separate styling bug for that?
Attached file New back / forward button assets (obsolete) —
Attached image mockup (obsolete) —
Here is a mockup with more detailed back and forward button states.
Attachment #557176 - Attachment is obsolete: true
Ian, this design (attachment 558926 [details]) makes it impossible to access the site menu or identity/security information on pages that have the forward button active.  I like the idea of keeping the title/url field stationary as the forward button appears and disappears, but is there a way we can preserve access to this information?
Thanks Matt, actually Madhava had brought up this point as well. 

It occurs to me though, users will still be able to access this information through the "more" menu's "page info" icon, no? http://www.flickr.com/photos/61892693@N03/6059293024/in/photostream/lightbox/

So given that, my preference would be to continue with this layout. But if people are still opposed, we could try a couple of other ways:

1. Slide the whole url bar to the right to make room for the forward button
2. Slide the favicon and url text (but not the bar) to the right to make room

Matt, Madhava, thoughts?
(In reply to Ian Barlow from comment #8)

> It occurs to me though, users will still be able to access this information
> through the "more" menu's "page info" icon, no?
> http://www.flickr.com/photos/61892693@N03/6059293024/in/photostream/lightbox/
> 
> So given that, my preference would be to continue with this layout. But if
> people are still opposed, we could try a couple of other ways:

In a way, we are changing the function of the button. If a user didn't notice the "slide" phase where the forward button replaces the favicon, they might think the forward button _is_ the favicon.

Also, the favicon shows some security state.

> 1. Slide the whole url bar to the right to make room for the forward button
> 2. Slide the favicon and url text (but not the bar) to the right to make room

#2 sounds reasonable to me. I don't like shifting the entire toolbar.
Alright, let's do that. I just noticed on our latest UX desktop build, they have also updated the behaviour to reflect what I've described in #2. So let's be consistent.
Assignee: nobody → lucasr.at.mozilla
Attached patch WIP (obsolete) — Splinter Review
Oh hey lucas! Didn't realise you'd grabbed this. I was playing around with it a bit so thought I'd throw this up. This does the keyhole back button and the conditional forward stuff.

Works, but its kinda hacky and the animation ain't great.
Assignee: lucasr.at.mozilla → wjohnston
Moving the component since we still want this on Native, but these mockups dont' apply anymore.
Component: General → Theme and Visual Design
Product: Fennec → Firefox for Android
Attached patch Patch v1 (obsolete) — Splinter Review
I had to add an animator for margin here, so that if there is an icon showing on the right of the urlbar it won't move. Performance is good on all my devices.
Attachment #558925 - Attachment is obsolete: true
Attachment #558926 - Attachment is obsolete: true
Attachment #559276 - Attachment is obsolete: true
Attachment #561336 - Attachment is obsolete: true
Attachment #674428 - Flags: review?(sriram)
Comment on attachment 674428 [details] [diff] [review]
Patch v1

Review of attachment 674428 [details] [diff] [review]:
-----------------------------------------------------------------

Does the tabs sidebar animation on tablets work fine in all cases (forward button visible and not visible)? I really want to hear why this really needs a margin animation. Slide animations can be implement in terms of translations in most cases. Giving f- until I get a more clear explanation why the margin animator is needed.

::: mobile/android/base/AnimatorProxy.java
@@ +104,5 @@
>          mImpl.setAlpha(alpha);
>      }
>  
> +    public int getMarginLeft() {
> +        View view = mImpl.getView();

You need to bail if view is null here. mImpl holds a weak reference of the view which might be disposed at any time.

@@ +111,5 @@
> +        return layoutParams.leftMargin;
> +    }
> +
> +    public void setMarginLeft(int margin) {
> +        View view = mImpl.getView();

Same here.

::: mobile/android/base/BrowserApp.java
@@ +75,5 @@
>      private Vector<MenuItemInfo> mAddonMenuItemsCache;
>  
>      private PropertyAnimator mMainLayoutAnimator;
>  
> +    public static final Interpolator sTabsInterpolator = new Interpolator() {

The DecelerateInterpolator doesn't work well enough?

::: mobile/android/base/BrowserToolbar.java
@@ +711,5 @@
> +                      PropertyAnimator.Property.TRANSLATION_X,
> +                      -1*mForward.getWidth()/2);
> +          anim.attach(mAddressBarView,
> +                      PropertyAnimator.Property.MARGIN_LEFT,
> +                      mAddressBarViewOffsetNoForward);

I don't see why you could not implement this in terms of translation. This will cause a relayout on each frame which is simply too expensive. The animation performance might be "ok" with this but it will never be as smooth as when using hw acceleration.
Attachment #674428 - Flags: feedback-
(In reply to Lucas Rocha (:lucasr) from comment #15)
> I don't see why you could not implement this in terms of translation. This
> will cause a relayout on each frame which is simply too expensive. The
> animation performance might be "ok" with this but it will never be as smooth
> as when using hw acceleration.

Maybe I don't know what you're proposing or understand Android's translation animations correctly. The urlbar looks like:

-------------------------------------------------------------------------------
Back, Forward [Favicon, Lock, FlexText............................Reader, Stop]
-------------------------------------------------------------------------------

we want the final state of the animation to give us:
-------------------------------------------------------------------------------
Back, [Favicon, Lock, FlexText....................................Reader, Stop]
-------------------------------------------------------------------------------

i.e. we want to translate the favicon, lock, and flexy text left, while expanding the width of the FlexText at the same time so that the reader and stop buttons don't move. The lock icon lays things out as they will be when the animation is done, and then does the animation (which leads to an incorrect layout for a brief moment during the animation).

I thought about something like that but that could wind up showing the stop/reader icons outside of the urlbar and then translating them backwards into the box. i.e. this:

-------------------------------------------------------------------------------
Back, Forward [Favicon, Lock, FlexText....................................Reader, Stop]
-------------------------------------------------------------------------------

would change to this:

-------------------------------------------------------------------------------
Back, [Favicon, Lock, FlexText....................................Reader, Stop]
-------------------------------------------------------------------------------

which seems like it will be more obvious to users (but we could try it, its kinda rare to have this happen while stop/reader are showing anyway).

I'm open to other options if you know of any. The performance here (on the devices I have that show a forward button, which are all fairly new, fast devices) is good with this patch, except on about:home where I think something is happening on the UI thread to cause jank.
Got it. What do you probably should do here is translating Forward, Favicon, Lock, and FlexText first, then setting left margin (and resetting the translations) *after* the animation finishes (this is for hiding the Forward button). You'd probably set the left margin before the animation when showing the Forward button.
Attached patch Patch (obsolete) — Splinter Review
This works fine, but looks kinda bad when moving to/from pages with the lock animation. I put a build at:

http://people.mozilla.com/~wjohnston/fennec-forward.apk

I think we probably need to delay the lock animation until after this is finished if its running. Adding UX to see how they like this though.
Attachment #674428 - Attachment is obsolete: true
Attachment #674428 - Flags: review?(sriram)
Attachment #685670 - Flags: feedback?(lucasr.at.mozilla)
Flags: needinfo?(ibarlow)
Attached patch Patch v3 (obsolete) — Splinter Review
I like this better. The tries to delay the lock animation until after the forward animation has completed. Updated build still at:

http://people.mozilla.com/~wjohnston/fennec-forward.apk

for ux.
Attachment #685670 - Attachment is obsolete: true
Attachment #685670 - Flags: feedback?(lucasr.at.mozilla)
Attachment #685698 - Flags: review?(lucasr.at.mozilla)
Nice!

Couple things I'm noticing:

- Going forward sometimes causes a sort of "eclipse" effect that isn't very nice. Anything we can do there?
- Can we remember if a site has a lock in the URL bar, and when going forward to it, redraw the [icon][lock][title] block all at once, rather than fading the lock in afterwards?
Flags: needinfo?(ibarlow)
Attached patch Patch v4 (obsolete) — Splinter Review
This fixes the clipping issue. I think the site security fix is a good idea. At the very least, I think maybe we/I could add a way to update the final translation of the TextView midway through the transition.

I think I'd rather do that in a second patch though.
Attachment #685698 - Attachment is obsolete: true
Attachment #685698 - Flags: review?(lucasr.at.mozilla)
Attachment #685805 - Flags: review?(lucasr.at.mozilla)
Comment on attachment 685805 [details] [diff] [review]
Patch v4

Review of attachment 685805 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good overall but will crash on pre-Honeycomb. I'd like to see a new version of this patch.

::: mobile/android/base/BrowserToolbar.java
@@ +421,5 @@
>                  mSiteSecurity.setVisibility(View.VISIBLE);
> +        } else if (animation.equals(mTitleSlideLeft)) {
> +            mSiteSecurity.setVisibility(View.GONE);
> +        } else if (animation.equals(mTitleSlideRight)) {
> +            mSiteSecurity.setVisibility(View.INVISIBLE);

Why are these changes needed?

@@ +660,5 @@
> +            mTitleSlideLeft.setStartOffset(delay);
> +        } else {
> +            mTitleSlideRight.setStartOffset(0);
> +            mTitleSlideLeft.setStartOffset(0);
> +        }

I assume this is to guarantee the title slide animation always happens after the forward button animation?

@@ +757,5 @@
> +    public void updateForwardButton(final boolean enabled) {
> +        if (mForward.isEnabled() == enabled)
> +            return;
> +        mForward.setEnabled(enabled);
> +        mForward.setColorFilter(enabled ? 0 : 0xFF999999);

Do these setEnable() and setColorFilter() calls still make sense after this patch? I mean, you're hiding the button anyway...

@@ +762,5 @@
> +
> +        if (mForward.getVisibility() != View.VISIBLE)
> +            return;
> +
> +        mForwardAnim = new PropertyAnimator(450);

Does mForwardAnim really need to be a property?

@@ +789,5 @@
> +                    layoutParams.leftMargin = mAddressBarViewOffset;
> +    
> +                    mTitle.setTranslationX(0);
> +                    mFavicon.setTranslationX(0);
> +                    mSiteSecurity.setTranslationX(0);

Ditto.

@@ +824,5 @@
> +            // appear to move initially.
> +            int startTrans = mAddressBarViewOffset - mAddressBarViewOffsetNoForward;
> +            mTitle.setTranslationX(startTrans);
> +            mFavicon.setTranslationX(startTrans);
> +            mSiteSecurity.setTranslationX(startTrans);

This will crash on pre-Honeycomb. You have to use the AnimatorProxy I wrote to do that in a backwards compatible way. Something like this:

AnimatorProxy proxy = AnimatorProxy.create(mTitle);
proxy.setTranslationX(startTrans);

@@ +840,5 @@
> +                      PropertyAnimator.Property.TRANSLATION_X,
> +                      mAddressBarViewOffset - mAddressBarViewOffsetNoForward);
> +            anim.attach(mForward,
> +                      PropertyAnimator.Property.ALPHA,
> +                      1);

nit: move this bit to be just after the other attach call with mForward?
Attachment #685805 - Flags: review?(lucasr.at.mozilla) → review-
Attached patch Patch v5 (obsolete) — Splinter Review
> > +        } else if (animation.equals(mTitleSlideLeft)) {
> > +            mSiteSecurity.setVisibility(View.GONE);
> > +        } else if (animation.equals(mTitleSlideRight)) {
> > +            mSiteSecurity.setVisibility(View.INVISIBLE);
> Why are these changes needed?

These have to be here because we're doing this weird 1.) Set the margin, 2.) Set a transform, 3.) Remove the transform process here. Without them the site security icon's padding causes those initial transform to not work out (the page title overlaps the favicon). I added some comments to explain.

> I assume this is to guarantee the title slide animation always happens after
> the forward button animation?
Yes.

> Do these setEnable() and setColorFilter() calls still make sense after this
> patch? I mean, you're hiding the button anyway...
setEnable is needed because we're using it to determine whether or not we need to do any animation (mFoward.getEnabled == enabled). I removed the color Filter bit.

> Does mForwardAnim really need to be a property?
I'm using the existence of this to determine whether or not to delay the siteSecurity animation.

> This will crash on pre-Honeycomb. You have to use the AnimatorProxy I wrote
> to do that in a backwards compatible way. Something like this:
Ahh thanks. Fixed.
Attachment #685805 - Attachment is obsolete: true
Attachment #688590 - Flags: review?(lucasr.at.mozilla)
Attached patch Patch v6 (obsolete) — Splinter Review
Found a bug where this was crashing from not finding the dimensions on small screen devices. I just included some dimensions for them in res/values/dimens.xml. We could do a check "Is this a large or small screen device?" or "Is the forward button visible?" But this seems easier and less likely to break to me.
Attachment #688590 - Attachment is obsolete: true
Attachment #688590 - Flags: review?(lucasr.at.mozilla)
Attachment #688858 - Flags: review?(lucasr.at.mozilla)
Comment on attachment 688858 [details] [diff] [review]
Patch v6

Review of attachment 688858 [details] [diff] [review]:
-----------------------------------------------------------------

Looking good! However, I found a few bugs while trying the build with this patch:
- The forward button starts visible then hides on starts. Feels a bit glitchy.
- The forward button fades in when transitioning to awesome screen even when it's hidden
- Sometimes the forward button is partially visible behind the back button. Maybe because of the awesome screen animation?
- Back/forward buttons look completely broken in landscape mode on phones. I recommend not changing that for now (if this was an intended change)
- It seems you haven't updated all layout files for the browser toolbar, no?

The patch looks generally good but I'd prefer to have these issues fixed before landing.

::: mobile/android/base/BrowserToolbar.java
@@ +419,5 @@
> +        } else if (animation.equals(mTitleSlideLeft)) {
> +            // These two animations may be scheduled to start while the forward
> +            // animation is occurring. If we're showing the site security icon, make
> +            // sure it doesn't take any space during the forward transition.
> +            mSiteSecurity.setVisibility(View.GONE);

Make sure that updating the visibility on these callbacks doesn't cause any glitches. I remember having explicitly put it outside the start callback because of that.

@@ +977,5 @@
> +            public void onPropertyAnimationStart() {
> +                if (!enabled) {
> +                    // Set the margin before the transition when hiding the forward button. We
> +                    // have to do this so that the favicon isn't clipped during the transition
> +                    ViewGroup.MarginLayoutParams layoutParams =    

nit: remove trailing space

@@ +986,5 @@
> +                    // in prepareForwardAnimation, so they should appear to have not moved at
> +                    // all at this point.
> +                }
> +            }
> +        

nit: remove trailing space

@@ +993,5 @@
> +                if (enabled) {
> +                    ViewGroup.MarginLayoutParams layoutParams =
> +                        (ViewGroup.MarginLayoutParams)mAddressBarView.getLayoutParams();
> +                    layoutParams.leftMargin = mAddressBarViewOffset;
> +    

nit: remove trailing space

@@ +1032,5 @@
> +            // We're hiding the forward button. We're going to reset the margin before
> +            // the animation starts, so we shift these items to the right so that they don't
> +            // appear to move initially.
> +            int startTrans = mAddressBarViewOffset - mAddressBarViewOffsetNoForward;
> +            AnimatorProxy titleProxy = AnimatorProxy.create(mTitle);

nit: Maybe just declare one proxy variable and reuse?

AnimatorProxy proxy = AnimatorProxy.create(mTitle);
proxy.setTranslationX(startTrans);
proxy = AnimatorProxy.create(mFavicon);
proxy.setTranslationX(startTrans);
...

@@ +1044,5 @@
> +                      PropertyAnimator.Property.TRANSLATION_X,
> +                      0);
> +            anim.attach(mForward,
> +                      PropertyAnimator.Property.ALPHA,
> +                      1);            anim.attach(mTitle,

Fix indentation here.

::: mobile/android/base/resources/layout-land-v14/browser_toolbar_menu.xml.in
@@ -17,5 @@
> -                     style="@style/AddressBar.ImageButton.Unused"/>
> -
> -        <ImageButton android:id="@+id/forward"
> -                     android:contentDescription="@string/forward"
> -                     style="@style/AddressBar.ImageButton.Unused"/>

So, you're adding back/forward button to the toolbar when in landscape mode on phones? Is that intentional? Have you checked with ibarlow?
Attachment #688858 - Flags: review?(lucasr.at.mozilla) → review-
Attached patch Patch v8 (obsolete) — Splinter Review
Startup and awesomebar changes are fixed.

Hmm... I didn't realize I'd changed the landscape layouts, and I'm still not sure why those exist even. I moved all of the property setting to style files. I think we need to do something like this for all the style properties in browser_toolbar, although I'm happy to hear about different methods if you have 'em.
Attachment #688858 - Attachment is obsolete: true
Attachment #689907 - Flags: review?(lucasr.at.mozilla)
Attached patch Patch v8 (obsolete) — Splinter Review
Forgot to qref this one!
Attachment #689907 - Attachment is obsolete: true
Attachment #689907 - Flags: review?(lucasr.at.mozilla)
Attachment #689919 - Flags: review?(lucasr.at.mozilla)
Comment on attachment 689919 [details] [diff] [review]
Patch v8

Review of attachment 689919 [details] [diff] [review]:
-----------------------------------------------------------------

This patch is a bit hard to follow because you're doing two different things in the same patch: implementing the animation to hide the forward *and* moving properties from the layout to styles. It would be great if this patch was split in two for review. No need to do it now. Just giving feedback.

I just want to understand why you're changing layout-land-v14/browser_toolbar_menu.xml.in so much given that we're even supposed to show the forward/back buttons on this layout. Looks suspicious. I can flip the review to r+ once I understand it.

::: mobile/android/base/BrowserToolbar.java
@@ +132,5 @@
>  
>          mAddressBarBg = (BrowserToolbarBackground) mLayout.findViewById(R.id.address_bar_bg);
> +        mAddressBarView = mLayout.findViewById(R.id.addressbar);
> +        mAddressBarViewOffset = (int) (mActivity.getResources().getDimension(R.dimen.addressbar_offset_left));
> +        mAddressBarViewOffsetNoForward = (int) (mActivity.getResources().getDimension(R.dimen.addressbar_offset_left_noforward));

I wonder if you should use getDimensionPixelSize() instead of getDimension() here?

@@ +862,5 @@
> +            mTitleSlideLeft.setStartOffset(delay);
> +        } else {
> +            mTitleSlideRight.setStartOffset(0);
> +            mTitleSlideLeft.setStartOffset(0);
> +        }

nit: add empty line here.

@@ +1003,5 @@
> +                    mAddressBarView.requestLayout();
> +                }
> +                mForwardAnim = null;
> +            }
> +        });

nit: add empty line here.

::: mobile/android/base/resources/layout-land-v14/browser_toolbar_menu.xml.in
@@ +15,5 @@
>          <ImageButton android:id="@+id/back"
>                       android:contentDescription="@string/back"
>                       style="@style/AddressBar.ImageButton.Unused"/>
>  
> +        <ImageButton style="@style/AddressBar.ImageButton.Forward"/>

I usually avoid defining ids in styles just to be more explicit and avoid one more level of indirection to identify views in the layout.

@@ +74,5 @@
>              <LinearLayout style="@style/AddressBar.Button"
> +                          android:layout_marginLeft="90dp"
> +                          android:layout_marginTop="6dp"
> +                          android:layout_marginBottom="6dp"
> +                          android:layout_marginRight="0dp"

I still don't understand why you're making so many changes here. I mean, in theory, you should only be doing the same (analogous) changes than in layout-land-v14/browser_toolbar_menu.xml.in, no?
Attachment #689919 - Flags: review?(lucasr.at.mozilla) → review-
Attached patch Patch 1/2Splinter Review
This moves the forward and addressbar container styles out of browser_toolbar styles so that I only have to edit in two places instead of 10.
Attachment #689919 - Attachment is obsolete: true
Attachment #693044 - Flags: review?(lucasr.at.mozilla)
Attached patch Patch 2/2 (obsolete) — Splinter Review
This does the actual hide/show work.

The landscape stuff was... strange. I didn't mean to make it. I removed it. It snuck back in. Sorry bout that :(
Attachment #693048 - Flags: review?(lucasr.at.mozilla)
Attached patch Patch 2/2Splinter Review
Attachment #693048 - Attachment is obsolete: true
Attachment #693048 - Flags: review?(lucasr.at.mozilla)
Attachment #693049 - Flags: review?(lucasr.at.mozilla)
Comment on attachment 693044 [details] [diff] [review]
Patch 1/2

Review of attachment 693044 [details] [diff] [review]:
-----------------------------------------------------------------

Look good. I'm assuming you tested this on all major device form factors :-) That makes me wonder if you could consolidate these layout files into fewer ones and simply vary the styles (which are easier to maintain).
Attachment #693044 - Flags: review?(lucasr.at.mozilla) → review+
Comment on attachment 693049 [details] [diff] [review]
Patch 2/2

Review of attachment 693049 [details] [diff] [review]:
-----------------------------------------------------------------

Nice patch series!
Attachment #693049 - Flags: review?(lucasr.at.mozilla) → review+
12-19 09:53:59.460 E/GeckoAppShell( 1883): Caused by: android.content.res.Resources$NotFoundException: Resource ID #0x7f0a0034
12-19 09:53:59.460 E/GeckoAppShell( 1883): 	at android.content.res.Resources.getValue(Resources.java:892)
12-19 09:53:59.460 E/GeckoAppShell( 1883): 	at android.content.res.Resources.getDimensionPixelSize(Resources.java:522)
12-19 09:53:59.460 E/GeckoAppShell( 1883): 	at org.mozilla.gecko.BrowserToolbar.from(BrowserToolbar.java:136)
12-19 09:53:59.460 E/GeckoAppShell( 1883): 	at org.mozilla.gecko.BrowserApp.onCreate(BrowserApp.java:216)

https://hg.mozilla.org/integration/mozilla-inbound/annotate/0e96545f0894/mobile/android/base/BrowserToolbar.java#l136
All the Android 2.2 tests started failing when this landed, possibly the app not starting up at all.

https://hg.mozilla.org/integration/mozilla-inbound/rev/a6c22df81869
https://hg.mozilla.org/integration/mozilla-inbound/rev/54618ad94522
The test issue was resolved by the backouts of comment 39. The relevant part of the logs was identified on irc:

edmorley|pto	nthomas: the real error shows in the logcat (further down the log) REPORTING UNCAUGHT EXCEPTION FROM THREAD 1 ("main")
java.lang.RuntimeException: Unable to start activity ComponentInfo{org.mozilla.fennec/org.mozilla.fennec.App}: android.content.res.Resources$NotFoundException: Resource ID #0x7f0a0034
I'll file a bug to get it added to the TBPL parser and/or see if we can get automation's checkForCrashes to check the logcat
Grr. I pushed this through try and it was fine, but I accidentally put the fix (which I just lost when unbitrotting) in the patch with the try commit message. i.e. It didn't get pushed with these patches. Sorry about that. Since the try run was fine, I'll fix and push again (i.e. I'm not intentionally just pushing the same thing over and over again!).
https://hg.mozilla.org/mozilla-central/rev/15f4b624bc3a
https://hg.mozilla.org/mozilla-central/rev/ee099414c986
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20
Firefox 20.0a1 (2013-01-02)
Device: Asus Eee Transformers 
OS: Android 4.0.3

The forward button is hidden when there is not forward history. Marking bug as Verified Fixed.
Status: RESOLVED → VERIFIED
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

Created:
Updated:
Size: