Closed Bug 1490059 Opened Last year Closed 2 months ago

Firefox not killed properly when exiting the GNOME session

Categories

(Core :: Widget: Gtk, defect, P5)

62 Branch
Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox71 --- fixed

People

(Reporter: bigon, Assigned: bigon)

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180905224245

Steps to reproduce:

Open firefox in a GNOME (3) session
Exit the session without quitting firefox
Reopen session
Reopen firefox


Actual results:

Firefox thinks it has died and is displaying the sorry page


Expected results:

Firefox should have been stopped properly and should display the default page
It's not completely clear to me if it's the fault of GNOME or the fault of firefox here (shouldn't firefox somehow register in the session to know when the session will be exited?)
Is this upstream Firefox? Or did you install a package from your distribution? Which distribution?
It's firefox from debian, I cannot give a precise version since this is happening for years
Putting gnome-session in debug mode, I got this at reboot/closing of the session:


sep 11 12:45:43 valinor gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Set properties from client '0x7fe9ec003390 [10599c4ba03936950c153666274371173400000016230065]'
sep 11 12:45:43 valinor gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient:   RestartCommand = '/usr/lib/firefox/firefox' '--sm-client-id' '10599c4ba03936950c153666274371173400000016230065'
sep 11 12:45:44 valinor /usr/lib/gdm3/gdm-wayland-session[1618]: gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Client '0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]' received SaveYourselfDone(success = True)
sep 11 12:45:44 valinor gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Client '0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]' received SaveYourselfDone(success = True)
sep 11 14:09:45 valinor /usr/lib/gdm3/gdm-wayland-session[1618]: gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Client '0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]' received InteractRequest(Dialog)
sep 11 14:09:45 valinor /usr/lib/gdm3/gdm-wayland-session[1618]: gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: xsmp_interact ('0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]')
sep 11 14:09:45 valinor /usr/lib/gdm3/gdm-wayland-session[1618]: gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Client '0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]' received InteractDone(cancel_shutdown = False)
sep 11 14:09:45 valinor /usr/lib/gdm3/gdm-wayland-session[1618]: gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Client '0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]' received SaveYourselfDone(success = True)
sep 11 14:09:45 valinor gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Client '0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]' received InteractRequest(Dialog)
sep 11 14:09:45 valinor gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: xsmp_interact ('0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]')
sep 11 14:09:45 valinor gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Client '0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]' received InteractDone(cancel_shutdown = False)
sep 11 14:09:45 valinor gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Client '0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]' received SaveYourselfDone(success = True)
sep 11 14:09:46 valinor /usr/lib/gdm3/gdm-wayland-session[1618]: gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Client '0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]' received SaveYourselfDone(success = True)
sep 11 14:09:46 valinor gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: Client '0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]' received SaveYourselfDone(success = True)
sep 11 14:09:51 valinor /usr/lib/gdm3/gdm-wayland-session[1618]: gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: xsmp_stop ('0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]')
sep 11 14:09:51 valinor gnome-session-binary[1623]: DEBUG(+): GsmXSMPClient: xsmp_stop ('0x7fe9ec003390 [firefox 10599c4ba03936950c153666274371173400000016230065]')

As you can see firefox is properly registered using SM protocol and at shutdown
* and at shutdown, SaveYourselfDone and Die are sent by gnome-session. Firefox seems to reply with a SaveYourselfDone

So, if I understand properly everything looks fine...
MMmh so with both firefox and thunderbird, I get a message from gnome-shell telling that there is something preventing the closing of the session, so it is working.

I see in the nsNativeAppSupportUnix::DieCB() function that it's calling a Quit() method with "eForceQuit", is that expected?
Reproducible.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180905224245

I am placing this bug in Firefox: Session Restore 
If this component is not appropriate please feel free to change it.
Thanks.
Status: UNCONFIRMED → NEW
Component: Untriaged → Session Restore
Ever confirmed: true
OS: Unspecified → Linux
Component: Session Restore → Widget: Gtk
Product: Firefox → Core
Has anything changed in 63?

Because now every time I'm trying to shutdown/reboot/logout gnome-shell is telling me that firefox is preventing the session to be closed and firefox is opening the dialog asking be if I want to close all my tabs.

But this is not yet the desired behavior I guess, in case of shutdown/reboot/logout firefox should just close everything as fast as possible except if a site is explicitly preventing to close the tab
I've been able to test this change in behavior between 62 and 63 on Fedora as well, the new behavior is awful if you ask me.
Ping? The new behavior blocks the closing of the user session for several seconds (if not completely). Should an other bug be opened for that? My initial bug report and that new behavior seems to be closely related but I might be wrong
Hello

I've been able to reproduce this in XFCE as well if you are NOT saving the X11 session (using the SM protocol)

If I'm saving the session, at the next login firefox starts up with all the tabs open as if nothing happened
As you can see, gnome-session (https://gitlab.gnome.org/GNOME/gnome-session/blob/master/gnome-session/gsm-xsmp-client.c#L402) is calling the following X11 SM function when closing the connection, note that in this case, save_type is != SmSaveLocal (so SmSaveGlobal or SmSaveBoth):

                default:
                        /* Logout */
                        if (!allow_interact) {
                                SmsSaveYourself (client->priv->conn,
                                                 save_type, /* save type */
                                                 TRUE, /* shutdown */
                                                 SmInteractStyleNone, /* interact style */
                                                 TRUE); /* fast */
                        } else {
                                SmsSaveYourself (client->priv->conn,
                                                 save_type, /* save type */
                                                 TRUE, /* shutdown */
                                                 SmInteractStyleAny, /* interact style */
                                                 FALSE /* fast */);
                        }
                        break;

For what I can see is that in almost all cases, SmsSaveYourself will be called with shutdown == true, fast == false and SmInteractStyleAny)

IMVHO:

1) the SmcInteractRequest() should only be called if there is really something that will require user interaction, if I'm not wrong the function is called in all cases even if there is nothing to ask the user. That should save some CPU cycle.

