464205 - all tabs preview is disconnected from the window and oversized.

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[philippe (part-time)]

Attachment: screen shot: fragment of my browser window

Actual result: 
The  all tabs preview is hooked to the user' screen, independently of width (size) and position on screen of browser window. If the user has multiple windows open, there is no clear relation between the tabs preview and that window.

Expected result:
Do something sane with the all tabs preview.

The all tabs preview should be sized to the width of the window (and autosize in height, but that appears covered by bug 464122), and positioned relative to the browser window, not the screen.

Conceptually the current implementation might fit for someone surfing with the browser window open in full screen. Users who surf with smaller windows, not necessarily positioned at top of the screen are overwhelmed. It is absolutely not clear how that preview relates to the current active window.

In the attached screenshot, the preview jumps out of the open window, far away form where my attention is focused

There is no way to control the size/positioning of the all tabs preview by themes or user stylesheets.

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

To provide some background, if we restrict to the window size we can't really show thumbnails in a way that is useful, particular for large numbers of tabs.  Also, the UI is meant to be transient, you are only interacting with it briefly before returning to Firefox, so during that transition we overlay your other apps, but the visual feedback is quickly dismissed.  cc'ing boriss since she is driving the design work on this.

Comment 2

[philippe (part-time)]

(In reply to comment #1)
> To provide some background, if we restrict to the window size we can't really
> show thumbnails in a way that is useful, particular for large numbers of tabs. 

I fail to see how this relates. If someone has a smaller monitor, the problem is the same... And the preview images scale depending on the width of the tab-preview pane.
(try setting a max-width to that object: #ctrlTab-panel {max-width: 900px !important;} - tested on my 1980px wide monitor)

> Also, the UI is meant to be transient, you are only interacting with it briefly
> before returning to Firefox, so during that transition we overlay your other
> apps, but the visual feedback is quickly dismissed.

It is not about blocking other aps form view, it is all about the relationship with the browser window where the tabs are located.

Comment 3

[Thomas Stache]

(In reply to comment #1)
> To provide some background, if we restrict to the window size we can't really
> show thumbnails in a way that is useful, particular for large numbers of tabs. 

Preamble: I'm testing Shiretoko on a 24" screen.

The way it is now, the All-Tabs panel appears _somewhere_ on the screen, not where I'm looking and focussing. Add a couple of open overlapping app windows and a patch of the desktop background to the mix, and it's *really* hard to make out the previews and tab titles.

Restricting to the browser window could improve the "visual noise" situation. I see that the notes in http://pastebin.mozilla.org/571525 contain the quote:
"<-- all tabs in tabstrip order
 <-- pagination entries if needed
 <-- overlays entire browser window",
so maybe the design is moving into this direction anyway...

Comment 4

[philippe (part-time)]

Dao, any thoughts on this ?

Comment 5

[Dão Gottwald [:dao]]

I think we should avoid scrolling or other overflow scenarios in the all-tabs panel, as they would complicate the UI. We also don't want the previews to shrink more than needed. Therefore I don't think the panel size should be limited to the size of non-maximized windows.

Comment 6

[philippe (part-time)]

(Sorry for slow response - I simply forgot the hit the commit button...)

So WontFix then ?

Mind you, the whole issue is much less important to me now, with the 'browser.allTabs.previews' pref. I hope it stays there, I can always flip to false if needed :-).

(In reply to comment #5)
Therefore I don't think the panel size should be
> limited to the size of non-maximized windows.

I still don't fully understand how that makes a difference; what about the people with a smaller monitor ? (1100px~1200px, macBook)

Comment 7

[Dão Gottwald [:dao]]

(In reply to comment #6)
> Mind you, the whole issue is much less important to me now, with the
> 'browser.allTabs.previews' pref. I hope it stays there, I can always flip to
> false if needed :-).

It's not expected to stay there forever.

> I still don't fully understand how that makes a difference; what about the
> people with a smaller monitor ? (1100px~1200px, macBook)

Smaller screens get smaller thumbnails with more truncated titles. That's not ideal either.

Comment 8

[Peter Lairo]

Smaller screens and non-maximized windows is what those users *chose*. Their browser window will be at a size they want and can use. Therefore, they will likely be perfectly happy if the thumbnails also fit into that chosen space. Having internal browser UI spill out over the browser and into the OS is just wrong.

e.g. I have my browser windowed (non-maximized) and slightly to the left of the screen (to allow me to see my Win7 Gadgets on the right). Having the thumbnails preview pane lopsided relative to my browser and spill outside my browser on one side is highly irritating and disorienting.

Comment 9

[Dão Gottwald [:dao]]

Attachment: stick the panel to the content area and style it accordingly

Comment 10

[Markus Stange [:mstange]]

+    const PANEL_MAX_HEIGHT = Math.max(gBrowser.selectedBrowser.clientHeight,
+                                      screen.availHeight / 2);
+    const PANEL_MAX_WIDTH = Math.max(gBrowser.selectedBrowser.clientWidth,
+                                     screen.availWidth / 2);

Querying for clientHeight / clientWidth will flush layout. Since the panel hasn't been reflowed at this point, the flush can cause the panel to resize temporarily, for example after dragging a preview to a different row. Can you move these lines somewhere else, for example to allTabs_open() before opening the panel, where flushing layout doesn't do any harm?
At least on OS X, a resizing panel will redraw its contents synchronously, so the unreflowed state actually makes its way to the screen. This results in a very unpleasant flash.

Comment 11

[Dão Gottwald [:dao]]

Attachment: stick the panel to the content area and style it accordingly, v2

as suggested

Comment 12

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/bbf9ca4be46f