Open Bug 697359 (PlacesInTabLibrary) Opened 13 years ago Updated 1 year ago

Move the Library window (Bookmarks, History, Downloads) to a tab (in-content UI)

Categories

(Firefox :: Bookmarks & History, defect, P3)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect
Points:
8

Tracking

()

People

(Reporter: fryn, Unassigned)

References

(Depends on 1 open bug, Blocks 6 open bugs)

Details

Attachments

(3 files)

WIP patch
7.43 KB, patch
Details | Diff | Splinter Review
Screenshot of WIP patch
110.43 KB, image/png
Details
mockup
774.15 KB, image/png
Details 
Let's move the Library window (Bookmarks, History, Downloads) to a tab (in-content UI).

Yes, there are existing bugs that dance around this issue, but since the purpose of bugs is to aid development, I'd like to unify them here, since I'm going to start working on it.
Attached patch WIP patch — — Splinter Review 
Here's a work-in-progress patch I put together that works surprisingly well for its simplicity.
Known issues include wonky back-and-forward behavior.

It will appear in Wednesday's UX build.
https://hg.mozilla.org/projects/ux/rev/d60996ec2bc2
why not reusing one of the other 10 bugs we had to do this :)
ah, I see, this is a simplified approach.
Detaching a tab containing library is broken (in the latest hourly) possibly because of Home Tab.
Attached image Screenshot of WIP patch — 
Looking pretty good already. ;)