2) If shutdown == true and style is SmInteractStyleAny (the else part of the code above), the only reason you want to interact with the user is to ask the user if you are allowed to close a tab where the site is explicitly asking to prompt the user.

Nobody? I'm quite surprised that I'm the only one impacted by this...

Version: 62 Branch → 66 Branch
Version: 66 Branch → 67 Branch
Version: 67 Branch → 68 Branch
Version: 68 Branch → 69 Branch

If you still see this please don't update the version. We assume the issue is continues beginning from the original reported version.

Version: 69 Branch → 62 Branch
Attached patch firefox_session.patch (obsolete) — Splinter Review

Hello,

Looking again at this, gnome-session in GNOME 3 only calls SmsSaveYourself with save_type = SmSaveGlobal when closing the session.

That means that "obsServ->NotifyObservers(didSaveSession, "session-save", nullptr);" is never called and the interaction is forced

Why is firefox doing a difference between SmSaveGlobal and SmSaveLocal/SmSaveBoth?

Isn't the attached patch the solution to this bug?

The documentation (https://www.x.org/releases/X11R7.7/doc/libSM/SMlib.html#SaveYourselfProc) states:

If save_type is SmSaveLocal the client must update the properties to reflect its current state. Specifically, it should save enough information to restore the state as seen by the user of this client. It should not affect the state as seen by other users. If save_type is SmSaveGlobal the user wants the client to commit all of its data to permanent, globally accessible storage. If save_type is SmSaveBoth the client should do both of these (it should first commit the data to permanent storage before updating its properties).

Some examples are as follows:

If a word processor were sent a “Save Yourself” with a type of SmSaveLocal it could create a temporary file that included the current contents of the file, the location of the cursor, and other aspects of the current editing session. It would then update its SmRestartCommand property with enough information to find this temporary file.

If a word processor were sent a “Save Yourself” with a type of SmSaveGlobal it would simply save the currently edited file.

If a word processor were sent a “Save Yourself” with a type of SmSaveBoth it would first save the currently edited file. It would then create a temporary file with information such as the current position of the cursor and what file is being edited. Finally, it would update its SmRestartCommand property with enough information to find the temporary file.

So I'm not too sure why you only want to do that for SmSaveLocal (or SmSaveBoth)

With modern desktop, the difference between SmSaveGlobal and SmSaveLocal has
faded, moreover the libSM documentation states that: "If save_type is
SmSaveGlobal the user wants the client to commit all of its data to permanent,
globally accessible storage.", it's difficult to understand why firefox
wouldn't save its session state in that case.

gnome-session is using SmSaveGlobal when closing the user session, that means
that under GNOME, firefox blocks the closing of the session and complains that
it has crashed on restart.

With this patch, "session-save" is sent in all cases, that means that the two
issues noted in the original bug are fixed.

Attachment #9090765 - Attachment is obsolete: true

Thanks for the patch. Please request check-in by adding checkin-needed to Keywords field.

Assignee: nobody → bigon
Flags: needinfo?(bigon)
Flags: needinfo?(bigon)
Keywords: checkin-needed

Pushed by dvarga@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/22f474cf97b3
Also call "session-save" in the SmSaveGlobal case r=stransky

Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
You need to log in before you can comment on or make changes to this bug.