Single-tab mode: determine tab width |
|||||||||
Issue descriptionCurrently single-tab windows use the same tab layout as normal windows. This causes problems like "tab title appears to be truncated for no reason" and "pinned tabs just show an audio icon in an empty frame". Instead, in single-tab mode, we should always render tabs with some title width, and that title width should probably be wider than the normal default width. My suggestion is to just let the tab take as much space in the tabstrip as it wants; anything else will look broken. P1 since without this single-tab mode feels sort of pointless.
,
Jun 1 2018
Re-prioritize: it's P1 within single tab but not P1 overall.
,
Jun 1 2018
Issue 847906 has been merged into this issue.
,
Jun 7 2018
Already in spec. Please check.
,
Jun 7 2018
I realize there's a spec on this, but I really think any width less than the full width is likely to feel broken. It would be helpful to know bettes' thought process on this stuff, so that any reasons why he disagrees/rationale for choosing 390 can be kept in mind as we try to implement here.
,
Jun 11 2018
Capturing triage conversation: Probably best to balance drag window action with drag tab action, thus not full-width, but maybe some fraction of tab with, like 80% or something. bettes to work out easy path forward with bsep@
,
Jun 18 2018
,
Jun 18 2018
Ideally the window should still be easily draggable even if we let the tab take up the full width allotted for tabs -- or else the window won't be very draggable once the user opens several tabs. I mean, 80% of tabstrip width is maybe OK, it just seems like it's still going to feel a bit arbitrary and potentially buggy to people. Anyway, I've said my piece, I won't kibitz more.
,
Jun 19 2018
Why isn't tab dragging equivalent to window dragging when there is only one tab? It certainly seems to be equivalent from cursory testing. Similar issue is that the tab context menu and window context menu contain different (but overlapping) things. Ideally there wouldn't be one different context menu accessible from clicking anywhere in the 0%-80% range, and another context menu in the 80%-100% range. I filed a separate bug about this, Issue 854007 .
,
Jun 19 2018
If in single tab mode we always dragged the window, you could never drag this tab into another window's tabstrip. If we always dragged the tab, you couldn't move the window over another Chrome window without getting sucked into its tabstrip.
,
Jun 19 2018
#11 Eek, that is a good point, but how is a user going to be aware of the very subtle difference between "dragging a tab" and "dragging the window", when the window is the tab and there is no visual distinction between the two. I think it makes more sense to always drag the tab, rather than always drag the window. Being able to drag a single tab into another window's tabstrip is more important (especially as a way to "undo" accidentally dragging a single tab out!) than preventing it. You can always avoid getting sucked into another window's tabstrip by moving to a different location. I agree it's not ideal, but it's just surprising and undiscoverable if there is any arbitrary tab width that's not the full width (as you said in #6).
,
Jun 19 2018
Partly overlapping Chrome windows is pretty common. IMO the right solution here is still "in single-tab mode, the tab's width is the width of the tab title + favicon". The visual distinction is basically "did you drag the favicon, or the blank space".
,
Jun 28 2018
Punting to 70
,
Jun 28 2018
On the deck discussing this, I think there was sentiment for "leave the width alone for M69; for M70+, set the width to ClampToRange(title width, min, max), where "min" is the current standard tab width, and "max" is ~400 DIP."
,
Jun 29 2018
,
Jul 10
,
Jul 10
,
Jul 12
,
Sep 20
,
Sep 26
,
Oct 8
Closing all Single-Tab Mode bugs as we pursue a new direction in this area. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by robliao@chromium.org
, May 31 2018Status: Assigned (was: Untriaged)