354991 - Tabbed browsing and Back/Forward are broken on 1st start of Seamonkey after installation

Status: RESOLVED WORKSFORME

(SeaMonkey :: Tabbed Browser, defect)

Description

[Tony Mechelynck [:tonymec]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060929 SeaMonkey/1.5a
Build Identifier: 20060930

Tabs don't work in Seamonkey 2006-09-30 trunk nightly

Reproducible: Always

Steps to Reproduce:
1. With an older version of Seamonkey, open several tabs and, in Edit Preferences, set Home page to "current group" and untick "Hide the tab bar when only one tab is open".
2. Install 2006-09-30 trunk nightly.
3. Start Seamonkey.

Actual Results:  
Seamonkey starts up with only one tab open and tab bar not showing. File -> New -> Navigator Tab neither opens a new tab nor displays the tab bar; the only thing it does is that the tab bar (with only one tab) can now be displayed using "View -> Show/Hide -> Tab Bar. Clicking the Home button does nothing but hovering the mouse over it shows the list of home tabs in a tooltip popup.

Expected Results:  
Seamonkey should have started up with all home tabs opened and showing in the tab bar.

Additional info:
The user agent displayed in full above is the previous nightly (which works). I downgraded in near-panic before reporting the bug or even writing down the exact user-agent string. The incriminated build was the September 30 build as downloaded from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/seamonkey-1.5a.en-US.linux-i686.installer.tar.bz2

Comment 1

[Andrew Schultz]

Do you have any extensions installed?  Do you see the problem with a clean profile?

Comment 2

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

I can't reproduce this in my local build, which has all the undo-close-tab-related stuff I landed (though it does also have some modifications by Neil and me).

Comment 3

[Tony Mechelynck [:tonymec]]

(In reply to comment #1)
> Do you have any extensions installed?  Do you see the problem with a clean
> profile?
> 

I didn't try a clean profile; the bug freaked me out. I immediately reinstalled the 2006-09-29-01 build, which doesn't exhibit the bug.

I think I have a few extensions, now which ones? Unlike Firefox, Seamonkey has no extensions manager.

Talkback, of course. Maybe Venkman. Maybe MR-Tech Local Install.

Since I install with the installer, my install directory is re-created every time (or is it?). How can I get the list of extensions installed globally and locally?

Comment 4

[Andrew Schultz]

You can get a reasonable idea what extensions are installed into your profile by looking in the profile/chrome directory (~/.mozilla/salt.slt/name/chrome/).  Typically, there's a .jar for each extension.

Are there any errors in the Error console when this happens?

Comment 5

[Tony Mechelynck [:tonymec]]

Attachment: ls of chrome directory

In reply to comment #4 :

There is no salt.slt/ in ~/.mozilla/ but there is a default/ subdirectory which IIUC contains my SeaMonkey profile. This attachment is the result of "ls -l" the chrome/ directory two levels down. The exact path and command-line are at top.

20 of these jar files should be themes; the active theme is AllAmerican.

I didn't check the error console: I noticed that my tab bar didn't appear, clicked "New Tab" in the menus, opened the tab bar in the View menu, noticed only one tab, clicked the "New tab" button at left of the tab bar, saw nothing happen, and decided to immediately reinstall the previous nightly. No other checks done.

Comment 6

[Tony Mechelynck [:tonymec]]

Attachment: ls of /usr/local/seamonkey/chrome (but for Sep.29 nightly)

Comment 7

[Tony Mechelynck [:tonymec]]

Attachment: /usr/local/seamonkey/chrome/installed-chrome.txt (also for Sep.29 nightly)

Comment 8

[Felix Miata]

In yesterday's 1.1b/1.8.1 on OS/2 I can't open new browser tabs from CZ links either with context menu or middle click. I wonder if this is the same problem?

Comment 9

[:Gijs (he/him)]

(In reply to comment #8)
> In yesterday's 1.1b/1.8.1 on OS/2 I can't open new browser tabs from CZ links
> either with context menu or middle click. I wonder if this is the same problem?
> 

I can't test this right now, perhaps I can manage to do it tomorrow. Are there any JS errors reported on the (js) console when you try to open a link in cz in a new tab?

Comment 10

[Tony Mechelynck [:tonymec]]

Attachment: tests with 2006-10-01-01 build

Oct.01 build "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061001 SeaMonkey/1.5a" {Build ID: 2006100101} exhibits the bug, but not on a clean profile. Attachments show tests done, and errors displayed in the error console when running with my "default" profile (which exhibits the bug).

Comment 11

[Felix Miata]

The error console had so many CSS errors I couldn't spot any other type before clearing it to try again. What I reported in comment 8 happened shortly after opening the latest 1.8.1 branch nightly from yesterday. That was some hours ago, and now I can no longer reproduce. Maybe I was seeing one of OS/2's schizophrenic focus problems. My only added extension is Web Developer. 

Comment 12

[Andrew Schultz]

The first error is probably the most relevant/important:

x Error: this.docShell has no properties
  Source File: chrome://global/content/bindings/browser.xml

But I don't know how that relates to bug 350416.

Since you don't see this with a clean profile, can you either
1. Back up your default profile
2. remove everything in the chrome directory (brute force uninstallation of extensions)
3. Delete preferences from prefs.js

If the bug goes away after #2, we know it was an extension, otherwise do #3 a bit at a time until it works and then we'll know what preference is needed to see the bug.  #2 and #3 both should be done while SeaMonkey is not loaded.

4. restore your profile.  :)

Comment 13

[Tony Mechelynck [:tonymec]]

Attachment: userChrome.css which was (apparently) causing the bug

> Since you don't see this with a clean profile, can you either
> 1. Back up your default profile
> 2. remove everything in the chrome directory (brute force uninstallation of
> extensions)
> 3. Delete preferences from prefs.js
> 
> If the bug goes away after #2, we know it was an extension, otherwise do #3 a
> bit at a time until it works and then we'll know what preference is needed to
> see the bug.  #2 and #3 both should be done while SeaMonkey is not loaded.
> 
> 4. restore your profile.  :)
> 

Luckily I didn't even have to go that far.

1. Select "Modern" theme in preference to AllAmerican. Bug still present.
2. Rename userChrome.css to userChrome.txt. Bug disappears.

I am adding my userChrome.css as an attachment. It is largely based on the userChrome-example.css and the Mozilla documentation. ?:-|

Comment 14

[Tony Mechelynck [:tonymec]]

Attachment: userChrome.css _not_ causing the bug

After reinstating _everything_ (theme and userChrome.css) the bug does _not_ reappear. Since I readded the userChrome.css lines one-by-one, the format is marginally different. I don't understand what might have caused the bug with the original one.

?:-| ?:-| ?:-|

Comment 15

[Andrew Schultz]

I still don't see the bug with All American theme and your userChrome.css
Do you see the bug with the clean profile if you install the theme and grab the userChrome.css?

Comment 16

[Tony Mechelynck [:tonymec]]

(In reply to comment #15)
> I still don't see the bug with All American theme and your userChrome.css
> Do you see the bug with the clean profile if you install the theme and grab the
> userChrome.css?
> 

Well, no. Not even if I also install the MR-Tech Local Install extension. And yet I didn't dream.

What was changed between 2006-09-29-01 and 2006-09-30-01? Buffer sizes? Format of some files created automatically by Sm in my profile? Is there a limit to how many themes are installed? (ready to be activated I mean. Of course only one can be active at any one time).

<shrug /> I suggest we leave this bug UNCONFIRMED for a week or two, then resolve it WORKSFORME if no one sees it again. What do you think? If it resurfaces later it can always be REOPENED.

The problem remains of whether Felix's OS2 problem is the same bug or not. It's not clear to me yet. If neither problem can be reproduced the question may become moot.

Comment 17

[Tony Mechelynck [:tonymec]]

§$*ç§%£µ²³@#+= !!!

Installed "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061002 SeaMonkey/1.5a" {Build ID: 2006100201} and the bug reappeared. :-(

And this is with my "second" version of userChrome.css

I'll come back if I can find a way to make it work.

Comment 18

[Tony Mechelynck [:tonymec]]

The following procedure makes the bug disappear:

1. Close Seamonkey.
2. Rename userChrome.css to something else.
3. Open Seamonkey. (Bug has disappeared.) Close Seamonkey.
4. Rename userChrome.css back with no changes.
5. Open Seamonkey. Bug is still not there.

Comment 19

[Andrew Schultz]

Right.  I guess if you try to narrow things down to identify what causes the bug (as in comment 12) you should try to get the bug to happen again by putting whatever you removed back.  userChrome.css is probably a red herring although I don't know why it has any effect.  And once you identify something that's needed to see the bug, put it back and try removing the other things from your profile to ensure they're /not/ needed.

Comment 20

[Tony Mechelynck [:tonymec]]

(In reply to comment #19)
> Right.  I guess if you try to narrow things down to identify what causes the
> bug (as in comment 12) you should try to get the bug to happen again by putting
> whatever you removed back.  userChrome.css is probably a red herring although I
> don't know why it has any effect.  And once you identify something that's
> needed to see the bug, put it back and try removing the other things from your
> profile to ensure they're /not/ needed.
> 

Hm. I'll go into town soon now. I may try something after midnight my time (timezone +2) if I'm not too tired by then. Is there something special that happens (a) when installing using the full installer (something that could trigger the bug), and (b) when the profile contents have been changed while Sm was not running (such as removing userChrome.css) (something that could cure the bug)? I suppose there's nothing obvious...

BTW, I've targzipped my profile (in case someone wanted to try building a testcase out of it) but I suspect it's too big for upload: 53,777,936 bytes, or 16,234,263 without default/Cache/ . Any suggestions?

...but at the moment, the bug is not showing. Maybe I should wait until tomorrow's nightly becomes visible, and if the bug triggers again, take a snapshot at that point in time. Are there any text files whose contents might give a hint about the cause of the bug if it reappears?

Comment 21

[Andrew Schultz]

> Is there something special that happens...

You might try removing any Mail/News from your profile tarball.  And perhaps history.dat.  Anyway, 16MB is small enough that I'd be willing to download it.  Can you post it somewhere (you can send me the link via email if you don't want the whole world seeing your profile)?

Comment 22

[Tony Mechelynck [:tonymec]]

(In reply to comment #21)
> > Is there something special that happens...
> 
> You might try removing any Mail/News from your profile tarball.  And perhaps
> history.dat.  Anyway, 16MB is small enough that I'd be willing to download it. 
> Can you post it somewhere (you can send me the link via email if you don't want
> the whole world seeing your profile)?
> 

- The whole world can see my profile if they want to; the problem is I don't have that much hosting space available (or barely: I'm using 36152K and my limit is set at 51200K).
- There isn't any mail/news in my SeaMonkey profile: I haven't set up any mail/news accounts yet, I'm still using Thunderbird 1.5.0.7 for that. (Sm has both advantages and inconvenients compared to Fx+Tb and I'm not sure I want to make the changeover yet.)
- default/ only contains Cache/, XUL.mfasl and r94771wy.slt/ ; the latter contains chrome/ plus a number of files; the largest of these files is history.dat (417167 bytes). I suppose I may want to remove 58696440.s which seems to contain my saved passwords, though not in human-readable form. Without that, the cache, and history.dat, the .tar.gz is still 16 MB. Shall I try sending it to you attached to an email?

Comment 23

[Tony Mechelynck [:tonymec]]

Bug happened on 1st startup after installing "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061003 SeaMonkey/1.5a" {Build ID: 2006100301}. Just closing and reopening Sm was enough to make the bug disappear, so you're right: userChrome.css was a red herring.

Comment 24

[Tony Mechelynck [:tonymec]]

I wonder if this is properly a "tabbed browser" bug, or an "installer" bug...

Comment 25

[Felix Miata]

Try the plain tar.bz2 and see.

Comment 26

[Tony Mechelynck [:tonymec]]

(In reply to comment #25)
> Try the plain tar.bz2 and see.
> 

Right. Bug does happen on 1st launch (only) after "rm -Rvf /usr/local/seamonkey" followed by "tar -xvC /usr/local -f seamonkey-1.5a.en-US.linux-i686.tar" so we can rule out the installer.

Comment 27

[Felix Miata]

I have no idea how bugzilla got the idea this should be confirmed. There was a midair from trying to add comment 25. I went back, hit reload, typed my short comment, and somehow confirmed was the result.

Comment 28

[Reed Loden [:reed]]

(In reply to comment #27)
> I have no idea how bugzilla got the idea this should be confirmed. There was a
> midair from trying to add comment 25. I went back, hit reload, typed my short
> comment, and somehow confirmed was the result.

Accidentally hit the wrong radio button, maybe?

Comment 29

[Felix Miata]

AFAIK, I clicked only thrice after hitting reload: 1st to scroll to see the textarea; 2nd to focus the textarea; and 3rd to commit.

Comment 30

[Tony Mechelynck [:tonymec]]

Comment on attachment 240882 [details]
userChrome.css _not_ causing the bug

Editing prefs.js while SeaMonkey is closed makes the problem reappear at next startup. Just adding an and-of-line space within a comment is enough.

Comment 31

[Tony Mechelynck [:tonymec]]

While this bug is manifesting itself (i.e., from the first load of Sm after update until closed down), the "Forward" and "Back" buttons, and the corresponding items in the "Go" menu, are non-functional (greyed-out), even after following links back and forth.

Comment 32

[Tony Mechelynck [:tonymec]]

Today's build
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061112 SeaMonkey/1.5a
Build ID: 2006111201
seems not to be affected by the bug. (Yesterday's build was.)
??? Secondary effect of a fix landed in these last 24 hours ??? Or was it something I inadvertenly did ??? Insofar as I remember it, nothing changed in the profile between yesterday and today.

So, let's recap:
- bug was not present until and including 2006-09-29
- bug was present on all nightly trunk builds from 2006-09-30 to 2006-11-11 included
- bug (apparently) disappeared on 2006-11-12
- in "bugged" builds, Sm has no tabs and no functional "Back" and "Forward" browsing functions on first load after either installing a build (be it from the installer or from the .tar.bz2) or editing prefs.js (even if the edit is within a comment). Closing and restarting the same build clears the bug -- until next install.

I'm baffled. Is anyone seeing anything similar?


I suggest waiting a few days (a week, maybe), and marking this bug WORKSFORME if it isn't sighted again in the meantime, then VERIFIED after some more waiting (a month or two maybe). _Serious_ comments welcome.

Comment 33

[Tony Mechelynck [:tonymec]]

I notice that there was much "fixing activity" yesterday on bugs which could have caused "racing between XUL overlays", whatever that be (e.g. bug 319654 , bug 359959 , bug 360119 ); but I can identify nothing concomitant with the "onset" of this bug on Sep.30. Maybe a red herring again?

Comment 34

[Tony Mechelynck [:tonymec]]

Changing to WORKSFORME.

Reopen (or add a comment) if this bug bites you.

Comment 35

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061210 SeaMonkey/1.5a
Build ID: 2006121001

Upgrading "MR Tech Local Install" extension (by uninstall, restart, install new version, restart, because straight upgrade doesn't work) makes the bug reappear on restart. I'm trying to contact the maintainer.

Comment 36

[Tony Mechelynck [:tonymec]]

It's even worse than that:

With the latest version (5.3.2.1) of MR Tech Local Install, I can't get more than one tab no matter what I do, not even by restarting SeaMonkey. After uninstalling it, the tabs reappear but not on first load.

Comment 37

[Tony Mechelynck [:tonymec]]

SH**! Reinstalling the older MTLI version from chrome uninstall backup doesn't work. Only uninstall does. ?:-(

Comment 38

[Tony Mechelynck [:tonymec]]

(In reply to comment #37)
> [....] Reinstalling the older MTLI version from chrome uninstall backup doesn't
> work. [...]

...but reinstalling MTLI 5.2 from https://addons.mozilla.org/firefox/421/history/ does work. I'll be doing some more tests, and report the results not here but on the MTLI forum thread at MozillaZine.

Comment 39

[Tony Mechelynck [:tonymec]]

I thought this bug was still open.

I still get broken tabbed browsing, now on every load of every trunk nightly of SeaMonkey. To make the tabbrowser work I have to hit Ctrl-N repeatedly until a window happens to open with a visible tab bar (when I'm lucky it's the second window; it's never the first one). Then I can close all other (tabbrowser-broken) windows.

Notes:
- I have a multitab homepage
- My prefs are set to display the homepage when opening a new window
- My prefs are set to always display the tab bar (even if there is only one tab), yet the tab bar doesn't display on the "broken" windows. It can be displayed using View => Show/Hide but shows only one tab and the "New Tab" button does nothing. Hovering the mouse over the Home button shows the full list of tab URLs in a tooltip, even in "broken" windows.
- I was using the DOM inspector tool today and I happened to notice that (in a window with all tabs working correctly) the first tab is listed as "xul:tab" with both "first-tab" and "last-tab" attributes set to true; its content is listed a little lower down as "xul:browser". All other tabs including the last one are listed as "tab" with neither "first-tab" nor "last-tab" present, and their content is "browser" ("tab" and "browser" without "xul:"). This strikes me as bizarre. I would expect all tabs to be the same element kind, and "last-tab" to be on the last tab, not the first. These symptoms are repeatable.
- I'm using the Modern theme distributed with SeaMonkey.
- I never experienced this bug in Firefox (neither "BonEcho" Fx2 nor "Minefield" Fx3).

Current version:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070528 SeaMonkey/1.5a - Build ID: 2007052801

Comment 40

[Tony Mechelynck [:tonymec]]

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/2007052909 SeaMonkey/2.0a1pre

This bug seems not to be persent in suiterunner; however this is my first load of it with multitab homepage. If it later comes back, I'll be sure to comment.

Comment 41

[Tony Mechelynck [:tonymec]]

I spoke too fast. bug reappears on next load of same build... maybe I have a hint of what causes it; more about this later.

Comment 42

[Tony Mechelynck [:tonymec]]

MR-Tech Local Install, which is supposed to be "compatible" with Sm 1.5, is the culprit :-(

Comment 44

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040601 SeaMonkey/2.0a1pre

Problem has disappeared since yesterday's nightly, after installing MR-Tech Toolkit 6.0a28 in the day-before-yesterday's nightly (which still exhibited the bug on restart). I don't know if the fix is from the Mr-Tech side or the Mozilla side but I'm relabeling this bug as FIXED.

Comment 45

[Jason Bassford]

Any actual browser code change is unknown.

-> WORKSFORME