663755 - After session restore, opening a new window ALWAYS opens a blank page

Status: NEW

(SeaMonkey :: Session Restore, defect)

Description

[Antti29]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1

This happens when tabs or windows have been restored, both after a planned browser shutdown and a crash. After the restore, whenever I open a new browser window, the setting "display on new window" is IGNORED and a blank page is displayed instead. If I close all my windows and start anew, the setting works as intended. The setting of "display on new tab" always works. This happens on both my 32-bit XP and 64-bit Win7, and has been around in SeaMonkey since I can't remember when.

Reproducible: Always

Steps to Reproduce:
1. Open browser, open either a few windows or a few tabs
2. Shutdown/crash
3. Open browser and restore the session
4. Open new browser window

Actual Results:  
The new window defaults to blank page, ignoring the setting "display on new window"

Expected Results:  
Open whatever I have in the setting (in my case, my home page)

Comment 1

[Philip Chee]

It might be an extension that isn't fully compatible with SeaMonkey 2.1
Please restart SeaMonkey in safe mode: Help->Restart with add-ons disabled. And retest.

Comment 2

[Antti29]

Nope, just as I thought, didn't make any difference. As I said, the bug has been there quite a while, most probably since the 1.x branch, so it's not a 2.1 issue. I was only hoping it would be fixed for 2.1 and when it wasn't, I decided to report it.

Comment 3

[Philip Chee]

We didn't have Session store or restore in the 1.x branch. I'll ask Misak our Session Restore person.

Comment 4

[Antti29]

Ok, my mistake. I'll name it a 2.x issue then :)

Comment 5

[Rich Gray (:rbgray)]

I've often seen this kind of thing after a change in Add-ons Manager requires a reboot.  It is as if the Home Page setting gets lost (even though it is still there correctly.)  Can't reproduce it right now, but will try (tomorrow?) under 2.2 if I get half a chance.  Does seem like it started when Session Restore came into being.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1

Comment 6

[Rich Gray (:rbgray)]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110704 Firefox/5.0 SeaMonkey/2.2

I don't generally use sesison restore, but add-on changes like this will trigger loss of home page.

Steps to reproduce:

1. set a home page to make sure established
2. close windows
3. Tools > Add-ons Manager > Appearance
4. Enable a different theme than the one you're running.
5. Click Restart Now - SeaMonkey will restart and restore the Appearance pref page
6. Open new browser windows - they open on the assigned home page
7. Close all browser windows
8. Open a new browser window - it opens blank
9. Open additional windows - they open on the home page

7-9 is repeatable.  The first browser window opens blank, successive windows get the home page.



Expected results:

Interestingly, if I quit SM  & start it again, the home page opens and does not get lost on opens and closes as in 7-9 above.  I'm guessing it is because this restart does not involve a session restore.

platform to all/all

Comment 7

[Rich Gray (:rbgray)]

Ooops, Expected results:

The blank window in the above sequences should always be the home page (as specified by the preferences.)

I confirm Antti29's sequence with the additional step 3.5 of first closing the restored windows.

Status > New

Comment 8

[Antti29]

Just to update; the problem still persists in the new 2.4 version.

Comment 9

[Antti29]

An update: I accidentally found that if I open the new window from the File menu, or click Ctrl+N, it defaults to whatever is in the setting (i.e. works as intended). It is only when I open the SeaMonkey executable via a shortcut that the setting fails after a session restore.

Therefore a usable workaround is to add the parameter "-new-window your_home_page_here" to the shortcut. However it would be nice to have a setting that works :)

So anyone who might have tried to reproduce the bug and only opened the new window from the program itself might not have witnessed the behaviour I'm seeing.

Comment 10

[Tim Taubert [:ttaubert] (inactive)]

I think this could just have been fixed by bug 893061 in Firefox.

Comment 11

[[e-mail]]

(In reply to Tim Taubert from comment #10)
> I think this could just have been fixed by bug 893061 in Firefox.

Wrong product?

(In reply to Antti29 from comment #9)
> It is only when I open the SeaMonkey executable via a shortcut
> that the setting fails after a session restore.

Launching the SeaMonkey executable always executes the "Display on browser startup" setting. (Note: if this is set to "Restore previous session" and the previous session has already been restored, then you just get a blank window).

Pressing Ctrl+N depends on whether you already have a browser window open. If you don't, then it executes the "Display on browser startup" setting. If you do, then it executes the "Display on new window" setting.

Comment 12

[Antti29]

(In reply to [e-mail] from comment #11)
> Launching the SeaMonkey executable always executes the "Display on browser
> startup" setting. (Note: if this is set to "Restore previous session" and
> the previous session has already been restored, then you just get a blank
> window).
> 
> Pressing Ctrl+N depends on whether you already have a browser window open.
> If you don't, then it executes the "Display on browser startup" setting. If
> you do, then it executes the "Display on new window" setting.


This makes sense, in a way, and it certainly explains the behaviour I reported. That isn't to say, however, that this is the correct behaviour; I think the best thing to do here is to check if the session is restored, and if it is, execute the "Display on new window" functionality. After all, the actual use case here is "opening a new window" and not session restore.

I can't speak for everyone but this really hinders the shortcut usage. The workaround I presented earlier does work, but it's still a workaround and those are seldom recommended.