Tab Mix Plus

mhowie,
try tabmix on clean profile

Okay I've reproduced this. Apparently if a session is loaded when the browser is starting up and Firefox doesn't think it's a reload or a crash, the concurrent_tabs preference is ignored for the first window in the session. I'm not sure why that would be though since the concurrent_tabs preference is enforced by Firefox itself and Session Manager doesn't do anything different when restoring sessions at startup or when done manually later.

So this is technically a Firefox bug since it seems to be ignoring the concurrent_tabs preference at startup. I'm going to have to research this more, but I'm not sure I can fix this on my end.

I tracked the problem down to a bug in Firefox that causes it to think the number of loading tabs is -1.

It actually doesn't matter what session is loaded at start-up or if that session has pinned tabs or not. The problem is triggered by having pinned tabs at shutdown and it doesn't matter if Session Manager makes a back up session or not. The bug is triggered based on the number of tabs that were pinned on shutdown, the number of tabs in the loaded session and the browser.sessionstore.max_concurrent_tabs preference. The problem occurs on a per window basis. The problem doesn't occur if there were no pinned app tabs at shutdown.

With browser.sessionstore.max_concurrent_tabs preference set to 0, if the number of tabs in the session loaded minus the number of pinned app tabs is 2 or greater, than Firefox gets confused and will load all the tabs at once. This is on a per window basis.

So for example, if there is one app tab, then any session with 3 or more tabs in a window will have all the tabs in that window load simultaneously. If there is two app tabs, then any session with 4 or more tabs in a window will have all of them load.

With browser.sessionstore.max_concurrent_tabs set to a value greater than 0, it will simply cause extra tabs to load concurrently or sometimes not at all.

I've filled Bug 636279 documenting this problem.

The only way Session Manager could work around this is to delay the loading of the session at start up for a while which isn't really desirable.

Just to clarify, when you say 'tabs in titlebar' do you mean the Mf menu option 'Tabs on top' and then using a style to put them in the title bar?

1) Double clicking on the tab bar results in the window size changing (same as if you clicked the "restore down" button in the upper right of your screen). My desired behavior forever is for a new tab to open when I double click on the tab bar. I have only recently noticed this problem.

2) With respect to the TMP session manager feature...I found that even if I had the selection to "reload all tabs" unchecked, all the tabs would reload upon selecting a saved session from the TMP dialog box when starting FF.

I tried it on a clean profile but the problem re-emerged. However, as a result of this, I now believe the Session Manager extension is at fault. I say this as when I disabled that extension, and used the built-in TMP session restore feature- the problem did not manifest. Unfortunately the Session Manager extension is much more robust, so I will post information on that author's support forum in the hope a change can be made to allow the two extensions to co-exist and enable tabs to be displayed in the title bar.

I managed to reproduce the problem with the tabs not displaying in the title bar. It requires a very specific set of steps though. First Session Manager must be set to prompt for a session on startup. Second the user must either shut down Firefox with the window maximized or choose to restore a session where the windows are maximized. At this point there's no way to get the tabs in the title bar other than to open a new window. The problem only occurs if Tab Mix Plus is installed and enabled. Without TMP installed it behaves as normal.

Using DOM Inspector it looks like all the DOM values are being set correctly, but for whatever reason some CSS values are not, for example the "titlebar" vbox should have CSS Rule of style="" with a value of "margin-bottom: -27px;" but it does not. That CSS value should be part of the Firefox code itself, so TMP must be replacing the values with it's own and not handling certain cases such as Session Manager restoring a session from a window prompt.

Session Manager may be triggering the problem, since it works correctly without TMP installed, it's not the cause. Since Session Manager just calls the Firefox API to restore the session, so I'm inclined to think it's something TMP is doing (or not doing correctly).

underpass,
see if this thread helps, looks like your issue discussed there: http://forums.mozillazine.org/viewtopic ... &t=2124581

@onemen
as of the FF 4 RC they'we modified the height of the tabs. it's a matter of taste if one likes the higher ones or not, but i would personally love to have the option to modify that in TMP.
before someone jumps all over me to tell me this is not a feature request forum, i'll tell you i figure since this is the forum where you discuss preparing the "final" version of TMP for FF4, witch is highly dependent on the development of FF4, this is also the best place to ask for something like this.
thank you in advance onemen, and always greatful for your consistent effort

tabs container is a box between Minefield button (left side) and the Windows minimize/maximize/close buttons (right side).

when we apply multi-row, we expand the box vertically.

So this "tabs container"... is that a Firefox parameter or a TMP parameter? If the former, seems that no tab utility could utilize the entire screen in rows below the titlebar?

Using archlinux x86_64, firefox 4.0b12 candidate build1, and equivalent (ie of roughly the same date) TMP tab_mix_plus-0.3.8.5pre.110221a.xpi.

Buttons for scrolling - when tabs become too many - no longer appear at the far two (right and left) edges of the tab-bar.

Up until b11 everything was fine.

Theme is the default one.

I will attach a shot, in a few minutes.



PS: Attachment added.

PS2: I see now that is the exact same bug ChrisM posted, at the top of the page.

wantilles thank you for the omni.jar

try the new dev-build, i think it should work ok