527799 - Session restore leads to minimized windows under some circumstances

Status: RESOLVED DUPLICATE of bug 476558

(Firefox :: Session Restore, defect)

Description

[Mike Hommey [:glandium]]

Attachment: broken sessionstore.js file

In some cases, which are not understood yet, when the session restore screen comes up and the user chooses "Restore", everything is restored, but in a zero-sized window, which is basically unusable.

Interestingly, this doesn't happen in all cases where firefox crashes or is killed. But once you have a broken sessionstore.js and copy it back for further testing, it is reproducible all the time. I'm attaching a sessionstore.js file here, that is known to break. The session is courtesy of a Debian user. (For that matter, I verified this is reproducible with a stock Firefox 3.5.x)

What is interesting is that removing the recentCrashes variable at the end of the file makes the session restored properly (but not asked for).

Comment 1

[Mike Hommey [:glandium]]

The problem seems to lie in "sizemode":"minimized" in the sessionstore. It seems restoring a minimized window doesn't restore it in a proper mode. Also note that I too had this bug on my laptop, and I absolutely never minimize my windows (I have a workspace dedicated to browsing) so there may be another bug about the session store wrongly storing this information.

Comment 2

[Mike Hommey [:glandium]]

Okay, the window *is* actually minimized, and with a proper window manager, you can get it back.

But I'm pretty sure I never minimized my window :-/

As we say in french, when in doubt, abstain, so let's unconfirm this bug and change its title...

Comment 3

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #2)
> Okay, the window *is* actually minimized, and with a proper window manager, you
> can get it back.

I was going to say something to that effect :)

If we're setting sizemode:"minimized" when it shouldn't be, that's a problem. If you can reproduce that and reduce to reliable steps to reproduce, please let us know and make sure to include information (like what window manager, exact version)

Comment 4

[Mike Hommey [:glandium]]

So far, I've had problems with awesome 3.4 because I basically have no taskbar because of a bug when having the panel vertically. The Debian user who provided the sessionstore.js file is using pwm, and confirmed the window was minimized after restore but definitely not before, and another user, who still has to confirm his sessionstore contains "sizemode":"minimized", is using fvwm, and reported the window was not in the taskbar.

Comment 5

[Mike Hommey [:glandium]]

FYI, the user under fvwm has another problem that looks similar to bug 520178 (offscreen window).

OTOH, on my awesome setup, when I willfully minimize the window and kill firefox, it doesn't restore minimized (and the sessionstore doesn't contain sizemode:minimized). There must really be something wrong with the detection of minimized windows...

Comment 6

[Mike Hommey [:glandium]]

 found an accurate way to reproduce:
- check that sizemode is normal or maximized in the sessionstore.js (it also happens that it is wrongly set to minimized after a session restore; in such case, just go to some web page in the current session, it stores a good value, then, from what i can see)
- kill -9 the firefox-bin process
- check the sessionstore.js file again: sizemode is minimized.

Comment 7

[Mike Hommey [:glandium]]

The procedure in comment 6 doesn't work with metacity, so this is dependent on the windows manager.

Comment 8

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

FYI when you kill the process will have an effect on what's stored in sessionstore.js. If you kill it before it's written the new data, then you might not see it when you restart Firefox. E.g. minimize a window, do something in another, restore and kill - if you killed before the window restored state was saved, then we'll still have sizemode:minimized in the file. We have a pref to control how often we write this file (default is 10s). See also bug 524745 (which describes a similar problem on Windows).

That's not to say that the problem isn't real, just that crash recovery isn't perfect. We do our pretty well though. What I'd be more concerned about is if this is reproducible under normal quitting conditions.

Comment 9

[Mike Hommey [:glandium]]

Note I *never* minimized the window in the process. I only started firefox, verified the content of sessionstore, killed firefox, and checked the sessionstore file again. Nothing more.

Comment 10

[u279076]

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a3pre) Gecko/20100309 Minefield/3.7a3pre

Reporter, is this reproducible on a more recent build?  Can you try to reproduce using Firefox 3.6 then again with the latest nightly and report your results.

Thanks.

Comment 11

[Mike Hommey [:glandium]]

AFAICS, it is not reproducible on 3.6.

Comment 12

[Mike Hommey [:glandium]]

Actually, it still happens on 3.6 :-/

Comment 13

[Mike Hommey [:glandium]]

Also happens with Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a3pre) Gecko/20100310 Minefield/3.7a3pre

(taken from http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64/1268231570/firefox-3.7a3pre.en-US.linux-x86_64.tar.bz2)

Comment 14

[Mike Hommey [:glandium]]

It appears this could be either a gtk/gdk bug or a window manager bug, because by putting a breakpoint on nsWindow::SetSizeMode, i see notification of GDK_WINDOW_STATE_ICONIFIED up the call stack when switching desktop, and while xprop doesn't show an Iconic WM_STATE.

Comment 15

[Mike Hommey [:glandium]]

So, the problem is much more general than a few window managers. I was actually able to reproduce the problem with metacity (IOW, the default gnome WM).

It is actually very simple to reproduce:
- Open firefox
- Open a terminal
- Put both in a different workspace
- Switch to the workspace containing firefox
- open a tab (this will trigger a sessionstore write in a few moments)
- switch to the workspace containing the terminal
- from the terminal, check sizemode in sessionstore.js after it is updated, it is minimized.

The root of the problem is that, as I wrote in comment 14, Gdk emits a GDK_WINDOW_STATE_ICONIFIED window state event when switching workspace. I verified this happens on a small gtk/gdk testcase (a slightly modified hello world from the gnome documentation)

So, while the problem may well be in gdk, the way firefox uses this information is problematic.

Note that another somehow related problem appears with tiling window managers with the session store, because it stores the window size, while the tiling window manager may open the window with a different size when starting, depending on the other windows on the screen. In such case, firefox doesn't fill its window space properly.

All in all, is window information that important for session store ? On Unix, at least, window placement is a matter of the window manager, why should the application keep trace of where it was ?

Comment 16

[Mike Hommey [:glandium]]

> All in all, is window information that important for session store ? On Unix,
> at least, window placement is a matter of the window manager, why should the
> application keep trace of where it was ?

This is especially troubling in case of crashes, because you get a window with the session restore screen, select restore, and the window gets iconified/moved/whatever.

Comment 17

[zug_treno]

Related to/duplicate of Core bug 476558?

Comment 18

[Mike Hommey [:glandium]]

Indeed.