Open
Bug 927173
Opened 11 years ago
Updated 2 years ago
Australis: scrolling tabs into view doesn't work very well
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
NEW
People
(Reporter: Gavin, Unassigned)
References
Details
(Whiteboard: [Australis:P5])
Attachments
(1 file)
(deleted),
image/png
|
Details |
STR:
1) Open enough tabs to get into overflow (be generous)
2) Select the first tab
3) Scroll the tab strip to the end (but don't select another tab)
4) Close the selected tab (Cmd+W)
Expected: tab closes, next tab selected and scrolled into view
Actual: tab closes, next tab selected and only a little bit of it is scrolled into view (see screenshot)
Reporter | ||
Comment 1•11 years ago
|
||
(I'm using today's UX build, Mac)
Reporter | ||
Comment 2•11 years ago
|
||
Similar issue occurs if you manually select a new tab instead of closing the current tab (e.g. replace step 4 with "press Cmd+2 to select the second tab").
Summary: Australis: closing a tab that's scrolled out of view doesn't scroll the new tab into view properly → Australis: scrolling tabs into view doesn't work very well
Updated•11 years ago
|
Blocks: australis-tabs
Whiteboard: [Australis:M?][Australis:P?]
Updated•11 years ago
|
Whiteboard: [Australis:M?][Australis:P?] → [Australis:M?][Australis:P5]
Comment 3•11 years ago
|
||
Marking this as P5 since the comment #0 STR are pretty edge-casey and I don't think that flow is likely to be hit by many users. Comment #1 is no longer an issue since bug 875180 has been fixed.
Updated•11 years ago
|
Whiteboard: [Australis:M?][Australis:P5] → [Australis:P5]
Comment 4•10 years ago
|
||
So this is caused by the fact that we set the selected tab to the next tab, but then we remove the previous tab, and so we scroll by exactly not enough, so to speak. :-)
In particular, in removeTab(), we call _blurTab(), which ends up setting the selected tab, causing us to scroll it into view. Then we remove the other tab.
What we should do is make sure that ensureElementIsVisible works irrespective of the tab animations which are in progress. However, I don't have any great ideas on how to make that happen...
The alternative would be calling ensureElementIsVisible a second time, but that's kind of sucky...
Gavin, do you have ideas, seeing as you filed this? ;-)
Flags: needinfo?(gavin.sharp)
Reporter | ||
Comment 5•10 years ago
|
||
Well the obvious answer is "only call ensureElementIsVisible after removing the tab", but I have no idea how feasible that is or what the constraints here are.
Flags: needinfo?(gavin.sharp)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•