Closed Bug 587873 Opened 14 years ago Closed 11 years ago

Pinned tabs should be the same in each window

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: zpao, Unassigned)

References

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

Details

Attachments

(2 files, 1 obsolete file)

Patch v0.2 (WIP)
31.19 KB, patch
Details | Diff | Splinter Review
Patch v0.2.1 (WIP)
26.93 KB, patch
Details | Diff | Splinter Review 
Each app tab should exist in each window. The docshell & whatever else goes along with that should only exist once, so will have to be transferred between windows. We'll make that happen only when an app tab gets focused.

This will also mean changes to sessionstore - instead of storing app tabs intermingled with the other tabs in each window, we'll have to have a new top-level object in the session data.
From what I've heard today, we want to block on this...
blocking2.0: --- → ?
Attached patch Patch v0.1 (WIP) (obsolete) — — Splinter Review 
A quick way to make this start to work. Not sure if it's how we actually want to do this, but it reminded me a lot of how my network prioritizer worked, so I used that as a launching point.

Dao, I know there isn't much here yet, but what are your thoughts on this approach so far? Better to know now rather than later.
Assignee: nobody → paul
Attachment #467976 - Flags: feedback?(dao)
FWIW, this is working to the extent that newly pinned tabs will be available across existing windows. Nothing else though. And it will leak like a sieve.
Attachment #467976 - Attachment is patch: true
Attachment #467976 - Attachment mime type: application/octet-stream → text/plain
Blocks: 589246
I missed any discussion about this. Will there be an option to disable that behavior? I like the idea of tabs existing only once in the browser, regardless of how many windows I have open.
Sorry. I had a brain freeze. Please ignore my last comment.
Comment on attachment 467976 [details] [diff] [review]
Patch v0.1 (WIP)

So you're swapping docshells upon tab select? This is probably going to be a problem for bug 577096...

Instead of adding the TabPin/TabUnpin events, I wonder if tabbrowser should just call the module.

The aSecondary parameter is kind of ugly, would be nice if this could be avoided. The module knows when it calls pinTab, letting onTabPin bail out in this case should be trivial.

The domwindowclosed observer isn't going to be necessary since you're listening for the unload event, as far as I can tell.

>+let _appTabs = {};
>+// appTabs will look like...
>+// [
>+//   {
>+//     tabs: []
>+//   }
>+// ]

Is there going to be more data apart from the tab nodes? If not, this structure is unnecessarily long-winded.
Attachment #467976 - Flags: feedback?(dao)
Attached patch Patch v0.2 (WIP) — — Splinter Review 
Updating with my current WIP so it doesn't get lost.
Much more comprehensive & starts in on the session restore related changes.
Attachment #467976 - Attachment is obsolete: true
Not blocking, as per updated spec at https://wiki.mozilla.org/Firefox/Projects/App_Tabs#Design_Specification - moving to future.
blocking2.0: ? → -
Target Milestone: --- → Future
Since this would be intended in the future, that means App Tab will be window and Tab Group specific for Firefox 4. I believe if this feature of global App Tabs will to be implemented, it should become an option instead. 

If you suddenly upon Firefox 5(If the next Firefox release is Firefox 5), make all App Tabs to be global, users may welcome or unwelcome this. 

