Closed
Bug 587873
Opened 14 years ago
Closed 12 years ago
Pinned tabs should be the same in each window
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
RESOLVED
WONTFIX
Future
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)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
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.
Reporter | ||
Updated•14 years ago
|
Blocks: pinnedtabs
Reporter | ||
Comment 2•14 years ago
|
||
From what I've heard today, we want to block on this...
blocking2.0: --- → ?
Reporter | ||
Comment 3•14 years ago
|
||
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)
Reporter | ||
Comment 4•14 years ago
|
||
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.
Reporter | ||
Updated•14 years ago
|
Attachment #467976 -
Attachment is patch: true
Attachment #467976 -
Attachment mime type: application/octet-stream → text/plain
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.
Comment 7•14 years ago
|
||
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)
Reporter | ||
Comment 8•14 years ago
|
||
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
Comment 9•14 years ago
|
||
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
Comment 10•14 years ago
|
||
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.
Comment 11•14 years ago
|
||
(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"
Comment 12•14 years ago
|
||
This bug is nearly the same as this bug Bug 587400
Comment 15•14 years ago
|
||
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.
Comment 16•14 years ago
|
||
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.
Comment 17•14 years ago
|
||
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.
Comment 18•14 years ago
|
||
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/
Comment 19•14 years ago
|
||
I agree this should be fixed.
Comment 21•14 years ago
|
||
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.
Comment 22•14 years ago
|
||
Instead of having identical app tabs on all windows, app tabs can be moved to the other open window.
Comment 23•14 years ago
|
||
(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.
Comment 24•14 years ago
|
||
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.
Reporter | ||
Comment 25•14 years ago
|
||
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)
Reporter | ||
Comment 26•14 years ago
|
||
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
Comment 27•14 years ago
|
||
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?
Comment 28•14 years ago
|
||
Oh, and the warnings comment 26 mentions are really not an issue. They really aren't. Just trust me on that.
Comment 29•14 years ago
|
||
> 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.
Comment 30•14 years ago
|
||
OK. I think it still makes sense to fall back to mScriptGlobal if we're not focused.
Comment 31•13 years ago
|
||
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?
Reporter | ||
Comment 32•13 years ago
|
||
(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.
Comment 33•13 years ago
|
||
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.
Comment 35•13 years ago
|
||
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
Comment 36•13 years ago
|
||
Hi, your comments (I think) should be filed as a separate bugs.
Reporter | ||
Comment 37•13 years ago
|
||
I'm not working on this right now and we may not need it going forward.
Assignee: paul → nobody
Updated•13 years ago
|
Attachment #542940 -
Flags: feedback?(dao)
Comment 38•13 years ago
|
||
(In reply to Paul O'Shannessy [:zpao] from comment #37)
> we may not need it going forward.
Do you mind elaborating?
Reporter | ||
Comment 39•13 years ago
|
||
(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
Comment 40•13 years ago
|
||
Thanks for the answer. Just to clarify, does this mean the goal of global App Tabs isn't currently a goal for Firefox?
Comment 41•13 years ago
|
||
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 :-)
Comment 42•13 years ago
|
||
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
Comment 43•13 years ago
|
||
(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.
Comment 45•12 years ago
|
||
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.
Comment 46•12 years ago
|
||
(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.
Comment 47•12 years ago
|
||
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.
Comment 48•12 years ago
|
||
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.
Comment 49•12 years ago
|
||
(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)
Comment 50•12 years ago
|
||
(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.
Comment 51•12 years ago
|
||
(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.
Updated•12 years ago
|
Summary: App tabs should be the same in each window → Pinned tabs should be the same in each window
Comment 52•12 years ago
|
||
(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.
Comment 53•12 years ago
|
||
It's pretty clear from various discussion and roadmaps that we no longer want this.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Comment 54•12 years ago
|
||
Frank, do you have links to those discussions or roadmaps? It would help all of us to understand this decision. Thanks.
Comment 55•12 years ago
|
||
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.
Comment 56•12 years ago
|
||
This bug is about AppTabs and not Panorama.
Comment 57•12 years ago
|
||
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.
Comment 58•12 years ago
|
||
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?
Updated•12 years ago
|
Flags: needinfo?(fyan)
Comment 59•12 years ago
|
||
(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)
Comment 60•12 years ago
|
||
(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.
Comment 62•10 years ago
|
||
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)
Updated•10 years ago
|
Flags: needinfo?(fryn)
Comment 63•10 years ago
|
||
wouldn't it be much simpler if a pinned tab history list would be created?
Comment hidden (advocacy) |
You need to log in
before you can comment on or make changes to this bug.
Description
•