The default bug view has changed. See this FAQ.

Hang when quitting SeaMonkey if "Always clear my private data when I close SeaMonkey" is combined with "Ask me before clearing private data"

VERIFIED FIXED in seamonkey2.1final

Status

SeaMonkey
General
--
critical
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: Michal Urban, Assigned: neil@parkwaycc.co.uk)

Tracking

({hang, regression})

Trunk
seamonkey2.1final
x86
All
hang, regression

Firefox Tracking Flags

(blocking-seamonkey2.1 final+)

Details

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11) Gecko/20110209 Firefox/ SeaMonkey/2.1b2
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11) Gecko/20110209 Firefox/ SeaMonkey/2.1b2

With "Always clear my private data when I close SeaMonkey" preference checked, SM 2.1b2 crashes upon closing. When restarted, clear data dialog appears again and works when clicked.

Reproducible: Always

Steps to Reproduce:
1. Check "Always clear my private data when I close SeaMonkey" in preferences
2. Check also "Ask me before clearing private data"
3. Close SeaMonkey
Actual Results:  
Browser hangs with the clear data dialog unresponsive.

Expected Results:  
Clear data dialog should respond to clicking an close browser normally.

Comment 1

6 years ago
When SeaMonkey crashes did you allow the crash reporter to send a crash report to Mozilla? If so go to about:crashes. There should be a list of clickable links to the crash reports in most-recent to oldest order.
(Reporter)

Comment 2

6 years ago
More testing revealed that the exit hang only occurs when the "Ask me before clearing private data" box is checked. When it's clear, browser quits normally.

Regarding crash log, here is what happens:

Upon quitting, only Clear Private Data dialog remains and is unresponsive (beach ball, also see screen shot). There is no complete crash which would invoke Mozilla crash reporter.

When I Force Quit SeaMonkey, Apple's crash reporter kicks in and shows info attached in a log file.

about:crashes is empty. Is there a way of enabling it somewhere?
(Reporter)

Comment 3

6 years ago
Created attachment 514787 [details]
SeaMonkey hangs when clearing private data
(Reporter)

Comment 4

6 years ago
Created attachment 514788 [details]
Info from Apple crash reporter
Attachment #514788 - Attachment mime type: application/octet-stream → text/plain

Comment 5

6 years ago
Without symbols from the mozilla symbol server the information from the apple crash reporter is useless.

Alternative ways to get a stacktrace from OSX:

https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report#Mac
(Reporter)

Comment 6

6 years ago
I may look into getting stack trace, however I'm wondering if anybody is able to replicate this issue? It should be easy - load SM 2.1beta, check "always clear" and "ask me" in preferences and close the browser...

I'll try to disable add-ons to see whether they interfere with this.
(Reporter)

Comment 7

6 years ago
I get the same behaviour with all Extensions disabled.

Comment 8

