Tab groups can push other groups across screen boundaries, making them invisible or causing groups to overlap

RESOLVED WONTFIX

Status

Firefox Graveyard
Panorama
P3
normal
RESOLVED WONTFIX
7 years ago
2 years ago

People

(Reporter: Tobbi, Unassigned)

Tracking

Dependency tree / graph

Details

(Whiteboard: [Aug-13-testday])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
See this screencast to see a detailled description of what I mean:
http://www.screencast.com/users/Tobbi_/folders/Jing/media/3c511774-3691-4124-b055-ec0d698cffe2

Groups can push other groups across boundaries, which make them invisible, or can cause them to overlap.
(Reporter)

Updated

7 years ago
Whiteboard: [Aug-13-testday]

Updated

7 years ago
OS: Windows 7 → All
Hardware: x86 → All
I can reproduce in [1], as well I see this happening if you resize the browser window to a small height, the bottom half of tab groups will cross their boundary.

[1] Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4pre) Gecko/20100813 Minefield/4.0b4pre
This will be corrected once bug 578512 is landed.
Depends on: 578512
Assignee: nobody → mitcho
No longer depends on: 578512
Priority: -- → P2
Note bug 578512 will not land before Firefox 4.
Duplicate of this bug: 601433
Blocks: 598154
I don't know that there's much that can be done about this.
No longer blocks: 598154
Priority: P2 → P3
can be reproduced as well in a normal sized window.  

1) Set a smallish sized group next to the right edge of the view. 
2) Then with larger sized group, DnD it such that it is also on the far right edge of the view and completely covering the smaller group.

Notice the smaller group get shoved off view to the right (all but one pixel width)

Note: moving the larger group back left does allow the hidden group to reappear.

Comment 7

7 years ago
A solution is to have groups to have a minimum size, after which they cannot be compressed anymore.
Blocks: 598154
Target Milestone: --- → Firefox 4.0
(In reply to comment #7)
> A solution is to have groups to have a minimum size, after which they cannot be
> compressed anymore.

Actually, the larger the minimum size, the more likely you are to encounter this issue; groups only get pushed off the side of the screen when they run out of room to squish down.

Updated

7 years ago
Duplicate of this bug: 604542
Created attachment 485619 [details]
Proposed interaction: pushing away as we interact (webm)

I started working on this bug today, first by taking the approach of simply adjusting the active group's bounds before setting it and pushing away everything off the edges, based on the other groups that are around. In other words, you can drag out a new group on top of lots of other groups, and when you let go, it'll snap to a smaller size than the user requested.

This approach has two problems: (1) technically, computing this "largest rectangle that doesn't squish its neighbors more than we need to" is tricky and I'm not happy with what I have now; (2) interaction-wise, I don't think this is a good idea. It makes much more sense (for me) to actually give direct feedback to the user in terms of what kinds of groups of what size can be made, but then actually respecting the user input, instead of snapping the user's active group rect, which they just wanted to set, to a different size.

An alternative approach—actually pushing other groups away as we resize new groups—seems to me to be a much more user-friendly way to go. A very rough first pass at this is captured in the attached video.

Since all groups of any decent size* are currently being created with a user-specified rect, I believe this will actually capture all the cases (except perhaps resizing the window, awaiting spec in bug 601534) where we are currently pushing things off the screen.

*Groups of a "not decent size" which are created without a user-specified rect are when, for example, you have an orphan tab and you open a new tab from that tab, turning it into a group. This is not a case where we have a problem with pushing things off the edge, though. In the future, for other programmatic instances of groups being created without a user-specified rect, we have bug 592932.
Attachment #485619 - Flags: ui-review?(aza)
Attachment #485619 - Flags: feedback?(ian)
Comment on attachment 485619 [details]
Proposed interaction: pushing away as we interact (webm)

I'm not in favor of pushing while resizing (or dragging), for a couple of reasons: 

* Our dragging and resizing is already too slow and this will only make it slower.
* Especially when dragging, but even when resizing, the user needs to be able to lift the group "above" the other objects without disturbing them, otherwise it devolves into a sliding blocks puzzle.

I'm still not convinced this bug is something we can/should fix in the ff4.0 time frame. Thing A shoves thing B off the window, you move thing A out of the way and thing B returns; not ideal, but not devastating. It's mathematically impossible to make this never happen (imagine, say, a 200 x 200 pixel window with 500 groups in it), so we're just talking about making it less likely. Chasing down all the exceptional situations will take some time/effort. 

At any rate, we might as well discuss strategies. 

I actually think I like the notion of having it resize (or move) for you after you've dropped; if you've stuck thing A in a spot that's going to force thing B off of the window, it squishes thing B as much as it can but then automatically pushes thing A back (squishing if necessary but preferring not to) out of the way. As long as it's animated, it's pretty clear what happened. 

Even with that, it'll still be possible for people to get things totally wedged, say by dropping a group on pile of minimum sized groups that are already jammed against the edge. One strategy would be to disallow this entirely, sending it back to where it came from. This would be a problem if it was just the spontaneous creation of a group out of an orphan, though that would be fine if the minimum group size was the same as the minimum tab size. Another strategy would be to detect such situations and do some sort of massive rearrangement of all of the items on the screen so that they somehow fit (again animated so the user can tell what's going on). 

