345378 - [rfe] tab preview from all tabs menupopup

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, enhancement)

Description

[(not reading, please use [e-mail] instead)]

[rfe] tab preview from all tabs menupopup

this comes from john, see https://bugzilla.mozilla.org/show_bug.cgi?id=343251#c100

"How about showing a preview of tabs as the user hovers over them,
especially as some sites have the same title for all their pages. Temporarily
switching to it would probably be too confusing, but a picture of it could be
shown over the current tab. To prevent this from slowing down the UI, you would
only show it if the user hovers over a menuitem for a little while, like a
tooltip. Bonus marks for translucency ;)
Presumeably only P3."

I chatted with vlad about this, and he seemed interested in doing this (using canvas / drawWindow()

in addition to vlad, michael.wu (of Reveal fame) seems like someone who knows a thing or two about this.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: mockup from john

Comment 2

[Michael Wu [:mwu]]

Seth asked me to post some info on how rendering is done in Reveal, so here it is..

Reveal uses a number of tricks to minimize visible latency when it comes to rendering tabs:

1. Prerendering allows any number of tab previews to be shown in O(1) time. This is achieved by rendering at:
  a. Tab switch time. The tab that is made inactive is rendered.
  b. Page onload event. The tab is actually rendered a brief moment after the onload event to give the page a chance to render more images. Unfortunately, the load event does not load after css background images are loaded.
  c. Preview opening time. The active tab is rendered.

This works on the idea that the user should see the tab as he/she last saw it, not necessarily what is currently shown.

2. Latency in rendering at tab switch time is hidden by using a setTimeout so the new tab has a chance to render (to screen) before the old tab is rendered to canvas. The user is extremely unlikely to switch to another tab before taking a brief glance at the contents of the page, which is enough time to render the previous tab.

At the time Reveal was written, saving the contents of canvas was not possible. Otherwise, I would have added additional optimizations to save previews to disk to reduce memory usage.

The actual rendering code is also somewhat non-trivial because when determining the area of the page it wants to render, it must avoid including the scrollbars (unless they're in a frame) and it must gather accurate information on the location of the scroll position (there are two different, mutually exclusive places to gather this info).

Comment 3

[Peter Kasting]

(In reply to comment #2)
> This works on the idea that the user should see the tab as he/she last saw it,
> not necessarily what is currently shown.

Offhand, I can see pluses for both sides here, and I wonder if showing the tab "as it is now" might not be nicer (from a user perspective, ignoring technical ramifications).  With a good enough preview function, I can just mouseover the tab on my popup to see if that darn Quicktime movie is done loading yet, or whatever.  For pages which have changed their appearance since the user last saw them, this approach also seems less like "lying" to the user.  If I preview a tab one way and then select it and it looks different, it feels like the browser is either lying to me or just broken.

Comment 4

[Michael Wu [:mwu]]

(In reply to comment #3)
> Offhand, I can see pluses for both sides here, and I wonder if showing the tab
> "as it is now" might not be nicer (from a user perspective, ignoring technical
> ramifications).  With a good enough preview function, I can just mouseover the
> tab on my popup to see if that darn Quicktime movie is done loading yet, or
> whatever.
What? We can't render plugins.

> For pages which have changed their appearance since the user last
> saw them, this approach also seems less like "lying" to the user.  If I preview
> a tab one way and then select it and it looks different, it feels like the
> browser is either lying to me or just broken.
> 
No one cares. :) The only case where users actually notice the "lying" is when the browser was resized. That can be handled specifically if needed. Also, for cases that matter like tinderbox or gmail, onload works perfectly. Tab preview is about remembering what the tab/page was about, not getting a mini version of the page (like Opera prefers to do).

Also, I was not advocating my approach, I was merely outlining the approach taken in Reveal, which needed to be as fast as possible. Doing an update on mouse over would be vastly simpler and less prone to edge cases and failures. The primary advantage of a Reveal type approach (besides speed), however, is that extensions can use it.

Comment 5

[Peter Kasting]

(In reply to comment #4)
> > With a good enough preview function, I can just mouseover the
> > tab on my popup to see if that darn Quicktime movie is done loading yet, or
> > whatever.
>
> What? We can't render plugins.

Well, I was trying to come up with an example of something that takes a long time to load.

But it would be cool if we *could* render plugins.  Maybe some of roc's work is moving us in that direction.

> Tab preview
> is about remembering what the tab/page was about, not getting a mini version of
> the page (like Opera prefers to do).

I'm saying, I think "getting a mini version of the page" might be better.

It's probably not a big enough difference in behavior to worry about if there are strong technical reasons to prefer one over the other, though.

Comment 7

[:Felipe Gomes (needinfo for replies!)]

Old request with not a lot of activity, this kind of feature is best left implemented as an add-on