Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23a1 ID:20130915003001 c-c:d26eff2ae9e0 m-c:9366ee039645 Of my many tabs (currently 99), some (currently the last 19) aren't loaded at startup until and unless I use the Go (not Reload) button on them. This has started appearing a few days ago but I don't remember exactly when. The first time I saw it, the problem affected all tabs except the current one.

Problem did not appear when going to SafeMode and back the usual way (Help → Restart with Add-ons Disabled with, then without, the checkbox tick). I'll now try starting Safe Mode from a shell prompt.

After Ctrl+Q followed by "seamonkey -P default -safe-mode >> ~/seamonkey.log 2>&1" then Ctrl+Q and normal start-up, the problem did not reappear. Apparently restarting in Safe Mode just after loading the tabs manually was "just what it needed". I'll close this bug WORKSFORME if it doesn't reappear in a few days. I'm attaching about:support in case anyone had an idea about which add-on(s) might be a possible cause of the misbehaviour. I have backlogs (with extensions.logging.enabled). I'll zip them (or .tar.bz2) and attach them or upload them where you might get at them, but only on request because they are somewhat bulky (let's say on the order of 1 MiB per day).

How many extensions and plugins do you have installed?

I don't know whether it's related but I had a problem with my sessionstore yesterday, I had to delete all of the "storage" entries to get it to work.

...and again with a build from Friday. At the moment I don't know whether the problem is with writing or reading.

(In reply to Philip Chee from comment #3) > How many extensions and plugins do you have installed? Plugins: 8 enabled Extensions: 74 enabled, as can be found by counting lines "Enabled: true" in attachment 805110 [details]. Yes, I know this is an unusually high number, and I've seen it said that "most users have fewer than 10 addons installed, if any". (I suppose the "if any" part applies to Firefox users but not necessarily to SeaMonkey users.)

Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24a1 ID:20130918003001 c-c:ea987ac7a344 m-c:ab4ccf3d6b60 Problem has not reappeared. With a new version number, I guess it's time to close this bug.

Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24a1 ID:20130918003001 c-c:ea987ac7a344 m-c:ab4ccf3d6b60 I spoke too fast: problem appeared again, on restart from a kernel panic. Oh I hate those B (black) SODs.

What I'm seeing... I caught this one early, not sure if related: > Error: getBrowser(...).securityUI.QueryInterface(...).SSLStatus is null > Source File: chrome://navigator/content/nsBrowserStatusHandler.js > Line: 370 On the (initial?) click a "dead" (non-responsive) tab, I always get the following series: This always repeats itself 4 times. The content within the particular DEPRECATION WARNING may vary: > Error: DEPRECATION WARNING: nsIContentPrefService is deprecated. Please use nsIContentPrefService2 instead. > You may find more details about this deprecation at: https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIContentPrefService2 > chrome://communicator/content/viewZoomOverlay.js 200 FullZoom_onLocationChange > chrome://navigator/content/nsBrowserStatusHandler.js 344 null > chrome://navigator/content/tabbrowser.xml 844 notifyUrlBar > chrome://navigator/content/tabbrowser.xml 841 updateUrlBar > chrome://navigator/content/tabbrowser.xml 993 updateCurrentBrowser > chrome://navigator/content/tabbrowser.xml 2769 onxblselect > chrome://global/content/bindings/tabbox.xml 642 set_selectedIndex > chrome://global/content/bindings/tabbox.xml 661 set_selectedPanel > chrome://global/content/bindings/tabbox.xml 389 set_selectedIndex > chrome://global/content/bindings/tabbox.xml 421 set_selectedItem > chrome://global/content/bindings/tabbox.xml 466 _selectNewTab > chrome://global/content/bindings/tabbox.xml 761 onxblmousedown > null 0 null > > Source File: resource://gre/modules/Deprecated.jsm > Line: 79 Then followed by this: > Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsISHistory.getEntryAtIndex]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/components/nsSessionStore.js :: sss_restoreTab :: line 2723" data: no] > Source File: resource://gre/components/nsSessionStore.js > Line: 2723 Possible that this also may appear: > Error: getBrowser(...).securityUI.QueryInterface(...).SSLStatus is null > Source File: chrome://navigator/content/nsBrowserStatusHandler.js > Line: 370 Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23a2 Build identifier: 20130920013001

A "Dead" page's location bar shows the expected URL, but the actual "page" is blank (about:blank). Preference setting of Browser | "When restoring preferences and windows"; immediate, count, or when i need, is immaterial. Occurs with ALL extensions & ALL plugins disabled. Most typical is that the first window is affected, though others can be too. Clearing ALL private data does not seem to have any affect. Doing so may help alleviate the situation, or at least for some tabs, but the issue still persists. The Error: DEPRECATION WARNING: message spew incessantly. I'm not really sure if any of the above error messages are necessarily related?

(In reply to therube from comment #9) [...] > Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0 > SeaMonkey/2.23a2 > Build identifier: 20130920013001 I haven't checked the error console, my stdout/stderr logs are available but bulky and I haven't (yet) looked at them either; but from what I saw you say on IRC the symptoms are the same. Since you're seeing it on Win32 and I on Linux64 it deserves Hardware/OS = All/All. Once I have hit "Go" on all "dead" tabs in turn, the problem usually goes away for a few sessions. Cycling through Safe Mode may help; I have also occasionally seen it fail spectacularly (on one occasion, I've seen 4 tabs loaded at Safe Mode startup and the other 97 blank without even a URL in the location bar). Happily I have enough backup sessions. Once cleared, the problem may reappear spontaneously, especially after a hard reboot, e.g. (in my case) AC power off/on due to CPU lockup; but I don't have STR which would "produce" the bug every time. Among a lot of other extensions, I use Session Manager (currently 0.8.0.8) from AMO. Of course not in Safe Mode. When closing SeaMonkey "normally" I save my tabs for next startup: I think this bypasses the extension; however I've found it invaluable in case of crashes, and to manage (and reload) past sessions. The AMO page for the extension, https://addons.mozilla.org/addon/session-manager/ says in the "Version Information" foldout at bottom, "Works with Firefox 10.0 and later, SeaMonkey 2.7 and later" but it also says next to the button, "Not available for SeaMonkey 2.24a1" meaning the maxVersion hasn't yet been bumped but the "Default to Compatible" feature ought to let it work (have there been recent changes in the tabbrowser system? And BTW I also have extensions.checkCompatibility.nightly set to false but I watch out as best I can for misbehaving extensions) There is a "development version" of that extension but I'm not using it. Hm, I see in its release notes: > * Added hidden preference extensions.{1280606b-2510-4fe0-97ef-9b5a22eafe30}.do_not_fix_tabgroups which if set to true, causes Session Manager to not try to correct tab groups. Maybe I should set that to true; what are tab groups anyway? I don't know if SeaMonkey supports them, and in any case I'm not using them, not even on Firefox. therube: are you also using that "Session Manager" extension?

I have been using Aurora. SeaMonkey 2.22a2 did not have this problem. The issue for me started with SeaMonkey 2.23a2. I've seen it in Windows, both XP & Win7. I'm not sure of STR to generate the problem?

(In reply to therube from comment #10) > A "Dead" page's location bar shows the expected URL, but the actual "page" > is blank (about:blank). With me it isn't exactly about:blank: it's grey as when preparing to GET a URL from some remote host, not white as for about:blank. But it _is_ featureless otherwise; and usually the URL is there. [...] > Occurs with ALL extensions & ALL plugins disabled. I guess this answers my question. > Most typical is that the first window is affected, though others can be too. [...] I use only one browser window. (Also one MailNews window and one ChatZilla window but they aren't affected.)

Empty your Profile. Copy the contents of attached ZIP into it. Prefs.js set to load Session Restore, all Plugins & all Extensions disabled. sessionstore.json file that should replicate the issue. Nothing more. I'm thinking that the sessionstore.json file was likely initially generated, at the latest, mid-August & likely with SeaMonkey 2.22a2. Possibility exists that since then almost any earlier version of SeaMonkey may have accessed that file, but I'm not sure?

> With me it isn't exactly about:blank: it's grey as when preparing to GET a URL > from some remote host, not white as for about:blank. But it _is_ featureless > otherwise; and usually the URL is there. Right. That's just what I see too.

(In reply to Tony Mechelynck [:tonymec] from comment #13) > (In reply to therube from comment #10) > > A "Dead" page's location bar shows the expected URL, but the actual "page" > > is blank (about:blank). > > With me it isn't exactly about:blank: it's grey as when preparing to GET a > URL from some remote host, not white as for about:blank. But it _is_ > featureless otherwise; and usually the URL is there. > > [...] Oh, and I forgot: even the favicon on the tab (on the tab bar) is missing. With the "many tabs" I have, only the favicon is shown on the tab, and I use userChrome.css rules to display the tabs on several rows (but fixed) rather than on one row (which moves about left and right).

I HAVE seen it in 2.24a1, I had set it for a purpose.

(In reply to therube from comment #12) > I have been using Aurora. > SeaMonkey 2.22a2 did not have this problem. > The issue for me started with SeaMonkey 2.23a2. I've been using Trunk, and neither have I seen it in 2.22a1 or earlier. For me the problem started near the end-of-cycle of 2.23a1, "a few days" before comment #0.

(In reply to therube from comment #14) > Created attachment 807815 [details] > Minimal Profile Testcase. So, you're saying that this profile opens correctly with 2.22 but not later versions?

morac: this is probably not related to your Session Manager extension (though, who knows?), however I thought it would be better to bring you onto this discussion: - you might have enlightening ideas - you might prefer not to be left out.

> you're saying that this profile opens correctly with 2.22 but not later versions? No, not exactly. Prior to running 2.23, it would have opened correctly in 2.22. But now that it has been opened in 2.23, it does fail in 2.22 (or earlier). > Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsISHistory.getEntryAtIndex]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/components/nsSessionStore.js :: sss_restoreTab :: line 2723" data: no] > Source File: resource://gre/components/nsSessionStore.js > Line: 2723 Without checking extensively, it looks like if I refresh (load) the affected pages while running 2.22, they are no longer affect on restart, still using 2.22.

(In reply to therube from comment #21) > > you're saying that this profile opens correctly with 2.22 but not later versions? > > No, not exactly. > > Prior to running 2.23, it would have opened correctly in 2.22. > But now that it has been opened in 2.23, it does fail in 2.22 (or earlier). Ah, so the problem seems to be that session store isn't saving session information correctly. > Without checking extensively, it looks like if I refresh (load) the affected > pages while running 2.22, they are no longer affect on restart, still using > 2.22. OK, so we have session store created by 2.23 doesn't open in 2.22, and session store created by 2.22 does open in 2.22 (unsurprisingly). And then I assume a session store created by 2.22 opens normally in both 2.22 and 2.23?

Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24a1 ID:20130919003001 c-c:1ea1fc3586db m-c:803189f35921 "extensions.{1280606b-2510-4fe0-97ef-9b5a22eafe30}.do_not_fix_tabgroups - user set - true" doesn't help and seems to hinder. I'm toggling it back to its default (false).

Oh, and BTW, even pages which would be expected not to cause problems (about:, about:config, about:crashes, about:plugins, about:buildconfig, …) were among the "dead" pages whose URL appeared but not the favicon and content. A few BMO pages were loaded but most weren't. AFAICT the tab which is "the current tab" at the time of SeaMonkey shutdown/restart is always loaded correctly.

Just an idea (I had a flash while on the stairs to the toilet): Couldn't the bug be due to the process exiting before the _asynchronous_ write of session data was completed?

Another thing I notice: the following rule in my userChrome.css affects the tabs correctly loaded but not the "dead" tabs: .tabbrowser-tabs tab[unread=true] /* not yet read: white */ { background-color: white !important }

…and, onmouseover over the "dead" tab (on the tab bar) the page title is correctly displayed (atop a blank thumbnail of course).

I think I have found the cause of the regression. Bug 785884, which landed on Gecko 26, i.e. SeaMonkey 2.23, removed the extendedOrigin property that session storage was using.

Trivial port of SessionStorage.jsm part of bug 785884.

This is what just happened to me: 1. I had painstakingly "woken up" all dead tabs (so they weren't dead anymore). 2. Help → Restart with Add-ons Disabled (with [√] Restart with Add-ons Disabled). --> Of my 100 tabs, only the current one got a favicon, plus a cluster of four somewhere in the middle. The rest were dead. 3. Clicked the last one of the cluster of four to make it current. It was a Facebook tab, and _after_ I clicked it, it loaded (its tab throbber throbbed for a few seconds, and the content got painted [or repainted, I couldn't say for sure]). 4. Ctrl+PgDn through all tabs but did _not_ wake them from the dead, they stayed dead. 5. Help → Restart with Add-ons Disabled (with [ ] Restart with Add-ons Disabled — i.e. unticked) --> _All_ tabs got loaded correctly (three at a time as always, in agreement with browser.sessionstore.max_concurrent_tabs)

Comment on attachment 807934 [details] [diff] [review] Proposed patch Looks reasonable.

For those who, like me, suffer from this bug, and until it gets FIXED: Sometimes I notice that just [Go] (or <Enter> in the URL bar) isn't enough (it loads the favicon in the URL bar, but neither the favicon on the tab nor the page contents); in that case both actions are needed, and in this order: 1. [Go] button, or <Enter> key in the URL bar 2. Reload (i.e. View→Reload, or Ctrl+R, or F5). Right-click→Reload doesn't work because no page context menu exists yet at this stage.

Pushed comm-central changeset ef87acafa4f7.

Comment on attachment 807934 [details] [diff] [review] Proposed patch [Approval Request Comment] Regression caused by (bug #): 785884 User impact if declined: Can't restore tabs that use session storage Testing completed (on m-c, etc.): Landed on c-c Risk to taking this patch (and alternatives if risky): Low String changes made by this patch: None

Comment on attachment 807934 [details] [diff] [review] Proposed patch a=me comm-aurora

(In reply to neil@parkwaycc.co.uk from comment #33) > Pushed comm-central changeset ef87acafa4f7. therube: can you check that this works on Windows? I can't test it on Linux because Linux builds are broken ATM.

Sorry guys ... Neil, thanks for fixing it!

(In reply to Tony Mechelynck [:tonymec] from comment #30) > This is what just happened to me: > 1. I had painstakingly "woken up" all dead tabs (so they weren't dead > anymore). > 2. Help → Restart with Add-ons Disabled (with [√] Restart with Add-ons > Disabled). > --> Of my 100 tabs, only the current one got a favicon, plus a cluster of > four somewhere in the middle. The rest were dead. > 3. Clicked the last one of the cluster of four to make it current. It was a > Facebook tab, and _after_ I clicked it, it loaded (its tab throbber throbbed > for a few seconds, and the content got painted [or repainted, I couldn't say > for sure]). > 4. Ctrl+PgDn through all tabs but did _not_ wake them from the dead, they > stayed dead. > 5. Help → Restart with Add-ons Disabled (with [ ] Restart with Add-ons > Disabled — i.e. unticked) > --> _All_ tabs got loaded correctly (three at a time as always, in agreement > with browser.sessionstore.max_concurrent_tabs) For other people like me, still suffering from this bug because no Linux builds since 19/9: when it hits, the following "simplified" procedure is usually enough to clear it: 1. If the last favicon before the series of "dead" tabs is for Facebook, click it. It might be an incompletely loaded tab. 2. Make sure that the Mailer is open. 3. Close _only_ the Browser window (e.g. by Ctrl+Shift+W in the browser). 4. If a "confirm" popup appears, asking if you're sure you want to quit, answer "Save and Quit". (This will not close the Mailer.) 5. Wait long enough to give the Browser time to close. 6. Restart the Browser by clicking the Navigator ("steering wheel") icon at bottom-left of the Mailer window. Advantages: - It's faster than going to Safe Mode and back. - If you have ChatZilla (or any other extension) running, it won't be closed, even temporarily.

Seen on IRC: <therube_agone> tonymec: re: Bug 916631#c36 yes it is & has been working correctly on Windows => VERIFIED

P.S. Of course he meanr bug 916631 comment #36.

Neil's comm-central changeset 9c812d89f8c9 referenced this bug instead of bug 913493. Sorry for the noise.