348429 - 'Message Display: in new window/in same window' does not work.

Status: REOPENED

Description

[Michael Graubart]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.6) Gecko/20060806 SeaMonkey/1.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.6) Gecko/20060806 SeaMonkey/1.0.4

In SeaMonkey Preferences, one can choose whether to display each successive received message in a new window or in the same window: 'Help' says 'When opening messages, display them in: Here you can choose if you want to reuse a message window for the next mail or if you want to open a new one for each. But in fact whichever setting is chosen, successive messages are always displayed in the same window.

Reproducible: Always

Steps to Reproduce:
1. Download several e-mails.
2. In 'preferences' — Message Display, select 'in new window'.
3. If this involved changing the setting, quit SeaMonkey and restart.
4. In main Mail window, click on several messages in turn.

Actual Results:  
Only the last-clicked message is displayed. There are no other open windows behind the last.

Expected Results:  
Each of the clicked messages should be displayed in its own window, all of them open but behind the last one.

eMac G4 (PPC), OS X 10.4.7. Classic theme.

Comment 1

[Michael Graubart]

This bug is still present, both in SM 1.1.2 and in the trunk build.

Comment 2

[Serge Gautherie (:sgautherie)]

Can you reproduce with SeaMonkey v1.1.9 ?
Can you reproduce with SeaMonkey v2.0a1pre ?

Comment 3

[Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention)]

No reply to comment #2 in 2⅔ years => INCOMPLETE.

This bug may be REOPENED after supplying the requested information.

Comment 4

[Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention)]

P.S. Of course, replace 1.1.9 by "the latest stable version" (currently 2.0.10) and 2.0a1pre by "the latest nightly" (currently 2.1b2pre).

Comment 5

[Michael Graubart]

Apologies! I somehow missed Comment #2. The bug is still present in SM 2.0.12pre, but as my computer is a Mac G4 (PPC) with OS 10.4.11, I cannot try SM 2.1... because this does not work on my system.

Comment 6

[Philip Chee]

Hmm Can't reproduce on 2.0.12pre or 2.1b2pre on windows. Do you have some incompatible extension installed? Try starting SeaMonkey in safe mode (not sure how to do this in OSX - you may have to open a terminal window and do it from there).

Comment 7

[Michael Graubart]

I started my computer in safe mode (held down 'Shift'). The bug is still there: I set Prefs. to open e-mails in new windows, but if I open an e-mail from the Mail window and then open a second one, only the second one is then open and visible.

NB: Computer G4 (PPC), OS X 10.4.11.

Comment 8

[Philip Chee]

Please start *SeaMonkey* in safe mode not your *computer* thanks. See the following for instructions on how to do this.

<http://kb.mozillazine.org/Safe_mode#Mac_OS_X>

Comment 9

[Michael Graubart]

Thank you, Philip, for the instructions. The behaviour is still exactly the same when in Safe Mode.

Comment 10

[Philip Chee]

Hmm. I don't have a Mac. This might be a Mac specific issue. CC stefanh as he has a Mac.

Comment 11

[Stefan [:stefanh]]

This seems to work fine for me with 2.0.10 (snow leopard). I changed the pref so new messages opens in a new window and double-clicked a few messages in the main mail window. All messages opened in a new window.

Comment 12

[Rich Gray (:rbgray)]

iBook G3 OS X 10.4.11  SeaMonkey 2.0.11   Tried to launch in safe mode and got serious strangeness:

/Users/rich
~$ /applications/seamonkey.app/contents/macos/seamonkey-bin -safe-mode
CGContextBeginPath: invalid context
CGContextAddArc: invalid context
CGContextClosePath: invalid context
CGContextSetRGBFillColor: invalid context
CGContextDrawPath: invalid context
CGContextFlush: invalid context
CGContextBeginPath: invalid context
CGContextAddArc: invalid context
CGContextClosePath: invalid context
CGContextSetRGBFillColor: invalid context
CGContextDrawPath: invalid context
CGContextFlush: invalid context
www.bugzilla.ceamonkey.orgdddkdkkasd;glkjsd;flgj;sdlfkgj;^H^H^H

OS X did not seem to think SeaMonkey was even running!  The dock icon did not indicate it and cmd-TAB did not offer SM as a running app.  Terminal.app held the menu bar and when I tried to type into the SM location bar, Terminal got the characters.  Killed SM by hitting ctrl/C.  Tried again adding an & to the command to try to background SM, but I got pretty much the same behavior.  

However, I was able to navigate to Mailnews and open multiple e-mails and they each opened in their own windows so I guess that's a strange WFM.  Running non-safe mode also WFM, without the strangeness.

Comment 13

[Michael Graubart]

Re Comment #11: If I open a message and then single-click another in the main mail window, just the second one remains open. If I open a message and then double-click another in the main mail window, two copies of the second are open, but no longer the first. If I select several messages simultaneously in the main mail window and double-click one of them, I get two copies of that one, but no other. BUT if I open one message, then depress 'Command' and double-click on another, both are open, the first one in duplicate.

Does this constitute the correct functioning? Does it say anywhere that one has to depress 'Command'?

Comment 14

[Philip Chee]

[Just speculating wildly here]
Stefan, are there any Mac system settings for mouse clicks like the mac click-to-hold stuff we were discussing in some other bug. Perhaps something was set to a non-default state?

Michael: Do you have some mouse gesture extension or smooth scrolling extension installed in SeaMonkey?

Comment 15

[Michael Graubart]

No, nothing of the kind, Philip.

Comment 16

[Karsten Düsterloh]

The prefs in question are mailnews.reuse_message_window, which should be false here, and mailnews.open_window_warning, which usually is 10.

Michael, what does about:config say about those?

Comment 17

[Michael Graubart]

Karsten, 'reuse...' has 'user set — boolean — false', and 'open...' has 'default — integer — 10'. So both seem to be OK.