6 years ago
Open the Task Manager (or whatever it's called in OSX). Close SeaMonkey. Do you see one or more plugin-container processes?

Similar bugs:
Bug 449707 - Selecting "clear private data" freezes browser
" Upon closing browser, dialogue box appears to clear private data. Clicking on "Clear now" freezes the browser (FF3)"

Bug 635090 - Multiple instances of plugin-container.exe spawn when closing Seamonkey and, if installed, launches acrobat.exe

Bug 633427 - Clearing cookies launches instance of plugin-container for each plugin installed.
(Reporter)

Comment 9

6 years ago
No plugin processes are listed in Mac's Activity Monitor (or "top" in Terminal), only when I load a page with e.g. Flash plugin, I can see a "SeaMonkey plugin process".

However, this issue occurs even without any plugins loaded, with only a single blank page displayed.

I just replicated this on another machine (MacBook5,1 running OS 10.6.5), so I guess anybody with a Mac/Snow Leopard should get this. Again, it only happens when "Ask me before clearing..." is checked.

"Always clear... when I close..." functionality seems to work fine as long as "Ask me..." is clear.

Comment 10

6 years ago
The "clear plugin private data when clearing cookies" patch made it to SeaMonkey 2.1b2. I'd ask you to try SeaMonkey 2.1b1 but this will wipe your history and bookmarks. If you try to reproduce with 2.1b1, do it with a separate profile or make a backup of your SeaMonkey profile (or at least all your *.sqlite files).
(Reporter)

Comment 11

6 years ago
Tested with 2.1b1, using a new profile. Behaviour is the same (hang upon quitting), when "Ask me..." is cleared SeaMonkey closes OK. The only difference I can see is that when I Force Quit hanging 2.1b1, Apple's crash reporter doesn't come up like it did with 2.1b2.
OS: Mac OS X → Windows XP

Comment 12

6 years ago
Sorry, I'm out of ideas except for some antivirus software interfering but I heard that Macs don't have viruses or something.
(Reporter)

Comment 13

6 years ago
Thanks for your effort, Philip! No antivirus on my Mac.

As I wrote, a developer with a Mac should be able to replicate this easily - it was consistent for me on 2 machines. I found a workaround of having "Always clear" enabled without "Ask me" option acceptable.
OS: Windows XP → All

Comment 14

6 years ago
Stefan has a Mac, I'll CC him on this bug.

Comment 15

6 years ago
I can reproduce this (trunk). Hmm, could it be related to the shutdown process and that we might have reached too far there when the clear pd window appears?

Michael - have you seen this on 2.0.x?
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 16

6 years ago
2.0.x builds (currently on 2.0.12) work fine for me. I only encountered this on 2.1 betas that I tried out.

Comment 17

6 years ago
OK, thanks. Do you have any idea on when it started to happen? A regressionwindow would be valuable. If you have the time, older builds can be found at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/. It's probably best to start with the oldest releases/candidates (a1).
blocking-seamonkey2.1: --- → ?
Keywords: regression, regressionwindow-wanted

Comment 18

6 years ago
Your bookmarks and history will be broken/gone if you switch between various 2.1betas/alphas. I suggest you use a separate throwaway profile.

Updated

6 years ago
blocking-seamonkey2.1: ? → final+

Updated

6 years ago
Keywords: hang
Summary: SeaMonkey 2.1 crashes when clearing private data upon closing → Hang when quitting SeaMonkey if "Always clear my private data when I close SeaMonkey" is combined with "Ask me before clearing private data"

Comment 19

6 years ago
In nsSuiteGlue.js

167-174:
      case "places-shutdown":
        if (this._isPlacesShutdownObserver) {
          Services.obs.removeObserver(this, "places-shutdown");
          this._isPlacesShutdownObserver = false;
        }
        // places-shutdown is fired when the profile is about to disappear.
        this._onProfileShutdown();
        break;


280-285:
  // profile shutdown handler (contains profile cleanup routines)
  _onProfileShutdown: function()
  {
    this._shutdownPlaces();
    Sanitizer.checkAndSanitize();
  },

If I call Sanitizer.checkAndSanitize() when "quit-application-granted" is fired I don't hang.

Comment 20

6 years ago
I did some testing and the regression-window is obvious:

Before bug 580658 we ran _onProfileShutdown() (which calls Sanitizer.checkAndSanitize()) when  "quit-application-granted" was fired. After the changes in bug 580658, we're calling _onProfileShutdown() after "places-shutdown" is fired. After bug 580658 we didn't showed the dialog at all (bug 588651), that was fixed in toolkit by bug 580892 2010-08-27.

Builds before bug 580658 (2010-08-08 and earlier) doesn't hang when the dialog show up.
Builds from 2010-08-09 to 2010-08-27 exhibits bug 588651 (naturally)
The nightly from 2010-08-28 hangs when the dialog show up.
Keywords: regressionwindow-wanted

Comment 21

6 years ago
Michal, no need to look for a regression window - I did some testing/digging:

Before bug 580658 we ran _onProfileShutdown() (which calls Sanitizer.checkAndSanitize()) when  "quit-application-granted" was fired. After the changes in bug 580658, we call _onProfileShutdown() when "places-shutdown" is fired. After bug 580658 we didn't showed the dialog at all (bug 588651), that was fixed in toolkit by bug 580892 2010-08-27.

Builds before bug 580658 (2010-08-08 and earlier) doesn't hang when the dialog show up.
Builds from 2010-08-09 to 2010-08-27 exhibits bug 588651 (naturally)
The nightly from 2010-08-28 hangs when the dialog show up.
Keywords: regressionwindow-wanted

Comment 22

6 years ago
Created attachment 517246 [details]
Stack from hang

Here's a stack from the hang
(Reporter)

Comment 23

6 years ago
Looks like you've found the problem, I can report this:

SM 2.1 Alpha 2 worked as expected - "Clear" dialog shows up upon exit, no hang/crash.

SM 2.1 Alpha 3 is broken - no dialog on exit, seems to quit without crash though. Dialog appears upon restart.

SM 2.1 Beta 1 and 2 show dialog but hang upon quitting, have to be Force Quit.
(Assignee)

Comment 24

6 years ago
(In reply to comment #23)
> Looks like you've found the problem, I can report this:
> 
> SM 2.1 Alpha 2 worked as expected - "Clear" dialog shows up upon exit, no
> hang/crash.
> 
> SM 2.1 Alpha 3 is broken - no dialog on exit, seems to quit without crash
> though. Dialog appears upon restart.
This was bug 588651.

> SM 2.1 Beta 1 and 2 show dialog but hang upon quitting, have to be Force Quit.
(Assignee)

Comment 25

6 years ago
Note that Firefox removed the prompt in bug 469158...

Comment 26

6 years ago
We really need to relnote this for 2.1b3. Jens, if you're doing the relnotes (assumption is based upon the fact that you did it the last time), ping me if you need more info.
Keywords: relnote

Comment 27

6 years ago
fwiw, atm my only idea on solving this is to make the dialog appear earlier (when "quit-application-granted" happens).
Version: unspecified → Trunk
(In reply to comment #27)
> fwiw, atm my only idea on solving this is to make the dialog appear earlier
> (when "quit-application-granted" happens).

If that works lets do it, we need this owned and/or we will be *forced* to ship with it (not something I want to do)

Comment 29

6 years ago
(In reply to comment #28)
> (In reply to comment #27)
> > fwiw, atm my only idea on solving this is to make the dialog appear earlier
> > (when "quit-application-granted" happens).
> 
> If that works lets do it, we need this owned and/or we will be *forced* to ship
> with it (not something I want to do)

Neil, what's your opinion on this? Should we instead remove the prompt/dialog (comment #25)? Jftr, I'm unsure if I'll be able to look at this until the beginning of May (leaving for holiday in a couple of days).
(Assignee)

Comment 30

6 years ago
If we make the dialog appear earlier, we'll fail to clear history...

Comment 31

6 years ago
(In reply to comment #30)
> If we make the dialog appear earlier, we'll fail to clear history...
Ah, right - I should have noticed that.
(Assignee)

Comment 32

6 years ago
OK, so I did some debugging, and the last place you can safely spin the event loop (as from a dialog) is from the quit-application notification.
(Assignee)

Comment 33

6 years ago
Created attachment 527511 [details] [diff] [review]
Sanitizer rewrite

I had to rewrite the sanitizer so that I could prompt at quit time (while it's still safe, which is what we used to do) but still sanitise on shutdown.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #527511 - Flags: review?(stefanh)
Attachment #527511 - Flags: review?(iann_bugzilla)

Comment 34

6 years ago
Comment on attachment 527511 [details] [diff] [review]
Sanitizer rewrite

JFTR, I won't be able to look at this until I get back from my vacation.
(Assignee)

Comment 35

6 years ago
Comment on attachment 527511 [details] [diff] [review]
Sanitizer rewrite

>+    if (Sanitizer.doPendingSanitize())
Oops, doPendingSanitize returns null on success, so this needs an extra !

Comment 36

6 years ago
Comment on attachment 527511 [details] [diff] [review]
Sanitizer rewrite

One strange thing I found, in the dialog the "Download History" is disabled (either via the Tools item or the Clear Now button), yet in the pref pane it is enabled - doesn't look like we check the clearability in the prefpane.
r=me
Attachment #527511 - Flags: review?(iann_bugzilla) → review+
(Assignee)

Comment 37

6 years ago
Pushed changeset 69c0e7fa9ed8 to comm-central.

Pushed changeset ec95fc0f4b7d to releases/comm-2.0

I get the feeling I should set some sort of flag for this but I can't see one.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(In reply to comment #37)
> I get the feeling I should set some sort of flag for this but I can't see one.

You sh/could set the Target Milestone, or what where you thinking about?

BTW, does the "relnote" keyword still apply with the patches in?

Updated

6 years ago
Keywords: relnote
Target Milestone: --- → seamonkey2.1final

Comment 39

6 years ago
Michael, if you're able to verify that this is fixed, fewl free to do so - I won't have access to a mac until I'm back from vacation.
(Reporter)

Comment 40

6 years ago
@Stefan:

As I don't see any new beta/candidate build yet, I tried the today's nightly. The bug seems to be gone now - with both options checked the dialog appears and browser closes without hanging/crashing.

I'm not sure if you want to move this to VERIFIED based on the nightly, I guess I'll leave that to you.

Comment 41

6 years ago
Comment on attachment 527511 [details] [diff] [review]
Sanitizer rewrite

Thanks for testing Michael. 

Post-checkin r+, This works fine on mac now - no hang and everything seems to be cleared (assuming Ian went through the code).

Re comment #36, We shouldn't check the clearability in the prefpane (then you wouldn't be able to set the pref to clear history if you at that moment didn't had any history).
Attachment #527511 - Flags: review?(stefanh) → review+

Comment 42

6 years ago
Verifying this based on comment #40 and my own testing.
Status: RESOLVED → VERIFIED
Depends on: 711937
You need to log in before you can comment on or make changes to this bug.