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

Status: NEW

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

Description

[Frank Yan (:fryn)]

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.

Comment 4

[Frank Yan (:fryn)]

Attachment: WIP patch

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

Comment 5

[Marco Bonardo [:mak]]

why not reusing one of the other 10 bugs we had to do this :)

Comment 6

[Marco Bonardo [:mak]]

ah, I see, this is a simplified approach.

Comment 7

[Siddhartha Dugar [:sdrocking]]

Detaching a tab containing library is broken (in the latest hourly) possibly because of Home Tab.

Comment 8

[Frank Yan (:fryn)]

Attachment: Screenshot of WIP patch

Looking pretty good already. ;)

(No need for any more screenshots unless requested. Thanks.)

Comment 9

[Paul [pwd]]

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.

Comment 10

[Peter Henkel [:Terepin]]

Err, isn't ICUI suppose to have... well, ICUI design?

Comment 11

[Paul [pwd]]

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

Comment 12

[Frank Yan (:fryn)]

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

Comment 13

[Frank Yan (:fryn)]

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

Comment 14

[Peter Henkel [:Terepin]]

But current window doesn't fit new theme. At all.

Comment 15

[bogas04]

How to enable it in UX build?

Comment 16

[Paul [pwd]]

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

Comment 17

[Frank Yan (:fryn)]

Leaving note to self to fix gradient colors on Lion:
active: 224 (0xe0) -> 201 (0xc9)
inactive: 243 (0xf3) -> 234 (0xea)

Comment 18

[Notlost]

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?

Comment 19

[Notlost]

you could look at how the addons panel works and use their method for the back/forward buttons. I think it works well.

Comment 21

[bogas04]

What's the status of this bug ? Thank you.

Comment 22

[bogas04]

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.

Comment 23

[Marco Castelluccio [:marco]]

Frank, what's missing in your patch? Do you have another updated WIP patch? Maybe I can take this.

Comment 24

[(no longer active)]

Andres, can someone on your team take this?  We need this in order to ship per-window private browsing.  Thanks!

Comment 25

[(no longer active)]

Actually, I filed bug 815352 for the bits that we need for per-window private browsing.

Comment 26

[Marco Bonardo [:mak]]

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)

Comment 27

[Marco Bonardo [:mak]]

Looks like we just need a design here and we could do this without many troubles

Comment 28

[u428464]

FWIW This is the latest mockup I could find : http://people.mozilla.com/~shorlander/files/australis-design-specs/images/Australis-i01-DesignSpec-MainWindow-%28LibraryTab%29.jpg

Comment 29

[Marco Bonardo [:mak]]

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.

Comment 30

[u428464]

AFAIK the plan is to redesign all the in-content views. Stephen Horlander may have new mockups/infos.

Comment 31

[t8av]

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.

Comment 32

[Nicolas Barbulesco]

(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

Comment 33

[Matthew N. [:MattN]]

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

Comment 34

[Alice0775 White]

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.

Comment 35

[Marco Bonardo [:mak]]

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

Comment 36

[Alice0775 White]

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

Comment 37

[Nicolas Barbulesco]

(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

Comment 40

[Zhenshuo Fang (:fang) - Firefox UX Team]

Attachment: mockup

one mockup from shorlander

Comment 42

[Aaron Train [:aaronmt]]

As a curious outsider, what is the status of these efforts?

Comment 43

[Jared Wein [:jaws] (please needinfo? me)]

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

Comment 45

[Greg]

What's the status of this bug? Fixing this bug would also clear bug 260611.

Comment 46

[Andre Klapper]

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

Comment 49

[David Hedlund]

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.

Comment 50

[Madis]

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.

Comment 54

[lolrepeatlol]

Doing this would help fix many issues on macOS.

The CSS (I believe it's CSS, anyway) on macOS for the current library window only supports the light theme which I believe is partly why light mode for Firefox is still forced through an info.plist setting. Putting the library window in a tab would help solve this issue, because instead of having the macOS developers make dark mode on the library window work, cross-platform dark mode would already be implemented into the library tab. Coupling a fix for this issue and recreating the "Page Info" window into a tab would mean that the macOS developers would not need to create CSS for dark mode at all. While fixing this bug on its own would not solve these issues, it seems like it would greatly help solve SO many dark mode related issues like this, this, this, and countless more, which are all caused by the fact that Firefox on macOS has forced light mode through the info.plist setting I mentioned earlier.

Additionally, recently it has been discovered that in Big Sur, the library window was broken. While I fully understand why the developers chose to fix the issue in this way as there is a limited amount of time, unfortunately the library window now has the style of macOS 10.10-10.15 even while in Big Sur and looks somewhat dated in comparison to the rest of Big Sur's new design. While actually using the OS, it sticks out and looks odd. And this kind of work has to be done every time there's a new look for macOS, needlessly wasting resources that could be better used for something else. If the library was remade into a tab, this would not have to be worried about ever again.

Of course, there are fairly obvious UX issues to the library window as well. Why are Add-ons, preferences, and logins a tab, but not the library?

In all honesty, the printing preview in Firefox is absolutely fantastic. It's a monumental improvement to an issue that's been unfortunately overlooked for years. Now, it's high time that the library window gets the same treatment.

Comment 58

[gliu20]

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)

Comment 60

[TOURCODER]

Is this a bug that hasn't been fixed in over a decade?

Comment 61

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 62

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.

Comment 63

[Alberto Fabbri]

Is this still considered? It would be a very nice addition since it would lower the clutter in the taskbar.

Comment 64

[David Lawrence [:dkl]]

Changing qe-verify? to qe-verify+.