Bugzilla

Noticed this a few days ago and soldiered on for a few days, trying to see if I would get used to it or if it was going to be improved. 

Steps to reproduce:

1. Open Firefox
2. Go to any page
3. Go to any other page (same tab)
4. Look at the back and forward buttons in the toolbar 

What happens:

The back and forward buttons are very thin, especially in comparison to the refresh icon and do not look sensitive to user input. They essentially look grayed out.

It is not an unexpected occurrence to need to see that the back button is disabled or insensitive to user input. I use containers, and there are times when a new tab is opened to ensure that a page opens in a new container segregated from the page it was opened for. That new tab has no back history or stack, and the correct action to get back to the originating tab is to go back to the tab the new page was opened from. I can do that very easily by using ctrl-shift-tab, but if I glance at the back button in the omnipresent toolbar, I am confused as to whether there *is* a back stack. The UI is not helping me be aware of what is happening here, and I instead need to mouse over the button in a mystery-meat-navigation kind of way to find out whether the control is sensitive to user input, instead of acting as an affordance. 

Expected result:

Back and forward buttons should be easier to see that they are sensitive to user input. At times, it is even hard to see the difference between the icons even when there are no pages to move forward to (and the back button is active), making me unsure of whether I can use the button. 

16:57.83 INFO: Narrowed integration regression window from [ca8aff82, 20cbe7fb] (3 builds) to [ca8aff82, f1601413] (2 builds) (~1 steps left)
16:57.83 INFO: No more integration revisions, bisection finished.
16:57.83 INFO: Last good revision: ca8aff8285cadc7fb74b0f05676ebcd98b4f77d3
16:57.83 INFO: First bad revision: f160141317e9c764ac698e7dab08c36820e7e922
16:57.83 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ca8aff8285cadc7fb74b0f05676ebcd98b4f77d3&tochange=f160141317e9c764ac698e7dab08c36820e7e922

Noticed this a few days ago and soldiered on for a few days, trying to see if I would get used to it or if it was going to be improved. 

Steps to reproduce:

1. Open Firefox
2. Go to any page
3. Go to any other page (same tab)
4. Look at the back and forward buttons in the toolbar 

What happens:

The back and forward buttons are very thin, especially in comparison to the refresh icon and do not look sensitive to user input. They essentially look grayed out.

It is not an unexpected occurrence to need to see that the back button is disabled or insensitive to user input. I use containers, and there are times when a new tab is opened to ensure that a page opens in a new container segregated from the page it was opened frmom. That new tab has no back history or stack, and the correct action to get back to the originating tab is to go back to the tab the new page was opened from. I can do that very easily by using ctrl-shift-tab, but if I glance at the back button in the omnipresent toolbar, I am confused as to whether there *is* a back stack. The UI is not helping me be aware of what is happening here, and I instead need to mouse over the button in a mystery-meat-navigation kind of way to find out whether the control is sensitive to user input, instead of acting as an affordance. 

Expected result:

Back and forward buttons should be easier to see that they are sensitive to user input. At times, it is even hard to see the difference between the icons even when there are no pages to move forward to (and the back button is active), making me unsure of whether I can use the button. 

16:57.83 INFO: Narrowed integration regression window from [ca8aff82, 20cbe7fb] (3 builds) to [ca8aff82, f1601413] (2 builds) (~1 steps left)
16:57.83 INFO: No more integration revisions, bisection finished.
16:57.83 INFO: Last good revision: ca8aff8285cadc7fb74b0f05676ebcd98b4f77d3
16:57.83 INFO: First bad revision: f160141317e9c764ac698e7dab08c36820e7e922
16:57.83 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ca8aff8285cadc7fb74b0f05676ebcd98b4f77d3&tochange=f160141317e9c764ac698e7dab08c36820e7e922

Noticed this a few days ago and soldiered on for a few days, trying to see if I would get used to it or if it was going to be improved. 

Steps to reproduce:

1. Open Firefox
2. Go to any page
3. Go to any other page (same tab)
4. Look at the back and forward buttons in the toolbar 

What happens:

The back and forward buttons are very thin, especially in comparison to the refresh icon and do not look sensitive to user input. They essentially look grayed out.

It is not an unexpected occurrence to need to see that the back button is disabled or insensitive to user input. I use containers, and there are times when a new tab is opened to ensure that a page opens in a new container segregated from the page it was opened from. That new tab has no back history or stack, and the correct action to get back to the originating tab is to go back to the tab the new page was opened from. I can do that very easily by using ctrl-shift-tab, but if I glance at the back button in the omnipresent toolbar, I am confused as to whether there *is* a back stack. The UI is not helping me be aware of what is happening here, and I instead need to mouse over the button in a mystery-meat-navigation kind of way to find out whether the control is sensitive to user input, instead of acting as an affordance. 

Expected result:

Back and forward buttons should be easier to see that they are sensitive to user input. At times, it is even hard to see the difference between the icons even when there are no pages to move forward to (and the back button is active), making me unsure of whether I can use the button. 

16:57.83 INFO: Narrowed integration regression window from [ca8aff82, 20cbe7fb] (3 builds) to [ca8aff82, f1601413] (2 builds) (~1 steps left)
16:57.83 INFO: No more integration revisions, bisection finished.
16:57.83 INFO: Last good revision: ca8aff8285cadc7fb74b0f05676ebcd98b4f77d3
16:57.83 INFO: First bad revision: f160141317e9c764ac698e7dab08c36820e7e922
16:57.83 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ca8aff8285cadc7fb74b0f05676ebcd98b4f77d3&tochange=f160141317e9c764ac698e7dab08c36820e7e922