Closed Bug 1148879 Opened 8 years ago Closed 8 years ago

current tab in tab overflow dropdown is no longer identifiable (bold)


(Firefox :: Tabbed Browser, defect)

Not set



Firefox 40
Tracking Status
firefox38 --- unaffected
firefox39 + fixed
firefox40 + fixed


(Reporter: dbaron, Assigned: gw280)



(Keywords: regression)


(1 file)

The current tab is no longer visibly indicated in the tabs dropdown that shows up when there's overflow in the tabstrip.

Steps to reproduce:
 1. start Firefox
 2. Press Ctrl+T to open new tabs until the "v" dropdown button appears at the very right edge of the tab strip
 3. click on the "v" dropdown button to show the full list of tabs

Expected results:  The currently selected tab appears in bold, or is indicated in some way.

Actual results: Can't distinguish the current tab (which makes it hard to figure out context).

This regressed sometime in the past 8 days; currently bisecting.
[Tracking Requested - why for this release]:  This is a pretty annoying UI regression; it makes the tab overflow dropdown much harder to use, since there's nothing to provide context for the current position/state.
One day regression window from mozilla-central nightlies is:
Multiple candidates in that one day window, primarily:
(or maybe even their interaction).

(I haven't tested to see which it is.)
Flags: needinfo?(wmccloskey)
Flags: needinfo?(gwright)
Adding regressionwindow-wanted for a narrower regression window.

regressed by: 
8194018355f6	George Wright — Bug 1066531 - Delay tab switching until content is ready in e10s mode r=mconley,mstange
Interestingly I can't reproduce this on OS X, but I'm pretty sure I know what the issue is. I will put a patch together.
Flags: needinfo?(wmccloskey)
Flags: needinfo?(gwright)
Tracking for 39 and 40. 
Thanks for taking this,  George!  Will you assign yourself to the bug? I am trying to make sure everything tracked for aurora has an owner.
Assignee: nobody → gwright
It sounds like this may be e10s related, though that isn't certain. So it may not be an issue in 39 once 39 goes to beta and it sounds like other e10s work may be a priority. Leaving this tracked for 39 for now.
For what it's worth, I can't reproduce this on either OS X or Windows (latest nightly builds). I think this is Linux-only.
Nice simple fix here. Basically, the menuitem's attribute is still called "selected", not "visuallyselected", and I inadvertently changed the CSS to trigger on "visuallyselected" for the menuitem for the alltabs popup. The rest of the machinery should still work fine, as the menuitem's "selected" attribute is set by calling the selected getter on the tab itself, which should do the right thing (
Attachment #8600023 - Flags: review?(mconley)
Attachment #8600023 - Flags: review?(mconley) → review+
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 40
Comment on attachment 8600023 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: Unable to visually determine which tab is currently selected by looking at the alltabs dropdown
[Describe test coverage new/current, TreeHerder]: Nightly users since last week; no automated tests
[Risks and why]: Very low risk; just reverts one CSS change that shouldn't have been made in the patch to bug 1066531
[String/UUID change made/needed]: None
Attachment #8600023 - Flags: approval-mozilla-aurora?
Comment on attachment 8600023 [details] [diff] [review]

Approved for uplift to aurora; this has been on central for a while, and fixes a regression.
Attachment #8600023 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.