Closed Bug 1148879 Opened 5 years ago Closed 4 years ago
current tab in tab overflow dropdown is no longer identifiable (bold)
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: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e046475a75cb&tochange=ad587ca628cf
Multiple candidates in that one day window, primarily: https://hg.mozilla.org/mozilla-central/rev/8194018355f6 https://hg.mozilla.org/mozilla-central/rev/564a9e11d9ec (or maybe even their interaction). (I haven't tested to see which it is.)
Adding regressionwindow-wanted for a narrower regression window.
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8c02abfe5360&tochange=8194018355f6 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.
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.
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 (https://dxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml?from=tabbrowser.xml#5722)
Attachment #8600023 - Flags: review?(mconley)
Attachment #8600023 - Flags: review?(mconley) → review+
Comment on attachment 8600023 [details] [diff] [review] 0001-Bug-1148879-style-alltabs-item-off-the-selected-attr.patch 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] 0001-Bug-1148879-style-alltabs-item-off-the-selected-attr.patch 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.