Closed Bug 1244312 Opened 8 years ago Closed 8 years ago

Opening Composer or Download Manager causes top menu and window sizing & closing options to disappear for all SeaMonkey windows

Categories

(SeaMonkey :: General, defect)

SeaMonkey 2.39 Branch
Unspecified
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: eric, Unassigned)

Details

Attachments

(9 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
Build ID: 20151103192036

Steps to reproduce:

Running Mac OS X 10.11.2 El Capitan, Mac Pro (Early 2008)
My SeaMonkey was configured to open Browser and Mail & Newsgroups windows at start up.
Subsequent opening of Composer or Download Manager...


Actual results:

Subsequent opening of Composer or Download Manager causes the top menu to disappear on all SeaMonkey windows.  The Composer or Download Manager windows have no red yellow green buttons to manage open windows.Those two windows cannot be resized or closed but they can be moved.


Expected results:

The menus aren't merely hidden.  They just aren't available, not even by moving the cursor to the top of the screen and waiting for any drop down menu to drop down.
I created a new profile and the problem does not occur.  During troubleshooting, I checked for Composer to open at start up along with browser and e-mail window.  Now the problem is full time... There is no way I can get to Preferences in the menu to uncheck the option of starting Composer at start up.  I'm quite disabled in what I can try.  
(This is the worst bug ever.
Before this problem developed, I noticed that sometimes SeaMonkey would not close from the close command in the SeaMonkey menu to the left of the File menu.  Had to use OS X force quit.)
Comment on attachment 8713842 [details]
Finder_menu_where_browser_menu_ought_to_be.png

Screen shot #4
Finder menu where SeaMonky browser menu ought to be.
Screen shot #1
Browser OK before opening composer
Screen shot #2
Composer opened, causing top menu to disappear
Screen shot #3
Desktop background image where browser menu ought to be.
OK
  Browser
  Mail and Newsgroups
    Compose e-mail
  Address Book
  Data Manager
  Password Manager
  Add-ons Manager

Not OK
  Composer
  Download Manager
MAC for now.
OS: Unspecified → Mac OS X
CC Stefanh who has a Mac.
I can't reproduce this on 10.11.3. I opened a bunch of Composer windows and I still have a menu bar.

Eric, please provide more detailed steps on how to reproduce this. For example, what do you mean by "subsequent opening of Composer"? Do you just open many Composer windows? How do you open these windows? Do you do anything special (moving focus between the windows, launching another application etc etc) before the menu disappears?
Flags: needinfo?(eric)
More detailed steps on how to reproduce the problem:

Start SeaMonkey program
(Two windows open, Browser and Mail&Newsgroups, because that is what is configured to open in Preferences-->Appearance)

Subsequent opening of Composer means I go to the Window menu and choose Composer to open a third window. (See screen shot)
I only have to open one Composer window to lose the top menu on every window: File Edit  View...

I don't do anything else special to get this problem.

My previous list of OK and not OK programs has gotten less OK.  I can't open a Mail & Newsgroups window either without getting the same problem as opening Composer.

I have continued to use SeaMonkey without this "Composer" bug by pressing the option key when starting SeaMonkey so that it starts in Safe Mode.  Works OK but no Javascript for the browser.

I still sometimes have the problem that Quit SeaMonkey doesn't work, whether I use the menu selection or Command-Q keys.  I haven't figured out what circumstances cause Quit SeaMonkey to stop working.
(In reply to Eric Houg from comment #10)

> I have continued to use SeaMonkey without this "Composer" bug by pressing
> the option key when starting SeaMonkey so that it starts in Safe Mode. 

Thanks for the info. That it works in Safe Mode is important information. It indicates that the issue could be caused by an extension (add-on). If you disable all your add-ons (in the add-ons manager), does the issue goes away? If it does, you should be able to find the offending add-on by enabling the first in the list, then enabling the next add-on and so on.
Attached image Plug-ins disabled
I had plug-ins disabled already but that didn't help.  I still needed Safe Mode.  I noticed when responding to your suggestion, that nothing in the SeaMonkey menu (to the left of File Edit View) was working except for Services—>Services Preferences.  Had to Force Quit again.
Right, but that's not the add-on manager :-)

From the menubar, open the Tools menu and choose "Add-on Manager". I the left pane, you can see what Add-ons/Extensions, themes you have installed.
Extensions
	DOM Inspector
	Chatzilla  (disabled)
	JavaScript Debugger  (disabled)

Appearance
	SeaMonkey Default Theme
	SeaMonkey Modern  (disabled)

Plugins   You don’t have any add-ons of this type installed

I tried disabling DOM Inspector but that didn’t fix the bug, so I let DOM Inspector go back to doing whatever it does.  I think I disabled everything I could.
https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems could be of help. The hardware acceleration pref differ from firefox, though - you need to turn it off in about:config (I don't remember the pref name, but you should be able to find it if you search for it).
When starting in Safe Mode, I only checked the check box to disable

Reset toolbars and window sizes

Then the bug is gone.
Aha, OK. This kind of indicates that you have some preference or other setting affecting your toolbar. It's also clear from looking at the Composer image you posted here. For example, I can't get Composer to only show text labels instead of text+icons in the toolbar. Maybe there's some old/corrupt setting that causes this.

These settings are stored in a file which gets removed in safe mode. Now, you could try to remove the file (or move it to somewhere else) from your profile directory and see what happens. The file will be re-created, but you'll loose all your settings concerning window sizes/toolbar customization/expanded lists and so on.

The settings are stored the xulstore.json file. There's actually an old file called localstore.rdf which settings used to be saved to before the xulstore.json file was introduced. You might want to remove/move that file too.

The files are at "YourUserName/Library/Application Support/SeaMonkey/Profiles/yourProfile" (sometimes I think the profile directory can be one level higher). The profile directory name starts with a random string followed by a dot and then the profile name, like ”3ghty65jj.yourProfileName”. If you only have one profile, it’s probably called ”randomString.default”.

Remember that not doing this properly will cause problems, you might end up with a wasted profile... Just moving the files to some other location will be safe and you can put them back to the original location later if you want.
Oh, I missed a couple of things. The correct procedure is:
1) Quit SeaMonkey
2) Locate and move/remove the files
3) Start SeaMonkey (if you have multiple profiles and you're able to choose one profile at startup, choose the one without the files)
Also, another thing to try is to enable the modern theme and see what happens.
Enabling the modern theme, SeaMonkey Modern, makes the bug go away.

I know my Library folder used to be where you said it should be at MyUserName/Library but I don't see it there now in Finder.  Also I can't find the files xulstore.json or localstore.rdf by searching This Mac.  Yet I still have all my old e-mails so my SeaMonkey application data must be somewhere.
(In reply to Eric Houg from comment #20)
> Where's my Library folder?
It's hidden by default since 10.9, but you can make it appear by pressing some key combo which I don't remember offhand (but the internet will).


> Enabling the modern theme, SeaMonkey Modern, makes the bug go away
That's interesting. I don't know why, but we'll see what happens when you remove those files.
I was able to unhide my Library folder. (hidden by default since OS X 10.8)

When attempting to quit SeaMonkey, I found that its quit function was not working. Had to Force Quit.

Moved preferences file xulstore.json to a temporary hiding place.

Started SeaMonkey.  (a new xulstore.json was created automatically)

Enabled SeaMonkey Default Theme by disabling SeaMonkey Modern theme.

Found no problem with Composer or Mail & Newsgroups window sizing or menus.  No problem quitting SeaMonkey.
Update:
After more use of SeaMonkey, quitting SeaMonkey becomes a problem.  Nothing in the SeaMonkey menu (to the left of File Edit View) works except for Services—>Services Preferences.
Are top menu and window sizing & closing options visible now? I think the "quit" problem is a different issue.
Component: Composer → General
(In reply to Eric Houg from comment #0)
> Now the problem is full time... There is no way
> I can get to Preferences in the menu to uncheck the option of starting
> Composer at start up.  I'm quite disabled in what I can try.  

It is possible to change which windows open at startup, even when the Preferences dialog is not available, by browsing to about:config (and, if necessary, answering that you'll be prudent when told that "this may void your warranty").

Type "general.startup." (with both dots but without the quotes) in the Filter (or maybe Search) box. This way you'll see one Boolean preference (on a separate line) for each possible component window. AFAICT the default is true (open at startup) for the Browser and false (don't open at startup) for all others. Double-click a line to toggle the corresponding preference.

On Linux too, I have (rarely) experienced shutdown hangs, where the SeaMonkey process remains there even after I hit Ctrl+Q and confirm that I want to close all tabs. In those cases, "ps -lC seamonkey" (at a shell prompt) often tells me that the program is in "futex_wait_queue_me" state. I don't now if and how this translates to Mac OS X though. Normally, however, some minutes (yes, minutes, plural; but I have many tabs) after the last window closes, I see that total memory use drops down by a sizable amount; and then the same ps command displays only column headings, meaning that the seamonkey process has exited.

When such a hang happens (and the program doesn't exit after even a little more than the usual "wait time") the only solution is of course to kill SeaMonkey. On a Unix-like OS like yours or mine, "killall -v seamonkey" (without the quotes, at a shell prompt, and the SeaMonkey process name may or may not be slightly different on the Mac) is one possible way to do it.
(In reply to Tony Mechelynck [:tonymec] from comment #26)
> It is possible to change which windows open at startup, even when the
> Preferences dialog is not available, by browsing to about:config (and, if
> necessary, answering that you'll be prudent when told that "this may void
> your warranty").

Cool. I'll just lie when I click on "I'll be careful, I promise!"

Good tip for next time I can't get to Preferences.
(In reply to Tony Mechelynck [:tonymec] from comment #26)
> Normally, however,
> some minutes (yes, minutes, plural; but I have many tabs) after the last
> window closes, I see that total memory use drops down by a sizable amount;
> and then the same ps command displays only column headings, meaning that the
> seamonkey process has exited.

I waited 8 hours after I tried quitting SeaMonkey but it just kept on working as if I had never tried quitting.  The OS X Force Quit function doesn't say SeaMonkey is "not responding".  I'm not sure where the command line is for Mac OS X.  That's why I didn't like Linux - all that command line stuff.
This is really(In reply to Eric Houg from comment #23)
> Update:
> After more use of SeaMonkey, quitting SeaMonkey becomes a problem.  Nothing
> in the SeaMonkey menu (to the left of File Edit View) works except for
> Services—>Services Preferences.

If it's not the same sympton/problem as Bug 1234087, please file a new bug for the "quit" issue.
I would file a bug report if somebody would work on it.

Bug 1244312 -- Opening Composer or Download Manager causes top menu and window sizing & closing options to disappear for all SeaMonkey windows 
Assigned To: 	Nobody;

Bug 1234087 - On the Mac, Cmd+Q or File→Quit do nothing, even in Safe Mode, if all windows have been closed (but the menubar is still there). 
Assigned To: 	Nobody;
> I would file a bug report if somebody would work on it.

Well, I have "worked" on this bug by asking you questions in order to:
- Be able to reproduce the issue
- Figure out what could have caused the issue

It's impossible to solve a problem if you can't reproduce it. And I wasn't able to reproduce it. Then it turned out that the issue here was caused by a corrupt xulstore.json file, so I would say that this bug is resolved now.

The "quit" problem is different compared to this problem, that's why I asked you to file a new bug.
OK.  I appreciate that you did fix the problem for me.  I thought that you might have wanted to dig deeper into what went wrong in my xulstore.json file.  I also thought somebody would be officially "Assigned To:" the problem.  This was my first bug report so I'm new to this.

In about two days I will have time to narrow down what steps lead to the quit problem, and I will file a new bug.
(In reply to Eric Houg from comment #32)
> OK.  I appreciate that you did fix the problem for me.  I thought that you
> might have wanted to dig deeper into what went wrong in my xulstore.json
> file.
It's almost impossible to find out what went wrong for you. If you still have the old file, you could try and compare its content with the new file and report back. Otherwise I think we can close this as "WORKSFORME" (feel free to do it yourself, just select "RESOLVED" in the dropdown at the bottom of this page and then choose "WORKSFORME").

> I also thought somebody would be officially "Assigned To:" the
> problem.  This was my first bug report so I'm new to this.
Ah, sorry - I should have explained a bit more. This bug is still in an unconfirmed state, because no-one have been able to reproduce the problem. When you file a bug, it first gets in an unconfirmed state, then if someone confirms it, status changes to "NEW". Then someone might pick it up. Another way a bug would get confirmed is of course if a lot of people report the same issue.

> In about two days I will have time to narrow down what steps lead to the
> quit problem, and I will file a new bug.
Sounds great. One interesting thing is whether actually something happens when you try to quit SeaMonkey or the command just doesn't work. If SeaMonkey hangs, there's a handy application in  Applications > Utilities called "Activity Monitor" (https://support.apple.com/en-us/HT201464), which could be of help when trying to say something about the problem. You could for example take a sample of the SeaMonkey process after you've tried to quit SeaMonkey and the application hangs (if it does). Another key thing is if there is difference between quit by shortcut Cmd+Q, from the menu or from the dock (right-click the SeaMonkey icon in the dock and then choose quit). Also, quit behavior with a window open versus no window open is interesting.
Re the quit issue: se also Bug 1239620 (Firefox) which got resolved as wfm.
(In reply to Eric Houg from comment #28)
> (In reply to Tony Mechelynck [:tonymec] from comment #26)
> > Normally, however,
> > some minutes (yes, minutes, plural; but I have many tabs) after the last
> > window closes, I see that total memory use drops down by a sizable amount;
> > and then the same ps command displays only column headings, meaning that the
> > seamonkey process has exited.
> 
> I waited 8 hours after I tried quitting SeaMonkey but it just kept on
> working as if I had never tried quitting.  The OS X Force Quit function
> doesn't say SeaMonkey is "not responding".  I'm not sure where the command
> line is for Mac OS X.  That's why I didn't like Linux - all that command
> line stuff.

8 hours is more than enough. OK, something ought to have happened much earlier.

IIUC, the command-line terminal is called Terminal.app on Mac OS X.

(In reply to Eric Houg from comment #30)
> I would file a bug report if somebody would work on it.

If you don't file a bug, and no one else does, then you can be sure that nobody will work on it because nobody will be aware of it.

OTOH, all newly filed bugs start their life as assigned to nobody. Then, hopefully, someone (especially if he can reproduce the bug, see comment #33) will decide that he has the knowledge and the time to fix it, and start working on it. But no one is ever required to fix any bug that you or I file: see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html §1.2 for an explanation.
More info on the "Quit" issue: Bug 1230607 (see also the reference to the Apple support forums).
I started a new bug report for the "Quit" problem.

Bug 1246999 - closing the browser window opened at startup disables the SeaMonkey menu items such as Quit and Preferences. Mac OS X
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: