Closed Bug 521026 Opened 12 years ago Closed 12 years ago
Can't open\close message pane with F8 button
STR: 1. close TB 2. open TB 3.1 if message pane is show, clicking on F8 button I can't hidden it. 3.1 if message pane is hidden, clicking on F8 button I can't show it. For restore functionality, I do click via menu-->view-->layout on item "message pane". After F8 button work fine (until the next restart of TB)
Also observed on Mac OS X 10.6.1 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:184.108.40.206pre) Gecko/20091008 Shredder/3.0pre
What I see on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:220.127.116.11pre) Gecko/20091012 Lightning/1.0pre Shredder/3.0pre: - If the message list, folder list or message header (e.g. subject) are focussed, then fn-f8 (the Mac equivalent of f8) closes and opens the message preview pane. - If the message content itself is focussed, fn-f8 will close the message preview but it won't open it again. I guess this is because the browser effectively has focus but is collapsed out of view.
This happens with SeaMonkey, too [Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168pre) Gecko/20091014 SeaMonkey/2.0pre].
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20091015 Shredder/3.0pre. I have a weird workaround. If you go to View->layout->Message Pane (F8), and toggle it, F8 works normally after that until the client is closed. I can't get it not work, even when focus is moved around.
(In reply to comment #4) > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/20091015 > Shredder/3.0pre. > > I have a weird workaround. If you go to View->layout->Message Pane (F8), and > toggle it, F8 works normally after that until the client is closed. I can't > get it not work, even when focus is moved around. you don't even have to toggle it afaict. just going to View... is sufficient to make F8 work
None of the workarounds works for me :-(. Please fix this before release date. The last beta worked fine AFAIR, so I would guess the list of changes that might have introduced this annoyance would be rather small.
best regression window I have ATM is fails 20091013, works 20091005
so Aureliano date of report narrows it, but he doesn't write which build was used. I'd guess the 2009-10-07 build) - there's too many checkins on 10/5 and 10/6 for me to make a quick guess as to the causing checkin
(In reply to comment #10) > so Aureliano date of report narrows it, but he doesn't write which build was > used. I'd guess the 2009-10-07 build) Yes build was 20091007
For better precision is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20091007 Lightning/1.0pre Shredder/3.0pre ID:20091007032014
From Phil's bisect, I based this on the patch in Bug 472076.
Comment on attachment 416114 [details] [diff] [review] Patch v1 I suspect the problem is that the "cmd_toggleMessagePane" command is initialized to be disabled initially in mailWindowOverlay.xul. We return true for the command being supported/enabled in all cases unless the thread pane is illegal, so I presume the problem is a failure for that command to get its state updated. The menu likely forces a refresh of the command state which allows things to work.
Attachment #416114 - Flags: review?(bugmail) → review-
I'll look at this a little more right now and get back with a suggestion.
Comment on attachment 416114 [details] [diff] [review] Patch v1 It turns out that our command handling is more broken than I assumed was the case. This seems like a sane solution to the problem after all :). Thank you very much for the patch. I will land this for you on the trunk and request approval on the 3.0.x branch.
Thanks, Andrew. I was just going over this again after your review-; looks like similar code is used elsewhere: > <command id="cmd_viewPageSource" oncommand="goDoCommand('cmd_viewPageSource')" disabled="true"/> > ... > <key id="key_viewPageSource" key="&pageSourceCmd.key;" oncommand="goDoCommand('cmd_viewPageSource')" modifiers="accel"/> So I agree that the command handling is pretty strange! Is there already a bug on that?
We can live without this bug being fixed in 3.0, but we should block 3.0.1 on it. I don't currently have a strong opinion on whether that fix should come in the form of patch here or the one on bug 532969. Presumably, the patch here is less risky...
blocking-thunderbird3.0: --- → .1+
I tried Jason's patch on Linux: The F8 works as expected now, but of course this was just a very brief test.
I can confirm that the bug is still present in TB 3.0 (build ID: 20091204171430).
With Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20091204 Thunderbird/3.0, F8 becomes functional once you go to the menu bar and select [View > Layout > Message Pane]. Thereafter during the same session, F8 will both open and close the message pane. Since this regression requires navigating to a menu and then a submenu every time Thunderbird is launched, this might be considered as "major feature is broken" with the Importance increased from Normal.
As you can find above, opening the view menu is all it takes to clean up the state and make F8 work. You can do this either with the mouse or alt-v (windows).
I suspect this is the same problem or at least related. When I first open TB3, <control><+> does not change the size of text in the message pane. Oddly, if I open TB and the message pane is not displayed, I can do an <alt><v>[cencel] and then f8 will display the message pane. At that point, <control><+> still won't work. A second <alt><v>[cancel] will then "unlock" the <control><+> functionality.
Does this needs to be checked in ?
(In reply to comment #27) > Does this needs to be checked in ? From the discussions, I think Andrew and Jason need to decide if they are going with this version or the one on bug 532969. Andrew, thoughts? I'd like to get something in for 3.0.1 at least.
Close Thunderbird -> Open Thunderbird -> ctrl+shift+T does not work here; workaround: use the menu, then it will work. Maybe this has something to do with the bug here. Peter Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:220.127.116.11) Gecko/20091204 Thunderbird/3.0
Peter: Not related to this bug (and I cannot reproduce your findings, on Linux). My personal opinion on this bug is in agreement with Comment #20. This patch only reverts a change made in Bug 472076, to coincide with the rest of the XUL in its current state. I can always unbitrot Bug 532969 when it comes time for that one. (It still needs tests, per Andrew's request.)
F8 issues reported in gsfn http://getsatisfaction.com/mozilla_messaging/topics/how_do_i_disable_the_message_preview_pane_in_thunderbird_3_0 Time to land patch?
Checked into trunk: http://hg.mozilla.org/comm-central/rev/aded7874ea8e I'm assuming the tests recommended in bug 532969 will cover this bug as well (just ask if you need help).
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1a1
Comment on attachment 416114 [details] [diff] [review] Patch v1 This patch is now baking on trunk, so we should consider it for branch soon (applies without conflict).
Attachment #416114 - Flags: approval-thunderbird3.0.1?
Attachment #416114 - Flags: approval-thunderbird3.0.1? → approval-thunderbird3.0.1+
Checked into branch: http://hg.mozilla.org/releases/comm-1.9.1/rev/82a4e37ff7d9
I inserted the proposed fix into my TB 3.0 environment (file mailWindowOverlay.xul) manually and performed a quick test. It seems to fix the problem.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:18.104.22.168) Gecko/20100107 Shredder/3.0.1pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.