Closed Bug 153016 Opened 22 years ago Closed 14 years ago

Bookmark groups should insert rather than append.

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: jasonb, Unassigned)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020618 BuildID: 2002061808 (Carried over from bug 134800.) I think that the focused tab should be replaced by the 1st tab in the group, and all other tabs in the group inserted between the focused tab and any other tabs to the right. This keeps the tabs in a contiguous grouping (which I don't think anybody really objects to) but keeps the usage of bookmarks consistent with how single bookmarks work. With a single bookmark, the currently focused tab is replaced, and a group bookmark comprised of only one bookmark should behave the same as a regular bookmark. I think that group bookmarks should behave as close to single bookmarks as much as possible (to avoid confusion), but also maintain their grouping and prevent dataloss. This seems the most logical way of doing it to me. (The back button would then change the focused tab back to what it was previously, but the other inserted tabs would remain.) One thing this would address is the very annoying "hanging left tab" syndrome I now see. I run Mozilla and immediately open a tab group. Now I'm left with a left-most tab that I don't care about and have to always close in annoyance. If I *want* to keep all my currently focused tab I'd simply create a new tab, switch to it, then load my tab group from there. Reproducible: Always Steps to Reproduce: 1. Open a group tab. Actual Results: Tabs are all appended. Expected Results: Focused tab should be replaced by the 1st tab in group, remaining tabs in group should be *inserted* to the right of the focused tab.
I'd like to vote against this bug. :-} I like the behavior as it is now. It is consistant with how single tabs open; at the end of the current list of tabs. IMHO, a bookmark group of 1 tab doesn't need to act like a normal bookmark, because it is a 'group'; distinctly different from a normal bookmark. Jason, would the ability to use a tabgroup as a 'homepage' make this better for you? That would solve the 'empty tab' issue I think. (if I understand your usage of groups correctly).
BTW, the tabgroup homepage bug is bug 118835
It does little good to file a bug against something "caused" by my fix without assigning me the bug, or at the least CC'ing me. Carrying over from 134800, we decided on the append method for now because it is the least destructive way of doing things. And let me re-iterate that *we have no clue what method users prefer here!* We know for a fact that the old behavior of clobbering every tab is bad. The append method is not necessarily intended to be the optimal solution. However, to discern what the optimal solution is requires usability testing. There are going to be some people that love this behavior and some that don't. So, I think for now the decision is going to be to stick with what we have and if and when we get data that clearly shows that a different way of doing things is better, we will go with that. For now though, it is useless to get into a fight over which way is best as it won't change anything. And I strongly recommend looking for newsgroup feedback. At this point, opinions on the newsgroup will be invaluable.
Assignee: ben → caillon
Having a tab group as a homepage won't help me, since I certainly don't always want the tab group loaded when I start the browser. I only want to have it open occasionally - and when I do, I open the browser then immediately load the tab group (then in frustration close the single tab on the left <grin>). Here's a graphical depiction of exactly why I think that this behaviour is closest to how single bookmarks work. Single bookmark (Tab 2 has focus): Before: Tab 1 [Tab 2] Tab 3 After: Tab 2 [New Tab 2] Tab 3 Group bookmark: Before: Tab 1 [Tab 2] Tab 3 After: Tab 1 [New Tab 2] Tab 3 Tab 2a Tab 2b Tab 2c Now, currently we have nothing in place to accomodate "tabs within tabs" (although I believe that there's some bug open on that too). So, since we can't accomodate the "columnar" aspect described above, the only way to represent it is to "flatten" it out into individual tabs. (Another possibility along the lines of tabs within tabs, is to make [New Tab 2] a drop down combo box with the list of sites included in the bookmark group - you could then pick which site you want that tab to show at any given time, but have "all sites" still contained within the single tab...) In any case, representing the above as closely as possible with what we currently have in place gives us this: Tab 1 [New Tab 2] Tab 2a Tab 2b Tab 2c Tab 3. Christopher: My apologies for not assigning it to you automatically. I've never opened a bug in this situation before and I can now see why not doing as you suggest might be thought of as a faux pas.
Jason, the argument against what you propose is that it moves existing tabs around. Moving things in the User Interface is considered to be a Bad Thing(tm). The user has likely already become accustomed to where his/her tabs are and has a general idea as to the history of each. With your proposal, the user now has to think about what tabs are which, where they are, etc. I originally thought that your proposal was the best way to go about doing this, and in fact, this behavior was already proposed in bug 134800 by the initial reporter, but looking back on it, I think the insertion method is very unintuitive. While it sounds like a good idea, it is very confusing to use if you have several existing tabs open. Also note, that the reporter of bug 134800 originally requested the behavior you want (Bug 134800 Comment 0), but then retracted that as he was extremely pleased with the new behavior instead. (Bug 134800 Comment 40).
I don't think I *personally* agree that moving existing tabs to the right to make room for a tab group insertion would confuse everybody or even most people. Still, I do see your point that it might well confuse SOME people, and we don't want to do that. (Perhaps a suggestion would be to make the tabs in a tab group a different colour, in order to visually draw the eye to them and help people not lose track of what what's happening?) In any case, would it not be possible to add a setting to the tab group folder itself, such that it determines the behaviour of it when it's sub-tabs loaded? Just as you have keywords, descriptions, and schedules / notify assigned to individual tabs, could not append or insert be something that's settable in the Bookmark Manager for each tab group folder? (The default could be append.) At first I thought of context menus and keyboard accelerators - but that would be WAY too much of a headache on top of an already confusing array of options. But a simple setting in the BM shouldn't be that difficult to accomplish and I don't think it would add any real UI complexity.
> make the tabs in a tab group a different colour, please don't. > would it not be possible to add a setting to the tab group folder itself, > such that it determines the behaviour of it when it's sub-tabs loaded? it's technically possible, but thankfully our UI people will veto that.
> it's technically possible, but thankfully our UI people will veto that. Why "thankfully" and how do you know it will be vetod? (I'm looking for discussion / explanation here, not just short statements. If you want the latter you might as well just close the bug and mark it WONTFIX without comment. <grin>)
I finally installed Multizilla to see how they handle tab groups. (After backing everything up.) It lets you choose between Mozilla's current behaviour, and its old complete replace (and add if necessary) behaviour but without the dataloss - any tab that's been replaced will still let you hit the Back button to go back to its previous state. However, I was annoyed enough with its "toy-like" interface, other aspects of its UI, such as moving the new tab and close tab buttons to a separate toolbar, and the proliferation of simple UI clutter, that I removed it and went back to vanilla Mozilla - even though that meant I lost the ability to load tab groups in, to me, a much better fashion. Despite Mozilla's lack of this ability, I still find it to be preferable in its UI simplicity. I certainly don't want Mozilla's UI turned into the almost nightmarish proliferation of preferences and toolbars that Multizilla seems to exhibit. (Even granting that there may be some people who like it - and those should use it, but they shouldn't be brought over to Mozilla.) But I still don't see anything wrong with adding a setting to the properties of group tab folders that determine the method in which their sub-items are opened on the tab bar. Comment 7 seems to indicate that the UI people would veto it - but it wouldn't add anything to the existing Edit / Preferences menu, it wouldn't add anything to the existing visual UI during normal browsing experiences, and, in fact, would help delineate tab group folders from regular folder in the Bookmark Manager in a helpful fashion. (Currently, the only thing that a user notices about them is that they have a different icon.)
*** Bug 156903 has been marked as a duplicate of this bug. ***
I agree with claudius' proposal (namely, this bug). The current behaviour is definitely better than what we had before, though! :-)
Ah...this is my my proposal, not Claudius'. He hasn't posted a comment here yet. I also checked bug 134800 and, aside from the final comment, couldn't find find support for this proposal there either. But, who am I to complain? I could use some support here! <grin> Are you in favour of the tab group folder setting as per comment 6 or did you have something else in mind?
No, I don't support having settings for this, it should just be the behaviour and that's all. :-)
> it should just be the behaviour and that's all. :-) Okay, I can go along with that too. <grin>
*** Bug 157411 has been marked as a duplicate of this bug. ***
I think we were really close to the correct behavior way before we went and changed everything. There was a bug that needed fixing - but we didn't have to go and fundamentally change the way tabs open.I recognize we needed a quick fix to satisfy the upcoming release, but let's not try to shoehorn the quickfix in permanently. Let's go back and simplify everything. Here's a sol'n that keeps things damn near the way they were (which seemed intuitive to me) but of course doesn't destroy tabs. I'll describe two scenarios: first, you have 2 open tabs and you open a group of 3, and secondly you have 3 open tabs and you open a group of 2. The single tab/bookmark case works exactly the same way(as it should, right Hixie) so no need to address it specifically. Scenario 1: Two tabs open and pref set to open tabs in background.[this tab has focus]. You click a group of 3 tabs. Before: Tab1 [Tab2] After: NewTab1 [NewTab2] NewTab3 This is just like clicking a bookmark, when you load it, it replaces the page you're looking at. If you want that old page back - click 'back', there's no dataloss. Scenario2: 3 tabs open, pref set for background, click group of 2 Before: Tab1 [Tab2] Tab3 After: NewTab1 [NewTab2] Tab3 There's nothing magic or fancy here. The reason it's easy to explain is because it straightforward and consistent. There are no(or not many) 'if's and 'and's. The metaphor i see is dealing out a card game. Just deal out the tabs starting from the left. With consitentcy comes understanding. The only subtlety in my plan is that the current pref for 'open tabs in background' would serve a dual role. Without it set, focus would always revert to the leftmost(first) and newly opened tab([NewTab1]). This is a different proposal and should techincally be in a different bug, but i promised to deliver a BookmarkGroup Manifesto. so here it is. One could summarize this idea as "Bookmark groups should replace smartly rather than append".
I like this a lot (I've suggested it a couple of times, mostly offline). I seem to recall though that some people thought there were problems with this too (users not able to find that ready-to-submit form that is now hiding behind the back button in one of the tabs). Caillon, do you remember? cc'ing marlon and lori who were part of the discussion that led to "always append".
The two proposed scenarios are for pref settings that aren't even the default. Granted, we need to make this work regardless of the prefs, but what are the proposals for when the "Load tabs in background" preference is turned off (the default value)? I think we should look at that first, and then see how a proposed solution there fits with loading in background turned on.
I think the assumption was made that when the load-in-background pref is off the first tab of the set is focused (in this case always the first tab in the window): Scenario 1: Two tabs open, click a group of 3 tabs. Before: Tab1 [Tab2] After: [NewTab1] NewTab2 NewTab3 Scenario 2: Three tabs open, click a group of 2 tabs. Before: Tab1 Tab2 [Tab3] After: [NewTab1] NewTab2 Tab3
I strongly disagree with anything that affects tabs other than the one I have focussed, whether that be to close them or to change what they are pointed at.
To clarify: I have bookmark groups with over 40 items in them which I use *regularly*. I also manually open over 80 tabs (bugzilla bugs that have changed since I last checked) *regularly*. If I ever open one of the bookmark groups while the bugs are open, I do NOT want to have to go through hitting the back button 40 times. Especially considering any of those tabs could have un-cached form content (e.g. on pages where the form is dynamically generated), which would still lead to dataloss. The current behaviour is fine; IMHO an improvement to it would be to replace the active tab with the first tab of the group (this makes the one bookmark group simplify to be equivalent to a simple bookmark), and insert the other tabs to its immediate right, but that is only a minor difference compared to not clobbering my active tabs.
First of all, this particular bug is about inserting (except for the focused tab) rather than replacing. Claudius/Jag: Both of you are suggesting a couple of things that I don't agree with / feel address this bug. First of all, you are changing the contents of tabs to the LEFT of the currently focused tab. if appending bookmarks is "bad", I don't think that prepending is any better. Regardless of whether they should insert, replace, or append to the RIGHT, I don't think anybody wants tabs to the left to be touched. When you load a bookmark you replace the currently focused window - so when you load a bookmark group you should be replacing everything *starting at* the currently focused window. Tabs to the left should be off limits. Secondly, while I might personally not have a problem with replacing all tabs to the right, that's not what this bug is about. Tabs to the right should be "pushed" more to the right to make room for any more that need to be added. Hence the "Insert" description on this bug. BTW: Whether load in background is on or off, I only EXPECT it to load in the foreground when I select a bookmark. Currently, we are unable to Ctrl-Click on a bookmark item which would produce the background load behaviour you suggest. (Bookmarks are not fully treated as links.) If you both want a "Prepend and replace bookmark groups" behaviour you should open a different bug...
jasonb's right. I did pollute this bug and i personally hate when people do that. I'll open a new bug, cite the relevant comments, and post the number here. By the way, it's seems that Jag and I are on the same page here. I thought I'd forgotten to mention it or something but Jag's comment#19 is exactly what I meant in the next-to-last paragraph "the only subtlety..." in comment#16. I think Hixie's experience is nowhere even close to approaching any sort of typical use case (i believe there are no more than 7 people on the planet who regulary open 120 tabs :-) - but that's what usability testing is for, no need to rest solely on my (nor anyone's) beliefs.
No, my usage pattern isn't even close to common. However, considering proposals in light of extremes (both large and small numbers of open tabs and bookmarks in bookmark groups) often highlights problems, as I think it does in comment 21.
*** Bug 158365 has been marked as a duplicate of this bug. ***
*** Bug 152335 has been marked as a duplicate of this bug. ***
Blocks: bm-group-tracker
*** Bug 151788 has been marked as a duplicate of this bug. ***
I'm a little slow with the copy and paste - i did finally file bug 159266
Blocks: 159431
See new meta bug 159431.
In my simple opinion, the behaviour suggested here seems very correct to me. I personally HATE it if a tab I don't have focused gets affected by the bookmark groups. I don't care if all I have to do is click the back-button. I'd constantly be annoyed. Now I don't know if anyone has thought to check how Opera handles this kind of behaviour. I think I have to remember you folks that the tabs and bookmark groups were kind of stolen from them. Their behaviour is the following: They replace the currently active tab with the first page in the bookmark group. Then they append all remaining pages in the bookmark group. I'm not at all saying Opera's the one to follow here, because the behaviour sketched by Jason is the one I like most. It seems very intuitive. Changing the colour of tabs that belong to a bookmark group is something which I'd be very opposed to. Just doesn't appeal to me. What might be an option( and I do know this sounds awful :-) ) is flashing the newly opened tabs a second or two with a colour. Just my 198 pennies
> I think I have to remember you folks that the tabs and bookmark groups were > kind of stolen from them [Opera, ed.] You might want to read these entries in hyatt's blog: http://www.mozillazine.org/weblogs/hyatt/2002_07_21_mozillian_archive.html#85289235 http://www.mozillazine.org/weblogs/hyatt/2002_09_08_mozillian_archive.html#85443744 The short of it is that he looked at what the MultiZilla people had done (who in turn had gotten their idea from NetCaptor) and wrote his own version of this concept. Opera didn't have tabbed browsing until after this feature appeared in Mozilla nightlies (MDI != tabbed browsing, see the first link). As for the bookmark group idea, it's a pretty obvious one, we didn't need to look at Opera to come up with it (in fact, I didn't even know they also have this feature).
*** Bug 173115 has been marked as a duplicate of this bug. ***
Bug 173115 is not a duplicate of this one. It doesn't want to insert anything anywhere. It simply wants to do away with the left-most "dangling" tab that serves no purpose when opening a bookmark group with only a single tab in place.
*** Bug 179442 has been marked as a duplicate of this bug. ***
*** Bug 159104 has been marked as a duplicate of this bug. ***
Bug 184660 (which I submitted) is *almost* a dupe of this one; I was submitting the case of a multiply-tabbed Home setting on top of a single open tab. After reading the comments here, I feel that's sort of a subcase of this bug, and I'd like to comment (from the user perspective; I've never done any active Moz development) that I stronly agree with Ian Hickson's comment 20 and comment 21 above. I'd further suggest that newly *inserted* tabs resulting from selection of a multiple-tab bookmark should be colored differently -- but only until one of them is focused. This alerts the user to the insertion, preventing the confusion described in comment 5.
I'm not sure if I agree with different tab colouring or not - although I do agree that some kind of visual indication of what was inserted might be appropriate. Having said that, if it's not colour I'm not sure what it should be. A different tab icon? Maybe that would be sufficient and not so totally distracting as I feel a different colour might be. (If it is colour that determines it, it should be a subtle shade difference and not something like bright pink! <grin>) Also, I'm not sure if any further progress on how to handle bookmark groups when there are already a lot of tabs open (inserting / replacing / appending, etc.) can *really* be considered until bug 155325 is resolved. Presumably, a determination of working visual cues of new/old tabs would depend on how tab overflow is handled (and whether a certain methodology works with it or not). (For instance, consider bug 155325 comment 32. Should that be implemented (it's doubtful but possible) then inserting a bookmark group could actually result in the insertion of a tab row, keeping the "new" group discrete from the rest...) Alternatively, we can just try to come up with the behaviour in the current scheme and leave visual cues and/or interaction with tab overflow to later, additional bugs.
> [..] some kind of visual indication of what was inserted might be > appropriate. Having said that, if it's not colour I'm not sure what it should > be. A different tab icon? Maybe that would be sufficient and not so totally > distracting as I feel a different colour might be. (If it is colour that > determines it, it should be a subtle shade difference and not something like > bright pink! I was kinda thinkin' of international orange blinking to deep violet, say at about 10 cycles/second. (Kidding!) Actually, I sort of envisioned a convex shading, but that might be too much work. A different tab icon is a good idea too, maybe a dotted outline or a temporary pair of icons showing the insertion endpoints, i.e: (starting condition) +-----------------------------------------------------------------------------+ |___________ ____________ +---------------+ ______________ ______________ | ||tab 1 | |tab 2 ||tab 3 (active) ||tab 4 | |tab 5 || |---------------------------+ +---------------------------------| | | (inserting group of 3 [possibly animated] tabs growing in the middle?): +-----------------------------------------------------------------------------+ |________ _________ +------------+ ___________ ____________ ______________ | ||tab 1 ||tab 2 ||tab 3 (act) ||<-#|###|#->||tab 7 (old4)||tab 8 (old5) || |--------------------+ +-------------------------------------------| | | (finished inserting 3 tabs, waiting for user to focus one of them): +-----------------------------------------------------------------------------+ |________ _______ +------------+ ________ _______ ________ ______ ______ | ||tab 1 ||tab 2 ||tab 3 (act) ||<-#tab 4||#tab 5#||tab 6#->||tab 7 ||tab 8 || |------------------+ +---------------------------------------------| | | (end state -- user has focused one of the new tabs): +-----------------------------------------------------------------------------+ |________ _______ _______ _______ +------------+ _______ _______ _______ | ||tab 1 ||tab 2 ||tab 3 ||tab 4 ||tab 5 (act) ||tab 6 ||tab 7 ||tab 8 || |------------------------------------+ +---------------------------| | | Ghu, ascii-art, sorry. Obviously, inserting N tabs into an already-"full" tab row should cause the endmost N tab(s) to flow to whatever solution is implemented for bug 155325.
Depends on: 155235
Depends on: taboverflow
No longer depends on: 155235
Depends on: 208278
->jag
Assignee: caillon → jaggernaut
OPTIONS. Please, simply (although it may be hideously difficult to implement) ALLOW THE USER TO CHOOSE. One can include multiple types of tabbed behaviour options in the preferences dialogue. It would also be useful if this behaviour could be assigned to individual accounts, as with other preferences. I personally MUCH prefer new tab groups to be appended to the right of all my existing tabs, as it was in Mozilla 1.4. As it happens, I'm sumitting this in shock after having a tab group unexpectedly wiped out before my eyes. The "Back" button behaviour was something I'd never considered or investigated, but upon reflection appears too kludgy to be of much use. The only thing I'd change is when creating a single new tab. That feels intuitively like it should appear directly to the right of the focused tab, wherever that may be in the row of oopen tabs, but again, please give people the ability to choose tab behaviour, even if it means editing about:config or something arcane like that. In the spirit of intuitiveness, the contextual menu that pops up in an empty tab area should (dynamically) have "New Tab" as the first item in the list. I realise this means that it might also have to apply to contextual menus popped up over existing tabs (for consistency), but if data destruction is so abhorrent, why are the first two items in the list "Close Tab" and "Close Other Tabs"? Are there any other bug reporting rules I can break? Options is what we need. That's all I'm saying.
This bug is NOT about restoring 1.4's append behaviour. It's not about appending at all. Rather, it's about *inserting* any tabs in tab groups loaded between the current tab and any tabs that might exist to the right. For discussion of restoring 1.4's behaviour via a pref, please see bug 203960.
Another vote against this bug... (In reply to comment #0) > Expected Results: Focused tab should be replaced by the 1st tab in group, Why should it? The focused is likely to be the one the user is reading. Replacing/covering the currently read content with a different one would mimic the annoyance of a popup window. BTW, for some reason recent 1.8x trunk builds switch to the first tab in the group. I find that highly annoying, for the very same reason. Is this reported in bugzilla? > remaining tabs in group should be *inserted* to the right of the focused tab. A UI that keeps moving things around defeats user orientation and muscle-memory. See Microsoft's obnoxious "personalized menus". Prog.
*Vote against this bug. Inserting rather than appending seems brain damaged and counter-intuitive. When adding paperwork to an in-tray, do you lift all the sheets up and place the new ones underneath? No. When writing in a diary, do you insert new pages at the front and add to those? No. That's what you are asking for with "inserting". This seems very Microsoftian, that is the way Outlook [Express] works with email. To have tabs open in anything other than chronological order of creation would be brain-dead. At worst, a pref could be added to accomodate the illogical behaviour.
Product: Browser → Seamonkey
Beryan's arguments against make no sense. The tab bar is not in the least bit analogous to a stack of papers: in a stack, only the topmost is accessible and reaching any other page requires searching back; in the tab bar, all tabs are equally accessible, which is much closer to how a filing cabinet works (and tabs are even meant to simulate the label tabs sticking up out of files in a drawer, as seen end-on) and files are inserted in drawers all of the time. Besides, if this feature is enabled, he can just open a new tab (which would still be appended to the right end) and open the group there to get the same behavior he's used to. This would make bookmark groups more flexible, not merely different.
Assignee: jag → nobody
QA Contact: claudius → bookmarks
1. On trunk we don't have bookmark groups any more. 2. Left clicking the "Open all in tabs" folder option will only override the current tab. Additional bookmarks will be appended in new tabs. 3. Middle or Control clicking the "Open all in tabs": 3.1. If browser.tabs.opentabfor.middleclick is true, then Ctrl (or Meta) and middle-click: 3.1.1 Opens new tabs, depending on the Shift key and onbrowser.tabs.loadInBackground. 3.1.2 Otherwise if middlemouse.openNewWindow is true, then Ctrl (or Meta) and middle-click opens the folder in tabs in a new window. 3.1.3 Otherwise: See point2. Closing as INVALID (no bookmark groups) and WORKSFORME (Middle-click options).
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.