(No need for any more screenshots unless requested. Thanks.)
Does the patch allow for automation of a user's preferences? i.e. if a user wants the library to open in a window rather than a tab, that should be the behaviour. I remember that someone from the UX Team stated that was something they'd aim to achieve.
Err, isn't ICUI suppose to have... well, ICUI design?
(In reply to Peter Henkel [:Terepin] from comment #10)
> Err, isn't ICUI suppose to have... well, ICUI design?

I'm assuming the plan is to land something now and sort out the polish later.
(In reply to Paul [sabret00the] from comment #9)
> Does the patch allow for automation of a user's preferences? i.e. if a user
> wants the library to open in a window rather than a tab, that should be the
> behaviour.

No.

> I remember that someone from the UX Team stated that was
> something they'd aim to achieve.

You misunderstood.
(In reply to Peter Henkel [:Terepin] from comment #10)
> Err, isn't ICUI suppose to have... well, ICUI design?

This is unhelpful.

(In reply to Paul [sabret00the] from comment #11)
> I'm assuming the plan is to land something now and sort out the polish later.

That's not the plan. It should work and look at least as good as the window does now when it lands. The long-term plan is to replace the Library in-content UI with something simpler, more efficient, and less of a trigger for micromanagement or OCD tendencies.
But current window doesn't fit new theme. At all.
How to enable it in UX build?
(In reply to Frank Yan (:fryn) from comment #12)
> > I remember that someone from the UX Team stated that was
> > something they'd aim to achieve.
> 
> You misunderstood.

Found this: https://bugzilla.mozilla.org/show_bug.cgi?id=584031#c16
"Any tab can be dragged to a separate window, and just like we have suggested for Downloads, the bookmarks windows, etc — we should remember if you did this, and keep it as a separate window the next time you open it. But I agree, it should open in a tab by default."

Can you tell me what I appear to have misunderstood?
Leaving note to self to fix gradient colors on Lion:
active: 224 (0xe0) -> 201 (0xc9)
inactive: 243 (0xf3) -> 234 (0xea)
With the new download manager in the UX builds having the history button linking to the library, I see the library a lot more than I used to. 

Can I test any of the recent patches?
you could look at how the addons panel works and use their method for the back/forward buttons. I think it works well.
What's the status of this bug ? Thank you.
Sorry for the bump , but i guess landing this with Bug 744936 would be better as it would give even more unified look. 
Thank you.
Assignee: fryn → nobody
Status: ASSIGNED → NEW
Frank, what's missing in your patch? Do you have another updated WIP patch? Maybe I can take this.
Blocks: 752434
Blocks: 801232
Andres, can someone on your team take this?  We need this in order to ship per-window private browsing.  Thanks!
Whiteboard: [appcoast]
Depends on: 815352
Actually, I filed bug 815352 for the bits that we need for per-window private browsing.
Whiteboard: [appcoast]
No longer blocks: 801232
yeah, indeed we don't need the whole Library...
The only problematic thing regarding the Library is still the transactions support for undo/redo. I think I'll file it apart now, since once that has a solution this bug could be much easier.
Luckily the downloads view doesn't need transactions (they are supported only for bookmarks)
Depends on: 815598
Depends on: 829067
Looks like we just need a design here and we could do this without many troubles
yes, though that's not really looking like the other in-content UIs, so I'm not sure if it's still a viable plan.
AFAIK the plan is to redesign all the in-content views. Stephen Horlander may have new mockups/infos.
Depends on: 750544
I support this bug request:

1. One tool = one window. Nobody wants to see few windows open per tool. 

2. See bug that is very relevant:
https://bugzilla.mozilla.org/show_bug.cgi?id=861514 (Download progress indication causes confusion between the two windows). 

Please hurry to eliminate the Library window and put it in a tab.
No longer blocks: 752434
Depends on: 752434
(In reply to Frank Yan (:fryn) from comment #12)

> > Does the patch allow for automation of a user's preferences? i.e. if a user
> > wants the library to open in a window rather than a tab, that should be the
> > behaviour.
> 
> No.

The application-level History or Bookmarks feature messing with the tabs in my front window. That would be one regression. A particularly annoying one, 'cause Firefox fails to always put you back at the tab you were at after you close the new tab. How many more regressions would there be ? The history auto-updating - and without lagging - ? The native handling of the bookmarks and history entries ? Dragging them to the Desktop ? To some browser window ? Selecting three of them - with native keys for that - and right-clicking them to open them in new tabs ?... I know what we would lose. What would we win ? I have no idea.

The History in Firefox Mac is quite nice, whereas the "History" in Google Chrome is unusable. Too bad you want to break what is good.

Nicolas
(In reply to Nicolas Barbulesco from comment #32)
> (In reply to Frank Yan (:fryn) from comment #12)
> 
> > > Does the patch allow for automation of a user's preferences? i.e. if a user
> > > wants the library to open in a window rather than a tab, that should be the
> > > behaviour.
> > 
> > No.
> 
> The application-level History or Bookmarks feature messing with the tabs in
> my front window. That would be one regression. 

Couldn't you just move the Library tab to a new window to get something similar to the old behaviour? Right-click on a tab > Move to New Window.
In content Library, cannot open bookmarks to new tab in sequence. It is necessary to switch back to the Library tab whenever I open bookmarks.
It is too difficult to select library tab if tabstrip overflowed.

So, In-content Library is no good idea.
Separate window is best.
CTRL+SHIFT should allow you to open in a new tab in background, and may become default behavior (TBD). Regardless, also with the window you have to switch back to the window, so I suppose the issue is that the windows is easier to find than a tab, especially if the tabbar is scrolled.
If we would transform our tools windows (Library, Add-ons, Preferences) into pinned tabs, it would help finding them and likely solve big part of the issue.
FWIW, you can also select multiple links, right click and "open all in tabs".
(In reply to Marco Bonardo [:mak] from comment #35)
> CTRL+SHIFT should allow you to open in a new tab in background, and may
> become default behavior (TBD).

No, I open the bookmark in front tab and check the content each time briefly.

> Regardless, also with the window you have to
> switch back to the window, so I suppose the issue is that the windows is
> easier to find than a tab, especially if the tabbar is scrolled.

I have wide monitor, so main-window and library window are always visible.
No need switch them. just double click the bookmark to open.

> If we would transform our tools windows (Library, Add-ons, Preferences) into
> pinned tabs, it would help finding them and likely solve big part of the
> issue.

It is necessary a extra step to switch to pinned tab. Useless.

> FWIW, you can also select multiple links, right click and "open all in tabs".

I know this.
(In reply to Matthew N. [:MattN] from comment #33)

> > The application-level History or Bookmarks feature messing with the tabs in
> > my front window. That would be one regression. 
> 
> Couldn't you just move the Library tab to a new window to get something
> similar to the old behaviour? Right-click on a tab > Move to New Window.

I would have to do extra operations, quite heavy operations for such a simple goal. And this would still not give me the same result as now.

Current behaviour :

 1) Menu History → Show all history. I get my History window. Whatever windows and tabs I have are left undisturbed. Simple.

In-content tab behaviour :

 1) Menu History → Show all history. I get a new tab in the front window. I make sure it's a "new" tab, by looking at the Back button. Because sometimes - including in Firefox, see request bug 806199 -, stuff coming from nowhere steals the front tab. Even if I see a greyed Back button, I am not sure that Firefox really opened a *new* tab. Will Firefox at least be consistent and always open a new tab for the History ? [With my current "add-ons manager", the answer is no.] Even if the front tab is a blank tab ? [With my current "add-ons manager", the answer is no, Firefox steals the tab.] And what if the front tab is blank but has user-entered text in the address bar ? Will Firefox steal that tab, making me lose my text forever ? [With my current "add-ons manager", the answer is yes, Firefox steals the tab and loses the user's text.] [Stealing a blank tab is bad. Stealing a blank tab with user text in the address bar is even worse.] Now there is a History tab in my front window, mixed with unrelated tabs. Where is this new tab ? At the end, I guess.
 2) I right-click the new tab, I make it a separate window. Fine for the History. But now what tab is active in the window that was parasited ? The tab that was active before ? Let's suppose so. Otherwise I would do a few more operations to fix the situation (going back to the victim window, activating the right tab back, going back to the History window).

The in-content tab behaviour would not be what I call pleasant, let alone simple.

If some day you really do this change, please at least leave an option to have the current behaviour, for the people like Alice and me. Thank you.

Nicolas
Blocks: 847949
Whiteboard: [triage]
Whiteboard: p=0
Attached image mockup — 
one mockup from shorlander
Alias: PlacesInTabLibrary
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
Depends on: 996873
Whiteboard: p=0 → p=8
No longer blocks: 752197
Points: --- → 8
Flags: qe-verify?
Whiteboard: p=8
As a curious outsider, what is the status of these efforts?
(In reply to Aaron Train [:aaronmt] from comment #42)
> As a curious outsider, what is the status of these efforts?

There is nobody working on this at the moment and I haven't heard of any plans to work on this in the near future.
Priority: -- → P3
What's the status of this bug? Fixing this bug would also clear bug 260611.
See Also: → 1310295
(In reply to Greg from comment #45)
> What's the status of this bug? Fixing this bug would also clear bug 260611.

The status can be seen above: The bug is "NEW" (means: not fixed) and "Unassigned" (means: nobody is working on this). Under "Depends on" above you can also see which underlying issues need fixing first. Patches and help welcome.
Blocks: 1344993
See Also: → 1364703
The add-on More In Content UI + (https://addons.mozilla.org/en-US/firefox/addon/more-in-content-ui-plus/) could be used to achieve this but it's 4 years old so it will likely not be rewritten as a WebExtension.
This could be fixed by simply making a prettier URL for chrome://browser/content/places/places.xul such as about:library. Then just make any attempts to open library create a tab for that, remove duplicate back-forward buttons and done - no immediate full redesign necessary.

Only question would then be how to differentiate between bookmarks, history and downloads.
See Also: → 1444483
Depends on: 1554144
Blocks: 1615850
Depends on: 1623332
Blocks: 1638584
See Also: → https://ideas.mozilla.org/post/721410
Blocks: 1720960

Updated See also --> https://connect.mozilla.org/t5/ideas/make-the-library-tab-based/idi-p/1162
(Posting as a comment since I don't have permissions to fix it)

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 17 duplicates, 53 votes and 93 CCs.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(mak)

Changing qe-verify? to qe-verify+.

Flags: qe-verify? → qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: