Closed Bug 453304 Opened 16 years ago Closed 16 years ago

Session not restored when starting Firefox with MOZ_NO_REMOTE set

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Version:
3.0 Branch
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED DUPLICATE of bug 456895

People

(Reporter: whimboo, Unassigned)

Details

(Keywords: dataloss, regression, Whiteboard: [vista specific?]) 

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.3pre) Gecko/2008090106 GranParadiso/3.0.3pre (.NET CLR 3.5.30729) ID:2008090106

If you are running Firefox 3 or any trunk nightly build with MOZ_NO_REMOTE set, Session Restore doesn't work. The browser comes up blank and no tabs are restored. Starting Firefox normally it works fine.

This is a major issue due to the dataloss we have here. If you have to run a profile via this environment variable (e.g. for QA work) you cannot rely on Session Restore.

No idea if this qualifies for blocking1.9.1 but for us who are running tests its necessary. At least this is a regression from Firefox 2.
Flags: blocking-firefox3.1?
Whiteboard: [regression range wanted]
I run firefox with -no-remote and haven't had this problem (my restarts are usually caused by nightly updates, though). Do you have STR that work with a new profile?
Gavin, probably this is Windows only. As I know there was a change in the underlying code. Robert, you said something to me a couple of days ago. Do you have the bug number?

The script I'm using is:

> SET MOZ_NO_REMOTE=1
> "C:\Programme\Mozilla Firefox\firefox.exe" -p

It happens with older and fresh profiles.

Steps:
1. Start Firefox with the above script
2. Enable Session Restore
3. Open some tabs with content
4. Close Firefox
5. Start the script again and select the same profile

As result you see that all tabs are gone. None of the existing ones from the last session are restored.
I'm using Windows.
(In reply to comment #2)
> Gavin, probably this is Windows only. As I know there was a change in the
> underlying code. Robert, you said something to me a couple of days ago. Do you
> have the bug number?
The only change I recall was for the updater.exe and wouldn't affect this except when updating the app... Bug 437349
I'll try to find the regression window so we will have a clue which patch caused this regression.
Keywords: regressionwindow-wanted
Whiteboard: [regression range wanted]
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3pre) Gecko/2008090206 GranParadiso/3.0.3pre

WORKSFORME. I guess I don't have to ask you that... but have you tried a clean install and a new profile? Or could this be a Vista specific issue?
Whiteboard: [worksforme?]
I just tried multiple times with multiple profiles and was not able to reproduce on Vista with
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080902033133 Minefield/3.1b1pre
I can reproduce it on a totally different machine (this time a VmWare box) and with a fresh profile.
Simon and Robert, have you both run only zip builds or have you also used an installed version of Firefox? As I can see now, this only happens for the latter one. Zip builds are not affected.
I was using my daily use install which was installed with the installer and I also update using software update for testing this.
I was using zip builds. The latest installer WORKSFORME as well, though.
No idea if thats related but I have different versions of Firefox installed on both systems: Firefox 2.0.0.16, Gran Paradiso and Minefield. I'll have a test tomorrow what happens if only one installation is present.
Whiteboard: [worksforme?]
Henrik: Have you been able to narrow down the circumstances under which this behavior happens? If not, could you please check whether the file sessionstore.js exists all the time in the specific profile and whether you get any SessionStore related errors in the Error Console before quitting and after starting again (javascript.options.showInConsole being true)?

Also: Does it make a difference whether you enable/disable UAC and/or DEP?
Whiteboard: [vista specific?]
Simon, sorry for being late with my reply but the last two days I hadn't time to check again. But what I have noticed is following: I can switch between the normal start and the one where MOZ_NO_REMOTE is set and the former one restores all the tabs and the latter one not. So the session is definitely stored. Strict javascript warnings are activated but there is no error listed. Otherwise I had already mentioned those. Lets see if I can get more information next week. I can also try to reproduce it on WinXP so we can make sure if its only related to Vista or not.
Hey, I'm not familiar of what the MOZ_NO_REMOTE is supposed to do, but this bug seems to be related to the Session Restore issue I have on FF3 under XP Pro SP2 & SP3, XP Home, and Vista Basic SP1.

Here's what I've figured out so far:

Try checking your settings under Privacy for the "Always clear private data...", In my experience, on the systems it's enabled, are the installs that won't restore sessions.

Test again with Always clear private data disabled.  This should work once.  Unfortunately it appears that Firefox demands on re-enabling the "Always clear..." on my XP Pro installs and will fail to restore on the second go-round.

The only way I have found to stop this behavior permanently is to go into the options under "Always clear..." and deselect "Browsing History".
Prime, this is another issue and I don't know if there is already an existing bug about that issue.

Simon, as what I can see the sessionstore.js is never touched when I use MOZ_NO_REMOTE. During start-up there is no read action and opened tabs aren't saved on shutdown. I can run the script as admin but that doesn't change anything. Still the same behavior. DEP is only active for special applications (default setting). Do I have to enable it for each application but exclude it for Firefox?
Simon, I've already sent a message to you with a sessionstore related issue. I believe the exception I'm able to see is related to this problem. It only occurs in that mode.

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIShellService.isDefaultBrowser]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: delayedStartup :: line 874"  data: no]

http://hg.mozilla.org/mozilla-central/annotate/969757f7a831/browser/base/content/browser.js#l1029
(In reply to comment #15)
> The only way I have found to stop this behavior permanently is to go into the
> options under "Always clear..." and deselect "Browsing History".

That's bug 398817.

(In reply to comment #16)
> Simon, as what I can see the sessionstore.js is never touched when I use
> MOZ_NO_REMOTE. During start-up there is no read action and opened tabs aren't
> saved on shutdown.

If the file isn't read at all, that means that either you've set Firefox to not resume your session or that Firefox isn't able to find the file in the first place. Considering the exception from comment #17, this might well be the latter (in which case this is no Session Restore specific bug at all).

BTW: I haven't been able to find a bug related to the isDefaultBrowser failure, either, so please file a new one and make it block this bug.
Depends on: 456895
(In reply to comment #18)
> If the file isn't read at all, that means that either you've set Firefox to not
> resume your session or that Firefox isn't able to find the file in the first
> place. Considering the exception from comment #17, this might well be the
> latter (in which case this is no Session Restore specific bug at all).

I'll have a test with process monitor tomorrow to see if there is any access or not to the file. sessionstore.js is located inside the profile so it has to be found. Starting without MOZ_NO_REMOTE the file is loaded on start-up and saved on shutdown. 

> BTW: I haven't been able to find a bug related to the isDefaultBrowser failure,
> either, so please file a new one and make it block this bug.

Done.
(In reply to comment #19)
> I'll have a test with process monitor tomorrow to see if there is any access or
> not to the file.

Oh, I thought you'd already done that. Guess by "the file isn't read at all" you only meant that the session wasn't restored, then. If the file's actually accessed by Firefox during startup, this bug is a DUPE of bug 456895 (all kinds of stuff in delayedStartup being broken by the shell service error). :-/
Sorry Simon, that it was a confusing comment. I did some investigations with the Process Monitor:

1. The file sessionstore.js is read as you can see in the following:

firefox.exe	8104	ReadFile	D:\Skupin\Anwendungsdaten\Firefox-test\sessionstore.js	SUCCESS	Offset: 0, Length: 819, Priority: Normal
firefox.exe	8104	ReadFile	D:\Skupin\Anwendungsdaten\Firefox-test\sessionstore.js	END OF FILE	Offset: 819, Length: 1.024
firefox.exe	8104	CloseFile	D:\Skupin\Anwendungsdaten\Firefox-test\sessionstore.js	SUCCESS	

2. Closing Firefox doesn't open this file (there is no recorded data set)

Because of the latter issue I think we should keep this bug open as depending on bug 456895. Probably also other issues can affect us here.
Alright, so the issue is that delayStartup is interrupted and never gets to the point where SessionStore is actually initialized (sessionstore.js is read by the separate SessionStartup component).

(In reply to comment #21)
> 2. Closing Firefox doesn't open this file (there is no recorded data set)

That's the logical consequence of SessionStore never having been initialized. If you unpack browser.jar, modifiy the offending line to only read |if (false) {| instead of |if (shouldCheck && ...) {| and then repack browser.jar, you should see that SessionStore is working as expected.
Status: NEW → RESOLVED
Closed: 16 years ago
No longer depends on: 456895
Flags: blocking-firefox3.1?
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.