Closed Bug 575864 Opened 14 years ago Closed 14 years ago

message pane reappears when menu View->Layout option turned off

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(thunderbird3.1 .3-fixed)

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
thunderbird3.1 --- .3-fixed

People

(Reporter: mjd, Assigned: Bienvenu)

References

(
URL
)

Details

(Whiteboard: [gs])

Attachments

(1 file, 2 obsolete files)

fix for multiple close + open case
7.02 KB, patch
asuth
: review+
standard8
: approval-thunderbird3.1.3+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 If an item is selected in the message list, and View->Layout Message Pane is turned off so no message pane shows (this works). However, if one closes the message list window and reopens by clicking the OSX dock thunderbird icon the message list window now opens with layout message pane shown. Very irritating to have to keep turning off the View->layout option each time starting thunderbird (I use classic view layout). Reproducible: Always Steps to Reproduce: 1.select message item by single click; set to not view message pane 2.close message list window 3.open message list window Actual Results: massage pane shows for previous selected message item Expected Results: no message pane for previous selected message item. Remembering of previous selection of item is okay but the desired layout should also be remembered.
In the preferences "reading & display" I have selected open messages in a new message window.
I can confirm this. I have OS X 10.5.8 on a G4 and TB 3.1. My TB settings appear identical to yours. This was not a problem with the earlier TB. It very occasionally forgot the setting perhaps after manually editing user.js or css. It is most frustrating.
I confirm the same behavior here, and also find it deeply frustrating. I can also reproduce it simply by closing the main window with command-W and then reopening it with command-1. Before closing, no message pane; after opening, message pane. Once difference from previous reports: I have "open messages in a new tab" set in preferences.
I confirm that cmd w / cmd 1 also demonstrates this frustrating behaviour with my settings.
This has been reported on PPC and Intel Macs but are other platforms affected also?
There may be a series of preferences which are not remembered but It is not clear to me if they share a common cause. See: https://bugzilla.mozilla.org/show_bug.cgi?id=568309
A quick test of TB 3.1 rc2 indicates that it has this bug. Here is an earlier bug with what appear to be the same symptoms but a different cause: https://bugzilla.mozilla.org/show_bug.cgi?id=518345
Similar CTRL+W don't affect Windows: added pp keyword. Ludo can you confirm this on Mac ?
Keywords: pp
Status: UNCONFIRMED → NEW
Component: OS Integration → Mail Window Front End
Ever confirmed: true
QA Contact: os-integration → front-end
Hardware: x86 → All
Probably stating the obvious, but I can confirm this issue continues to occur under 3.1.1 .... Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
This bug has an unfortunate consequence which, in my opinion, is a 'major loss of function' so I request that its 'importance' be raised. Archiving the previous day's messages marks the first message for today as read. I assume that this is because the Archive function automatically highlights the next message which puts it in the message pane contrary to my wishes. I don't want message panes - I want my messages in windows only. Incorrectly removing the unread indication is a 'major loss of function'. Could this be used to increase Importance please?
I don't read a message pane, either. This function is important. Please correct this function.
status-thunderbird3.1: ? → wanted
Flags: wanted-thunderbird+
Neville: I had the same problem. My current workaround (which I intensely dislike, but not quite as much as the problem you described, and may only mesh with my particular way of using e-mail) was to go to "Preferences > Advanced > Reading & Display" and set "Automatically mark messages read > After displaying for" to 10 seconds. Like I say, this is a sucky workaround, chiefly because it means that if I go zipping through a bunch of report e-mails none of them are open for more than 10 seconds and so none are automatically marked read. This in itself is a major loss of function, so I definitely agree the importance should be raised. Hell, I'd make it a blocker for 3.1.
I did that a while ago but with 5 seconds. This is not much good if you don't either close the main window or read the message within the 5 seconds. It will eventually overcome whatever time is set. I can report that the problem still exists in TB 3.1.1 I don't have the skill to write TB code but I am getting good at hacking it if somebody can tell me what to do.
Neville: Oh, I know. Like I said, it's a sucky workaround. I also agree that it would be great if someone could at least point us in the right direction of where to look/what to look for in the code. I did a few searches of http://mxr.mozilla.org/comm-1.9.2/source/ but quickly got lost.
Followup: I also continue to see the problem in TB 3.1.1 (which installed just a few minutes ago).
I have 'invented' a hack which appears to work with TB 3.1.1. WARNING: This has been tested by me for less than 5 minutes. It is unlikely to do any serious harm but it may have to be reversed if it has unforeseen consequences. LONG INSTRUCTIONS: For the those who have not done such things before. 1 - Install http://www.codeland.org/download/download.html 2 - Quit from TB 3 - Control-click TB application and select 'Show Package Contents' 4 - Make an alias of the enclosed Contents folder - for subsequent easy access 5 - Do a Get Info on /Applications/Thunderbird.app/Contents/MacOS/chrome/messenger.jar 6 - Set JarInspector to 'open all documents like this' 7 - Double click item at 5 8 - Double click Contents 9 - Double click messenger 10 - Find (top right) 'message' 11 - Double click messageDisplay.js 12 - Cmd F to bring up Find window and then find 'function MessagePaneDisplayWidget' 13 - Change 'true' (2 lines down) to false 14 - Cmd S - to save 15 - Start TB and test. SHORT INSTRUCTIONS: 1 - Open /Applications/Thunderbird.app/Contents/MacOS/chrome/messenger.jar/messenger/messageDisplay.js 2 - Replace: function MessagePaneDisplayWidget(aBeVisible) { MessageDisplayWidget.call(this); this._visible = aBeVisible == undefined ? true : aBeVisible; } With: function MessagePaneDisplayWidget(aBeVisible) { MessageDisplayWidget.call(this); this._visible = aBeVisible == undefined ? false : aBeVisible; // Above true changed to false as per bug 575864 }
Neville: dude, you SO ROCK. Thank you. A much, much, much better workaround than mine.
Could a few more people try this please - it is not difficult to do and is low risk.
this bug is all platforms; it's just easier to do on the mac, but it's reproducible on windows. I have a suspicion that your patch would just reverse the bug, so that people who show the message pane would have it hidden following the same steps...but I'll have a quick look.
Keywords: pp
OS: Mac OS X → All
I apologise to non-Mac users. I assume that changes on other platforms would be similar. Could somebody test on Windows and Linux please. So far I have not discovered any loss of functionality on my POP only TB. I never use tabs so have not tested these. I am surprised that I can still toggle the message pane.
(In reply to comment #24) > I apologise to non-Mac users. I assume that changes on other platforms would be > similar. Oh, I wasn't referring to your patch, just that the bug was marked as OS/X-only.
I am getting lost. Does the bug exist on other platforms or is there a mistake in the original stated platform?
this bug is all platforms and operating systems; it's just easier to do on the mac, but it's reproducible on windows.
OK - thanks. I am not a Windows user and would be grateful if you could advise how to reproduce it on Windows so that I can help others.
yes, as I thought, your patch causes the opposite bug - if you are viewing the message pane, and follow the STR's, the message pane will get hidden instead of shown. Which is fine for you, but not the users who like to see the 3-pane UI.
I don't understand. What are STR's ? If I have a 3 pane view my message pane toggles on/off in the correct way.
on Windows, one way to reproduce it is to bring up the compose window from the 3-pane ui, close the thread ui, and then re-open it from the compose window using tools | mail and news. I'm not sure how the message pane visible state is supposed to persist, but it seems flawed. STR is steps to reproduce (the issue)
You are correct my patch does, unfortunately, simply reverse the bug so my existing patch is only useful to those who do not want message panes. Thanks for pointing this out. Am I correct in thinking that few Windows users will ever notice the bug?
asuth, clarkbw, what would you think of the idea of restoring the session in the case of going from 0 3-pane windows to 1 3-pane window, in addition to the startup case? I think that would fix the most common cause of this bug, and would seem to be in general the right thing to do anyway...
Fine with me.
Sorry - I don't understand: "0 3-pane windows to 1 3-pane window"
Are the cause or fix for this bug related in any way to bug 568309 ?
There is a similar patch for https://bugzilla.mozilla.org/show_bug.cgi?id=578377#c5 with the same downside as https://bugzilla.mozilla.org/show_bug.cgi?id=575864#c20 but with simple cmd F recovery.
Attached patch proposed fix (obsolete) — — Splinter Review
this makes us go through session restore when we go from 0 to 1 3 pane windows, even after startup. Fixes the collapsed message pane issue, as well as the quick find issue (if I understand the latter correctly). I'll try to write a mozmill test for this...
Assignee: nobody → bienvenu
Status: NEW → ASSIGNED
Thanks David. As far as I can tell from my tests your comment 38 patch resolves both bugs with no downside. This is what I did on my Mac. 1 - Removed both previous patches 2 - Opened /Applications/Thunderbird.app/Contents/MacOS/modules/sessionStoreManager.js 3 - Replaced: let firstWindow = !this._initialized; with: let firstWindow = !this._initialized || this._shutdownStateSaved;
Please ignore comment 39 - it failed after further tests. I will have to test further tomorrow - nearly midnight here. After several closing and opening of main window both bugs returned.
I have done further testing. All this assumes that my actions in bug 575864 comment 39 are a correct interpretation of David's patch - please say if I have got it wrong. The first time I close and open TB main window my inhibited Message Pane and Quick Filter Bar preferences are remembered but they are forgotten upon second opening and both default to visible. I assume this is more noticeable on OS X because many Mac users normally close TB windows rather than minimise them and then open TB by hitting TB Dock icon. Two close methods are commonly used (hit red button or cmd W) but, in relation to this bug, they both do the same. There are similarly 2 ways to open (hit TB Dock icon or cmd 1) and they also both do the same. Since TB has to be the 'active' application for cmd 1 to work it is rarely used as hitting the Dock icon does both automatically. The operation of the red button is under application control - like TB many applications close the window but some quit. The Dock is often nearly full and hence too much use of minimise is not popular. A satisfactory workaround (which I have only just discovered) is cmd H to hide TB main window. Repeated use of cmd H and the Dock icon honours these TB settings. I am not sure how helpful this discovery is - I will probably not remember to use it every time so my original hack will be better for me. OS X Dock icons are the most popular way to launch frequently used applications and also to open the application's default window. It appears that there is an underlying bug probably affecting all platforms but perhaps more evident on some than others. Whilst a proper fix would be preferable I am not sure if it would be worth investigating if TB can use the red button to invoke cmd H rather than cmd W. Even if this is platform specific it may appear to resolve the situation for those most affected- perhaps a temporary fix - I am happy to test a patch. Since both bug 578377 and bug 575864 appear to exhibit similar behaviour and have a common cause would it be best to combine them?
>>Whilst a proper fix would be preferable I am not sure if it would be worth >>investigating if TB can use the red button to invoke cmd H rather than cmd W. Hmmm..... invoke cmd H and stand back and watch the complaints come in from people who only want to, for example, close the main mail window and yet leave the messages they may have open in seperate windows on display. cmd H would simply hide the whole lot. Sorry but I'm voting for taking a bit more time to get a proper fix rather than some kludge that will probaly then be forgotten in the codebase and never truly fixed as the new hide behaviour would be adopted as a default.
Good point - I have never used cmd H before and had not realised that it hid all application windows.
I see that many lists of keyboard shortcuts incorrectly list cmd H as hide window rather than the correct hide application. Whilst a proper fix is always preferable investigating hiding the window rather than closing it may be useful in the short term. Restoring hidden items appears faster than closed ones so would this be a better way for TB to operate long term?
On the other hand,I was just thinking, how about if we take the gist of your suggestion to change the behaviour of red button / cmd w .... perhaps it will be quicker to introduce a new "semi-hide" behaviour that won't hide all windows whilst the bug hunting goes on ? Perhaps this is what you meant by your second reply ?
What is semi-hide? I cannot find any OS X finder controls to hide windows. Double clicking the title bar appears to minimise. There are applications which say they will hide windows but I have not investigated. I assume it must be possible to do it somehow, tab? z-index?
Sometimes I wish I were a developer and not a mere mortal consumer of code. ;-) In other words, probably best ignoring my previous mail. Going back to sit in my corner with the dunce cap as requested. ;-)
I haven't tried my patch on the mac yet. I'm still struggling to get a mozmill test working on Windows, but once that's done, I'll try it on the mac.
Attached patch proposed fix with mozmill test (obsolete) — — Splinter Review
I'll try this on the mac now, but it seems to work fine on Windows.
Attachment #459591 - Attachment is obsolete: true
Attachment #459868 - Flags: review?(bugmail)
On the mac, it seems like the third time I try to restore the 3-pane window, I lose my settings. At first glance, it looks session.json isn't getting written out sometimes when the 3-pane window is closed. And since we delete it after restoring it (or so I've been told), we end up with no session (assuming the timer hasn't fired).
Interesting that it is second for me and third for you.
this fixes the case of closing after not changing the state (e.g., which folder was selected), and adds a mozmill test for that. Giving review to asuth, but getting feedback from standard8 in case he wants to try to get it into 3.1.2
Attachment #459868 - Attachment is obsolete: true
Attachment #459902 - Flags: review?(bugmail)
Attachment #459902 - Flags: feedback?(bugzilla)
Attachment #459868 - Flags: review?(bugmail)
Comment on attachment 459902 [details] [diff] [review] fix for multiple close + open case Patch looks good and pretty low risk to me. The test is a little cargo culty though; why are you grabbing 'state'? I think you can lose that bit since you only care about the results as they affect the window.
Attachment #459902 - Flags: review?(bugmail) → review+
(In reply to comment #53) > > The test is a little cargo culty though; why are you grabbing 'state'? Oh, yeah, I shouldn't need that - I was copying part of an other test that grabbed state and a bunch of other things, and removed all of the other things except for that line...
Attachment #459902 - Flags: feedback?(bugzilla)
fixed on trunk, with the state line removed from the test: let state = mail3PaneWindow.getWindowStateForSessionPersistence(); http://hg.mozilla.org/comm-central/rev/b2b2419499ff
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 459902 [details] [diff] [review] fix for multiple close + open case getting on the 3.1.x radar (we're going to need a 3.2 flag if we keep on our 3.2 comm central 1.9.2 path)
Attachment #459902 - Flags: approval-thunderbird3.1.3?
Thanks David. I tested your comment 56 patch and it appears to be OK on my Mac. The following may be useful for Mac users who want to patch their TB now. This is what I did to a standard TB 3.1.1 install (ie after removing all previous experimental patches) 1 - Opened: /Applications/Thunderbird.app/Contents/MacOS/modules/sessionStoreManager.js 2 - Replaced: sessionFile.remove(false); With: sessionFile.remove(false); this._currentStateString = null; 3 - Replaced: let firstWindow = !this._initialized; with: let firstWindow = !this._initialized || this._shutdownStateSaved; 4 - Saved and tested.
Mac users who end up here (as far as I can tell it is less of a problem for users of other platforms) who want a fix for this before their next normal release can either follow my comment 57 instructions or download the latest nightly build from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central-trunk/ Use of a nightly build is simpler and will include fixes for other bugs although it risks exposure to unresolved quirks and will probably inhibit normal update notifications.
Comment on attachment 459902 [details] [diff] [review] fix for multiple close + open case a=Standard8 for 3.1.3, please land on comm-1.9.2 default.
Attachment #459902 - Flags: approval-thunderbird3.1.3? → approval-thunderbird3.1.3+
Resulting from this I have marked bug 578377 as resolved/fixed as it has been established that the patch used here also fixes that bug. Many thanks to all who have worked on this - oops, not allowed to say that !
URL: http://gsfn.us/t/18trc
Whiteboard: [gs]
I am not a programmer so is there somewhere that I can simply download a new version of Thunderbird with the problem fixed, please?
KiwiGirl - please see comment 60.
Thank you, Neville. I have downloaded it. What do I do now? When I click on the downloaded file on the desktop I am asked for an application to open it. :)
Which OS do you have and which file did you download?
I'm using OS X, Version 1o.5.8 on a MacBook. I downloaded thunderbird-3.2a1pre.en-US.mac.complete.mar which is probably wrong, but I had a guess (yes, I'm blonde!).
I think you want the .dmg file
Try the dmg.
I've downloaded the dmg and dragged it to Applications as it says. When I open it, it says Welcome to Shredder (I have to close Thunderbird first). What should happen now?
It is preferable to backup your Thunderbird profile first - Google it if necessary. Close Thunderbird and use Shredder instead for the time being - it should work automatically.
Yay! It works. Thanks guys. :)
Let me be sure that I do this right. All I have to do is to open the .dmg and then the shredder and I will be able to stop this infernal message pane from opening. tried the fix above with the jar inspector and got nada. probably did something wrong in the process? Mac 10.4.11 and TB 3.1.2 The word "shredder" scares me.
Well, it is still working for me and I'm delighted. I've made it my default instead of Thunderbird. No probs with it so far. Only one request - is there an English or Australian dictionary instead of the US English one, please?
Australian dictionary: https://addons.mozilla.org/en-US/thunderbird/addon/3099/ Please try and keep this bug report clear of comments which are not directed towards fixing the bug by emailing me privately about other matters. Thanks
Apologies. I thought it was related.
Blocks: 573045
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
Status: RESOLVED → VERIFIED
Any idea when this bug will be corrected in a new update
(In reply to comment #84) > Any idea when this bug will be corrected in a new update Once 3.1.3 is released on Tuesday.
Blocks: 576938
I know this is fairly belated, but I want to thank the contributors who fixed this problem. I really appreciate it!
glad it works for you , i have followed every bit of advice and still the messaged pane returns. Have been fighting this for a long time and finally got **** off enough to express my frustration. tonight when i opened the program to check fro fresh mail the pane was closed, i opened a new email and read it, when i closed the email there it was open in the pane. all weary computer users know that opening an unknown or suspicious email can unleash a virus or Trojan on an unsuspecting user, and now thunderbird is facilitating system security breaches.
Flags: in-testsuite+
Version: unspecified → 3.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: