Closed Bug 376930 Opened 17 years ago Closed 9 days ago

Overflow tab menu covers whole upper right part of my screen

Categories

(Camino Graveyard :: Tabbed Browsing, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: hwaara, Unassigned)

References

Details

Camino trunk, with the new overflow menu

DESCRIPTION OF PROBLEM:

The new overflow menu pops up with the currently selected item under the cursor. This may make sense in theory, but in practice it is not very user-friendly.

The reason is that more often than not, you are on the right-most tab (the newest one). When you pop up the menu it will cover the whole upper right of your screen because *all* other items are before it, in the menu.

I found this unexpected and annoying. 

SUGGESTED RESOLUTION:

Please make it behave like a context menu, or the Bookmark folder menus, where the menu starts under the cursor. 

That way I (the user!) feel like I am in control over this monster menu - whereas now, I am reluctant to even use it.
Also, this probably sucks more on small (MacBook) screens than on huge displays. Screen estate is expensive!
This was very deliberate. If it's a drop-down, then getting to the right-most
tabs is a huge PITA if you have a bunch of tabs. It's fundamentally unlike
bookmark folders and context menus; neither of them have a concept of a current
selection.

I'm not sure what you mean in comment #1. The menu is only shown while you are actively using it, so I don't see how showing as much as possible during that time could be construed as undesirable.
On the other hand, in support of "the current behavior isn't great", my windows tend to live at the top of my screen, and while testing the patch I noticed that left-hand tabs tended to be harder to get to as a result, so this may have just traded the usability of one side for the other.
Conceptually I agree with the decision to make the menu a pop-up, but in
practice I agree that it feels very awkward.  90% of my time is spent on the
rightmost tab too, and that ends up making our current implementation actually
show as *little* as possible.  I'm not really sure what the best thing to do
here is.
How about doing away with the already-displayed tabs from the menu? That would leave us with fewer items. 

Then perhaps displaying it in reverse order, so right-most in the tab order = upper-most in the menu?
(In reply to comment #5)
> How about doing away with the already-displayed tabs from the menu? That would
> leave us with fewer items.

If you are working in a set of tabs in the middle, how do you know where you are?
 
> Then perhaps displaying it in reverse order, so right-most in the tab order =
> upper-most in the menu?

I'm worried that reversing the order will be confusing, since in my mental model at least, ones further down are beyond me to the right, and our tab strip goes left to right, not right to left.

Since I live in the right-most tab a lot, I sympathize and am a bit annoyed by the tiny (4?) number of tabs I can see in the menu.  However, this is one of those bugs where "that which sucks least and is most consistent" is the best solution--whatever that may be :(
(In reply to comment #5)
> How about doing away with the already-displayed tabs from the menu? That would
> leave us with fewer items. 
That is what the WebKit build I have in front me does. But it does not do scrolling tabs.
It might work, in Camino's case (bearing in mind Smokey's comment): the separator could suggest 'you are here'. All entries before the separator are off-screen on the left, after the separator, on the right.

> 
> Then perhaps displaying it in reverse order, so right-most in the tab order =
> upper-most in the menu?
> 
That would confuse me (but I live mostly in the left-of centre tabs).

Another problem seems to be that the menu is drawn/built very slowly, so when I try to scroll up to get to a left-side tab, it takes a while and "stutters".

I suppose the old overflow menu did this as well, but since it dropped all the way down, I could still get a good 50 or so tabs into the list immediately rather than just 4.
Summary: Overflow menu covers whole upper right part of my screen → Overflow tab menu covers whole upper right part of my screen
So, I've found myself actively avoiding using the all tabs menu (when I used to use the overflow menu frequently) because of the issues I described in comment 8 (because I spend lots of time in the rightmost tabs).

Pulling this to 1.6 to keep it on the 1.6 radar better, but we should still decide if we want to do something before confirming.
Target Milestone: --- → Camino1.6
(In reply to comment #8)
> Another problem seems to be that the menu is drawn/built very slowly, so when I
> try to scroll up to get to a left-side tab, it takes a while and "stutters".
> 
> I suppose the old overflow menu did this as well, but since it dropped all the
> way down, I could still get a good 50 or so tabs into the list immediately
> rather than just 4.
> 

Is this strictly a performance concern? If so, please spin off a new bug, since that should be fixable independently of this bug.
We should find some way to target this for user feedback in a1.
(In reply to comment #5)
> How about doing away with the already-displayed tabs from the menu? That would
> leave us with fewer items.

There's not a lot of consensus on other ideas, but there seems to be some semblance of consensus on this. Can someone work up a patch that implements this behaviour? It's not going to help much for people who spend all their time in the right-most tab(s) and have >30 tabs per window open on a regular basis, but it'll help a lot for the more "normal" use case, I think.

cl
Er, we decided at last week's meeting to push this off until after 1.6, when we could evaluate any feedback we did get.

Confirming just because it's silly to stay UNCO and have a target of 2.0 or Future....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: Camino1.6 → Camino2.0
Has anyone heard any feedback on this since 1.6 launched?  It's really long since ceased bothering me.
I still don't like it when dealing with a big pile of tabs (> 30 or so), but I think comment 12 is about the best we're going to do, and I think it would be a huge help unless you're one of the four or five users who always has 200+ tabs open (in which case this feature either bothers you or doesn't at this point).
But no, I haven't heard any feedback about it. I suspect most of our user base doesn't keep enough tabs open at once for it to be a big issue.
Hardware: PC → All
Comment 12 seems really bizarre, though, since it defeats the entire purpose of the pop-up nature of the fix; we'd have a pop-up menu that pops open not with the current selection selected, but with some random off-screen item selected.
What about putting a blank space in the middle to represent the visible tabs and select that?
I'm not wild about the idea of removing the current tabs offhand (if it's not all tabs, having the left tabs on the right too seems more strange), but we could play with it.

If we do, I think we want comment 7; there needs to be a separator, so that would be the thing to select.
Since this has not turned out to be a big source of user pain, taking off the 2.0 list.
Target Milestone: Camino2.0 → ---
After all these years, we've finally gotten our very first(?) end-user complaint about this: http://forums.mozillazine.org/viewtopic.php?f=12&t=1460525

Two comments: 

1) The comment 7/comment 12 method drives me absolutely batty in Safari; I never end up where I'm trying to go.  I vehemently oppose doing this in Camino.

2) My comment 8 really was about perf displaying/scrolling the menu, it turns out; it's not at all an issue for me on my PBG4 with only 10 or 20 tabs in a window now, nor is it an issue on the MBP with 100+ tabs.  PBG4s were just slow :P

Given the lack of complaints and the absence of any decent solutions after all these years, my vote is to close this and let it be.
I'm fine with closing this, too, unless someone comes up with a solution better than what's been described here so far. The big problem is that the Firefox and Safari implementations don't scale to more than a couple windows' worth of tabs very well at all (nor did our old one).

I guess the question really becomes this: what's the average number of tabs (per window) our users are dealing with at once?

The Safari and Firefox implementations seem better for small numbers of tabs (enough to trigger the overflow, but less than, say, 20); our current implementation strikes me as superior for larger numbers of tabs (up to about 50). I'm not sure there's *any* solution that works well for people with hundreds of tabs per window, but they're probably the very small minority of our users anyway, and Sam and Smokey haven't complained too much about our current implementation ;)
Status: NEW → RESOLVED
Closed: 9 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.