Of course at some point there's just no more room; everything is wedged so tightly that nothing can be added or moved. Perhaps at that point we need some sort of mode-switch, like how groups turn into stacks. Maybe at some point all of Panorama turns into something more compact, even if it's just a sign that says "make this window bigger or delete some tabs!" I don't know, maybe some sort of scrolling text list, as ugly as that sounds?
Attachment #485619 - Flags: feedback?(ian) → feedback-
(In reply to comment #11)
> Comment on attachment 485619 [details]
> Proposed interaction: pushing away as we interact (webm)
> 
> I'm not in favor of pushing while resizing (or dragging), for a couple of
> reasons: 
> 
> * Our dragging and resizing is already too slow and this will only make it
> slower.
> * Especially when dragging, but even when resizing, the user needs to be able
> to lift the group "above" the other objects without disturbing them, otherwise
> it devolves into a sliding blocks puzzle.

Makes sense for me.

I like the various use cases and strategies that you've mentioned. We need a behavior spec. Assigning to Aza for spec work.
Assignee: mitcho → aza
Status: NEW → ASSIGNED

Updated

7 years ago
blocking2.0: --- → ?
Blocking. At the very least, groups shouldn't be able to be pushed off-screen.
blocking2.0: ? → final+
Note that if we have the resize behavior defined in this spec: 

https://bug601534.bugzilla.mozilla.org/attachment.cgi?id=487880

... another option is to grow the "canonical bounds" whenever something gets pushed off the edge, thereby resizing everything down.
Bumping up to b8 in response to the blocking flag; better to give these changes longer to soak, as there may be unexpected consequences.
Blocks: 597043
No longer blocks: 598154

Comment 16

7 years ago
Ian, I like the solution of growing the bounds when we are up against the wall, so to speak.
Depends on: 601534
Attachment #485619 - Attachment is obsolete: true
Attachment #485619 - Flags: ui-review?(aza)
Created attachment 489787 [details]
Screenshot of Automatically-Misplaced Tab-Group

*** Something 'very' similar to this bug, if not the same. Guide me if I should have filed a new bug.

Reproduction :
* Create & dock tab-groups to fill the entire available space.
* Go to any group in left & browse (& open/close tabs etc.)
* Come to the panorama-management page (by button or Ctrl/Cmd+E)
>>> Here you see the top-right group is misplaced, elevated & clipped out of view partially.

Updated

7 years ago
Blocks: 598154

Comment 18

7 years ago
Beta8 has 1 bug left on it, moving our blockers to b9
No longer blocks: 597043
Reverting blocking on this. The cost and risk of fixing this appears too high to risk the release on. If there's a way to mitigate this problem with a well-contained and well-tested patch, then request approval on that.
blocking2.0: final+ → -

Comment 20

7 years ago
Ian, what does our code path look like on this? How volatile is it?

Updated

7 years ago
Assignee: aza → ian
(In reply to comment #20)
> Ian, what does our code path look like on this? How volatile is it?

The relevant code is more or less self-contained in Item.pushAway(). Comment 11 is still a good overview of what our options are. I'd say we could make some progress on this without much risk, but it's unlikely we'll fix it entirely. Also, note that bug 601534 should give us some additional possibilities.
I'm hoping to get 601534 wrapped up for beta 9. I hope to update this bug with thoughts after that.

Comment 23

7 years ago
bugspam (moving b9 to b10)
Blocks: 608028

Comment 24

7 years ago
bugspam (removing b9)
No longer blocks: 598154
(In reply to comment #21)
> (In reply to comment #20)
> > Ian, what does our code path look like on this? How volatile is it?
> 
> The relevant code is more or less self-contained in Item.pushAway(). Comment 11
> is still a good overview of what our options are. I'd say we could make some
> progress on this without much risk, but it's unlikely we'll fix it entirely.
> Also, note that bug 601534 should give us some additional possibilities.

Note: we've decided to punt on 601534 for fx4. I (or someone else) will hopefully look into tweaking pushAway, though, to improve this behavior.
Assignee: ian → mitcho
Depends on: 625668
Punting. Based on our current priorities and strategy for this bug, we will not completely solve it by fx4. Sad but true.
No longer blocks: 608028
Target Milestone: Firefox 4.0 → Future
Assignee: mitcho → nobody

Updated

7 years ago
Duplicate of this bug: 644724
Status: ASSIGNED → NEW
Duplicate of this bug: 648859
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111109 Firefox/10.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0

Issue is still reproducible on the latest Aurora and Firefox 9 beta 1.
Created attachment 573802 [details]
Screenshot describing the issue
As reported, this bug does still occurs on Fx 8 and latest Aurora build.

Simona B, that screenshot is not this bug. Please see screencast in original comment and/or my post in comment #6. This bug is about groups can be pushed out of the group your tabs window.

Comment 32

6 years ago
(In reply to Soumya Deb [:Debloper] from comment #17)
> Created attachment 489787 [details]
> Screenshot of Automatically-Misplaced Tab-Group
> 
> *** Something 'very' similar to this bug, if not the same. Guide me if I
> should have filed a new bug.
> 
> Reproduction :
> * Create & dock tab-groups to fill the entire available space.
> * Go to any group in left & browse (& open/close tabs etc.)
> * Come to the panorama-management page (by button or Ctrl/Cmd+E)
> >>> Here you see the top-right group is misplaced, elevated & clipped out of view partially.

"Go to any group in left & browse (& open/close tabs etc.)" - actually you only have to close a tab in non-panorama mode. It seems like some kind of auto-arrange event is fired when a tab is closed in non-panorama mode. If this is true, than it doesn't make sense to me: Isn't this just a waste of CPU calculations at tab close?
Panorama has been removed from Firefox 45, currently in Beta and scheduled for release on March 7th. As such, I'm closing all existing Panorama bugs.

If you are still using Panorama, you will see a deprecation message in Firefox 44, and when 45 is released your tab group data will be migrated to bookmarks, with a folder for each group. There are also a few addons offering similar functionality.

See https://support.mozilla.org/en-US/kb/tab-groups-removal for more info.

We're removing Panorama because it has extremely low usage (about 0.01% of users), and has a large number of bugs and usability issues. The cost of fixing all those issues is far too high to justify, and so we'll instead be focusing our time and energy on improving other parts of Firefox.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

2 years ago
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.