Instead of forcing changes on them, I think an option will make everyone happy.
(In reply to comment #9)
> Not blocking, as per updated spec at
> https://wiki.mozilla.org/Firefox/Projects/App_Tabs#Design_Specification -
> moving to future.

Should the title of the bug be changed to match the updated spec? "Allow App Tabs to be "global", appearing in all windows"
This bug is nearly the same as this bug Bug 587400
No longer blocks: 589246
Either implement this (or fix Bug 587400) or disable App Tabs completely. At the moment pinning an App Tab are 2 wasted clicks, nothing more.
Looking at the App Tabs page on the wiki (https://wiki.mozilla.org/Firefox/Projects/App_Tabs), I note that the first paragraph outlines the major design goal: "App tabs can not be accidentally closed".

Obviously this is referring to the fact that they don't have a visible "X" button, making it hard to accidentally close the tab by indiscriminately clicking. But I would argue that if opening a new window, closing the current window, and then closing the new window causes the app tabs to be closed, that would usually be quite accidental, and therefore, app tabs are currently not meeting this design criteria.
You forgot the part about this bug being future work.   We know its not implemented yet, so please no more mentions about incomplete app tabs (we know by design and hense this bug) unless your going to fix it.
until this will be implemented, for all people interested, maybe also as a reference for implementation, this addon makes app tabs permanent and shared across all windows.

https://addons.mozilla.org/en-US/firefox/addon/tab-utilities/
I agree this should be fixed.
Blocks: 588058
Lately I've seen a few grumbles about lost App Tabs and people assuming the feature is implemented in a buggy manner, I think this bug could solve that.
Instead of having identical app tabs on all windows, app tabs can be moved to the other open window.
(In reply to comment #22)
> Instead of having identical app tabs on all windows, app tabs can be moved to
> the other open window.

That wouldn't fix the problem, just move it. As it is now, if I open a new window and then close the old one first, I'll lose my app tabs. With that suggestion, if I open a new window and then subsequently close it, I'll lose my app tabs.

That sounds worse to me: often I open a new window just temporarily or by accident, then close it soon after. At least the way things are now, as long as I leave my "main window" open until last, it will keep the app tabs.
This ***really*** needs to be configurable, preferably by tab.

For example, I use two Firefox windows - one for each monitor.
I have a few app tabs: some browsergames and the work webmail client. On one window I have the game apptabs and on the other the webmail apptab.

Now it would be a huge waste of space and additionally an annoyance to have all apptabs in all windows - I **know** which tabs are in which windows so depending on which one I want to access I use the corresponding window.
Mostly unbitrotted patch. I need to figure out the session restore bits again, but I think actually working first is more important - there are still docshell related issues.

Dao, I know there were things here which I haven't addressed yet since last time you looked at this, but do you still think the general approach of using a module to track & swapping docshells is ok?
Attachment #542940 - Flags: feedback?(dao)
Boris, can you apply this patch and help me figure out the docshell issue? I gave it the old college try but I think it would benefit from somebody more familiar.

The problem:
  * swapping tabs more than twice fails hard (you can't miss it)
  * there are 2 warnings (I suspect are early indicators for future fails) on the first swap, which does succeed
> WARNING: NS_ENSURE_TRUE(!mParent || mParent == docLoaderService) failed: file /Users/pao/Mozilla/mozilla-central-dev/docshell/base/nsDocShell.cpp, line 2565

STR:
  * have 2 windows (A, B)
  * pin a tab in A
  * select the newly created corresponding app tab in window B - you should see the content swap
  * focus window A - which should swap again
  * focus B again, go back to A, etc. Things are out of whack
So the basic problem is that once things start failing they're failing because swapTabs() calls updateCurrentBrowser() which does this:

904               this._fastFind.setDocShell(this.mCurrentBrowser.docShell);

That lands us in nsDocShell::EnsureFind via this call in nsTypeAheadFind:

196       mWebBrowserFind = do_GetInterface(aDocShell);

EnsureFind does this:

10963  // default to our window
10964  nsCOMPtr<nsIDOMWindow> windowToSearch(do_QueryInterface(mScriptGlobal));
....
10969  // if the active window is the same window that this docshell is in,
10970  // use the currently focused frame
...
10977       fm->GetFocusedWindow(getter_AddRefs(windowToSearch));

and windowToSearch ends up null.  Then we call SetRootSearchFrame on the mFind, which returns error if passed null, and we lose.

So on the docshell end we may be able to fix this by setting windowToSearch to mScriptGlobal again if it ends up null.  But how is it that the active window is the root window of our docshell but there is no focused window at all?  Is that expected?
Oh, and the warnings comment 26 mentions are really not an issue.  They really aren't.  Just trust me on that.
> So on the docshell end we may be able to fix this by setting windowToSearch
> to mScriptGlobal again if it ends up null.  But how is it that the active
> window is the root window of our docshell but there is no focused window at
> all?  Is that expected?

It would be the case while the 'activate' event is firing, as the code in this patch appears to be doing, as that event fires when the window is raised but before focus is assigned to it. You'd want to wait for the focus event to occur afterwards.
OK.  I think it still makes sense to fall back to mScriptGlobal if we're not focused.
experiencing an issue with app tabs, that i *think* is related to this bug, just wanted to confirm before filing separately:

1. no Fx windows open, open a new window
2. pin a site as an app tab.
3. close that window, and re-open... app tab still there (session restore probably?)
4. now, open a second window, app tab from first window is *not* present
5. pin another site as an app tab in this second window.
6. close second window, then first window, and re-open
7. only the first window's app tab is restored

Bottom line, it seems like the app-tab state is not shared to new windows (this bug I guess) *and* that only the last window's app-tab state is preserved, not the combination of all app-tab states as one might expect (also this bug I think).

Am I correct in my assumption that these issues are related to this bug?
(In reply to comment #31)
> experiencing an issue with app tabs, that i *think* is related to this bug,
> just wanted to confirm before filing separately:
> 
> 1. no Fx windows open, open a new window
> 2. pin a site as an app tab.
> 3. close that window, and re-open... app tab still there (session restore
> probably?)
> 4. now, open a second window, app tab from first window is *not* present
> 5. pin another site as an app tab in this second window.
> 6. close second window, then first window, and re-open
> 7. only the first window's app tab is restored
> 
> Bottom line, it seems like the app-tab state is not shared to new windows
> (this bug I guess) *and* that only the last window's app-tab state is
> preserved, not the combination of all app-tab states as one might expect
> (also this bug I think).
> 
> Am I correct in my assumption that these issues are related to this bug?

Most app tab dataloss issues are related to this in that this will make them (as they are) invalid. There are bunch flying around, some have been hacked around (bug 625016), some are ideas I'm not wild about (bug 671486). Your STR are most closely represented by bug 587400 though, but you don't want another fix, you want this bug fixed.

Short answer: This bug seems to cover you & you don't need to file a new bug.
Hi guys.
Can you please update the wiki page with the status of this feature.
What's the release target?
I'm asking this because i am the QA lead of this feature.
Thanks.
Blocks: 587400
There are a lot of bugs in the ap tab and group tab fonctions. 

I want to have all ap tabs on all groups and a possibility to add ap tabs only to some groups. 

I want also that the ap tabs are on a pull down list 8only one main ap tab on the hight of the tabs ... a mouseover on it opens the list of ap tabs. 

it is also not very simple to identify a group. I would like to have the name of the group as group background. 


Thanks 
brainstuff
Hi, your comments (I think) should be filed as a separate bugs.
I'm not working on this right now and we may not need it going forward.
Assignee: paul → nobody
Attachment #542940 - Flags: feedback?(dao)
(In reply to Paul O'Shannessy [:zpao] from comment #37)
> we may not need it going forward.

Do you mind elaborating?
(In reply to Paul [sabret00the] from comment #38)
> (In reply to Paul O'Shannessy [:zpao] from comment #37)
> > we may not need it going forward.
> 
> Do you mind elaborating?

One of the driving forces was focused around a home tab, which we're thinking of doing a bit differently. The problem here was also "hard" - the proper solution (not my WIPs) involved making some deeper changes to the platform (bug 706274). I think we'll try something a bit different for preventing dataloss you were thinking this could solve.
Depends on: 706274
Thanks for the answer. Just to clarify, does this mean the goal of global App Tabs isn't currently a goal for Firefox?
I can see the problem you are trying to solve here but i think this is *NOT* the right way to solve it.

Having app tabs per window is one of the coolest features.

I usually have ~5 firefox windows open for different tasks, each with 8-15 app tabs. these sets of app tabs are *disitinct* and the windows have been persistent (e.g. never closed) for years. To have the most used tabs (reference, apps, …) always at hand without later having to dig for the last opened "normal" tab again is a real timesaver...

obviously this is me having a constant tab count >300 at work... but then ffx is the only browser supporting so many tabs at very little ram usage...

why not just display confirmation dialog like the one for closing a window with multiple "normal" tabs open? IMHO: thats probably easy to implement and should have been implemented since day one. you know: make people happy and not confused :-)
Yes app tabs is a good fonction..But they must be app tabs for all windows, app tabs for specific windows .

Tas are not a very good idea in the actual form. I want to have a drop down list on each tab... the first page opened is at the Top then I want to have the pages who was opened from this first page as a drop down list. in this way we have not hundereds of tabs and all related pages are in the same tab.

I want alsi a button >>LAST TAB  and << FIRST TAB
(In reply to brainstuff John Scheb from comment #42)
> Yes app tabs is a good fonction..But they must be app tabs for all windows,
> app tabs for specific windows .
This is relevant and an interesting suggestion.

> Tas are not a very good idea in the actual form. I want to have a drop down
> list on each tab... the first page opened is at the Top then I want to have
> the pages who was opened from this first page as a drop down list. in this
> way we have not hundereds of tabs and all related pages are in the same tab.
For the drop down list on tabs, file a separate bug.

> I want alsi a button >>LAST TAB  and << FIRST TAB
File a separate bug. Don't just comment on random bugs or you will be ignored.
Having the same app tabs in all windows would defeat the purpose of opening a new window. And like Claude Nobs said you might want to have different app tabs in different windows (how do you maintain this when shutting down?!).

Perhaps to solve the problem in bug #587400 while maintaining the ability to have different apptabs in different windows, a field could be added to persistent apptab bookmarks stating a window number. So if you create app tabs in a second window, firefox will know to open both windows next time you launch the program, each with its respective tabs.
(In reply to David from comment #45)
> Having the same app tabs in all windows would defeat the purpose of opening
> a new window. And like Claude Nobs said you might want to have different app
> tabs in different windows (how do you maintain this when shutting down?!).
> 
> Perhaps to solve the problem in bug #587400 while maintaining the ability to
> have different apptabs in different windows, a field could be added to
> persistent apptab bookmarks stating a window number. So if you create app
> tabs in a second window, firefox will know to open both windows next time
> you launch the program, each with its respective tabs.

The use case built by the UX Team runs contradictory to what you're saying. App Tabs are supposed to be like applications and thus only meant to be removable upon explicit instruction from the user. Things like closing windows and accidentally losing your App Tabs or being forced to keep a window open to ensure you don't lose your App Tabs are a problem due to the implementation. If you'd want a different set of App Tabs for different windows, I'm sure it'll be easier to implement in an extension, but for the general user, should they pin a tab/application. That application/tab should follow them across all windows.
But if two windows are open at the same time it makes absolutely not sense to have both windows contain the *same* tab. It just wastes space and I can't believe anyone would want e.g. his Facebook or Stack Overflow Chat tab on both monitors/windows.
A user is writing some emails and then has to do some research to complete said email. They've found themselves surfing and what-not and before they know it, they have five different windows open. Should a user have to figure out what window contains the email application tab or should it just be there? It should just be there. There's a difference between favoured tabs and actual application tabs. Of course, a user doesn't need five Stack Overflow tabs, but then Stack Overflow isn't the use case of App Tabs. Facebook however, is. If a user is doing whatever, the design of the App Tabs in Firefox means that no matter what a user is doing, they'll be notified and able to check the tab without losing their work flow.
(In reply to Paul [sabret00the] from comment #48)

>Should a user have to figure out what window contains the email application 
>tab or should it just be there?

It would be obvious which window has the tabs: the first one.

Anyway what you say does make sense; if it's an application you want to always have access and notifications. I just can't imagine a way this could be implemented without wasting system resources.

I think what needs to be solved first is these app tabs dissapearing altogether when you close new windows last. (i.e. bug #587400)
(In reply to David from comment #49)
> (In reply to Paul [sabret00the] from comment #48)
> 
> >Should a user have to figure out what window contains the email application 
> >tab or should it just be there?
> 
> It would be obvious which window has the tabs: the first one.

You'd think that, but my personal use-case sees app tabs in the second, third or fourth window should the browser require a restart. At which point the above scenario requires the user to remember the window number in order to create a basic work-flow. Terrible UX!


> Anyway what you say does make sense; if it's an application you want to
> always have access and notifications. I just can't imagine a way this could
> be implemented without wasting system resources.

See bug 706274. The last bug standing in the way of this one.


> I think what needs to be solved first is these app tabs dissapearing
> altogether when you close new windows last. (i.e. bug #587400)

Bug 587400 is negated should this bug get finally get fixed.
(In reply to Paul from comment #48)
Thinking about this a bit, I see multiple windows as being similar to having multiple desktops, where one wouldn't expect (or want?) an application open in one desktop to be open in a different one. However, I do fully agree that App tabs should not be lost if one happens to close the App tab window before an non-App tab window, which is the case now. Perhaps an alternative would be to consider the App tab window as being the primary window and not allowing it to be closed until other secondary windows have closed. Accordingly, App tabs should be able to be created in any window but only be pinned to the primary window. Note: Also, maybe placing a symbol like, say, an "*" on the taskbar tab to signify the primary window would make it easier to locate said window when one needs to access the App.
Summary: App tabs should be the same in each window → Pinned tabs should be the same in each window
(In reply to Patrick Thompson from comment #51)
> Thinking about this a bit, I see multiple windows as being similar to having
> multiple desktops, where one wouldn't expect (or want?) an application open
> in one desktop to be open in a different one.

That's silly.  Properly designed multiple desktops allow for global desktop/workspace visibility as an option.  There are plenty of use cases where a user would desire a tab common to all windows, tab groups, etc.  Web email is one that I would definitely make global.

Given that Firefox has deprecated* the tab group/panorama feature not long after introduction (which faithfully made app tabs global to all tab groups) and now encourages users to leverage multiple windows instead, it seems like this feature should be escalated.

* see bug 589336 comment 29

> pinned to the primary window. Note: Also, maybe placing a symbol like, say,
> an "*" on the taskbar tab to signify the primary window would make it easier
> to locate said window when one needs to access the App.

Please don't do this!  This is bad UX.

I'd just suggest two options:
* pin as app tab (behaves as today...pins to local window and its tab groups, if present)
* pin as global tab

Also (In reply to Daniel from comment #18)
> until this will be implemented, for all people interested, maybe also as a
> reference for implementation, this addon makes app tabs permanent and shared
> across all windows.
> 
> https://addons.mozilla.org/en-US/firefox/addon/tab-utilities/

I installed this with high hopes.  However, my experience is that this extension *duplicates* app tabs across all windows.  I.e. each window's app tab state is unique.  No good.
It's pretty clear from various discussion and roadmaps that we no longer want this.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Frank, do you have links to those discussions or roadmaps? It would help all of us to understand this decision. Thanks.
From what I could make out from a few of the bugs where there was talking of integrating Sync and Panorama more deeply, it's simply a case of Panorama not being in the vision of the product or the UX Team. It's pretty much a dead product waiting to be put out of its misery. The future of Panorama may fall back to an extension/extensions.
This bug is about AppTabs and not Panorama.
Oops you're right, sorry for that one. It's that App Tabs are now considered Pinned Tabs and as such much of the functionality one would expect from App Tabs, such as being globally available are outside of the expectations of their application. You may have noticed that all 'App Tab' references were replaced with that of 'Pinned Tabs' a while back.
So does this mean pinned tabs are going away? If not, is there a backup plan for fixing bug 587400, which is a data loss bug for someone using pinned tabs?
Flags: needinfo?(fyan)
(In reply to Henrik Skupin (:whimboo) from comment #54)
> Frank, do you have links to those discussions or roadmaps? It would help all
> of us to understand this decision. Thanks.

No, I don't, because we discussed this verbally and IRC, so I can only point to the complete lack of resourcing or even mention of this work for all the more recently updated Wiki pages. After pinned tabs were implemented, it became clear to different people on the team at different times that mirroring them across windows made neither technical nor usability sense within the non-fullscreen windowing paradigms of desktop OSes. For example, if two windows are different sizes, it is impossible to mirror the viewport of an app tab between windows, so instead you have to pull the docshell back and forth between windows as the user switches between them, which is a technical and usability mess. Creating new, independent instances of the pinned pages with each new window also doesn't make sense from a usability standpoint.

Pinned tabs aren't going away in Firefox. They just aren't going to be mirrored across windows.
Flags: needinfo?(fyan)
(In reply to Roman from comment #58)
> So does this mean pinned tabs are going away? If not, is there a backup plan
> for fixing bug 587400, which is a data loss bug for someone using pinned
> tabs?

The problem here is that pinned tabs were incorrectly advertised as a magical feature that ensures that you never lose one, and we even built a separate session restore mechanism for them, but since they are tied to a window like normal tabs, they inherently and unavoidably have the same benefits and flaws of normal tabs. Pinned tabs are really just small tabs that don't get scrolled off when the tab bar overflows and are less likely to be accidentally closed (via accel+w or tab close button), and that's totally okay and a great feature by itself, and we shouldn't have promised more than that.
Just duplicating Pinned Tabs with independent instances is not a perfect solution. But at least it wouldn't involve frequent user data loss, and an overall awful UX (which is the current state of affairs).

May I add that many "web apps" that people use as Pinned Tabs -- including Facebook-types and webmail clients -- already do the heavy lifting of synchronizing concurrent instances. For example, new e-mail appears on all instances, and chat messages as well.
Flags: needinfo?(fryn)
Flags: needinfo?(fryn)
wouldn't it be much simpler if a pinned tab history list would be created?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: