Tobias (:Tobbi) Markus Reporter
	Description • 14 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.

	Aaron Train [:aaronmt]
	Comment 1 • 14 years ago

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

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 2 • 14 years ago

This will be corrected once bug 578512 is landed.

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 3 • 14 years ago

Note bug 578512 will not land before Firefox 4.

	Ian Gilman [:iangilman]
	Comment 5 • 14 years ago

I don't know that there's much that can be done about this.

	Tracy Walker [:tracy]
	Comment 6 • 14 years ago

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.

	Aza Raskin [:aza]
	Comment 7 • 14 years ago

A solution is to have groups to have a minimum size, after which they cannot be compressed anymore.

	Ian Gilman [:iangilman]
	Comment 8 • 14 years ago

(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.

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 10 • 14 years ago

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.

	Ian Gilman [:iangilman]
	Comment 11 • 14 years ago

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?

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 12 • 14 years ago

(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.

	Dietrich Ayala (:dietrich)
	Comment 13 • 14 years ago

Blocking. At the very least, groups shouldn't be able to be pushed off-screen.

	Ian Gilman [:iangilman]
	Comment 14 • 14 years ago

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.

	Ian Gilman [:iangilman]
	Comment 15 • 14 years ago

Bumping up to b8 in response to the blocking flag; better to give these changes longer to soak, as there may be unexpected consequences.

	Aza Raskin [:aza]
	Comment 16 • 14 years ago

Ian, I like the solution of growing the bounds when we are up against the wall, so to speak.

	Soumya Deb [:Debloper]
	Comment 17 • 14 years ago

*** 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.

	Kevin Hanes
	Comment 18 • 14 years ago

Beta8 has 1 bug left on it, moving our blockers to b9

	Dietrich Ayala (:dietrich)
	Comment 19 • 14 years ago

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.

	Aza Raskin [:aza]
	Comment 20 • 14 years ago

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

	Ian Gilman [:iangilman]
	Comment 21 • 14 years ago

(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.

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 22 • 14 years ago

I'm hoping to get 601534 wrapped up for beta 9. I hope to update this bug with thoughts after that.

	Kevin Hanes
	Comment 23 • 14 years ago

bugspam (moving b9 to b10)

	Kevin Hanes
	Comment 24 • 14 years ago

bugspam (removing b9)

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 25 • 14 years ago

(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.

	Michael Yoshitaka Erlewine [:mitcho]
	Comment 26 • 14 years ago

Punting. Based on our current priorities and strategy for this bug, we will not completely solve it by fx4. Sad but true.

	Simona Badau, Desktop QA
	Comment 29 • 13 years ago

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.

	Tracy Walker [:tracy]
	Comment 31 • 13 years ago

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.

	Greg Karz
	Comment 32 • 13 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?

	Justin Dolske [:Dolske]
	Comment 33 • 9 years ago

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.