seen in version 3.0a1pre (2008032002) not in version 2.0.5 when "find in message" is active in message preview and find input field is empty, then focus is stolen by find when clicking on a folder in folder pane or when clicking a message in thread pane. A second click on same item in either of these panes and the focus sticks where it should. Or, if find has one or more characters, then problem also does not happen. not directly related, but the only thunderbird bug of note about find+message pane is bug 263530 – "Find in Message" in quicksearch should be disabled unless message is in focus
has workaround. But is regression, and workaround is not terribly obvious. nominating blocking‑thunderbird3
it does seem broken.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Priority: -- → P2
Target Milestone: --- → Thunderbird 3.0b2
agreed, seems broken. not sure what priority though, it's annoying but not that bad
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b2
Moving this to wanted; this sucks, but I'm not sure it blocks the release. Hopefully during some polish session of rc1 we can get this piece in.
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0rc1
Severity: normal → minor
Version: unspecified → 3.0
From triage of duplicate bug 550888, note that a seemingly-related glitch is that the Find in Message bar disappears when selecting a new message iff it contains text -- either it should always disappear when a new message is selected, or never disappear, but the inconsistency isn't good. (BTW, this should be retargeted; 3.0rc1 was quite a while ago! ;))
Created attachment 512406 [details] [diff] [review] Don't set focus to quickFilterBar if message pane has focus.
Attachment #512406 - Flags: review?(bienvenu)
Comment on attachment 512406 [details] [diff] [review] Don't set focus to quickFilterBar if message pane has focus. asuth would be better to review this. And Bryan - but I think the current behavior is the desired behavior.
Attachment #512406 - Flags: review?(bienvenu) → review?(bugmail)
Comment on attachment 512406 [details] [diff] [review] Don't set focus to quickFilterBar if message pane has focus. Thank you very much for providing this patch! Two separate issues: 1) The patch needs a mozmill test before it can be reviewed. There are already keyboard-interface tests for the quick filter bar around here: http://mxr.mozilla.org/comm-central/source/mail/test/mozmill/quick-filter-bar/test-keyboard-interface.js#161 2) I don't think this patch is addressing what this bug seems to be about. The bug seems to pre-date the quick filter bar and seems to deal with focus changes related to mouse activity in the folder pane and thread pane. If I read-between-the-lines right, the problem is that focus is not properly transferred to the folder/thread pane when it should be. This patch is not that. This patch, however, does seem like it adds reasonable behaviour that users would appreciate. So if you find an existing bug or file a new bug that is appropriate to the patch I will be more than happy to review it! :)
Attachment #512406 - Flags: review?(bugmail)
Also, off the top of my head, the change from return null to return false is incorrect. I believe the method in question is a "first peek" method and that returning null says "I have nothing to say about this command" whereas returning false means "I say NO". There is documentation to that effect if the code is what I think it is.
Thanks for review. I found another existing bug 613775 which maybe right place where I should post my patch. But it was marked as a dup of bug 564328. So I posted my patch there. I can't find the document about difference between "return false" and "return null". Can you give me a link? From the code at http://mxr.mozilla.org/comm-central/source/mail/base/content/tabmail.xml#1188 "return false" will search next command handler.
Hm, nothing is jumping out at me about the false/null thing. Maybe I was thinking of some other hooking mechanism! Thanks for finding the other bug; sorry to have gotten your hopes up about the patch though. (I had forgotten that we had written off the focus-informed logic.)
given comment 10, should I file a new bug for comment 0? :)
Severity: minor → normal
Priority: P2 → --
Whiteboard: [patchlove][has draft patch]
Target Milestone: Thunderbird 3.0rc1 → ---
(In reply to Wayne Mery (:wsmwk) from comment #14) > given comment 10, should I file a new bug for comment 0? :) nevermind
Whiteboard: [patchlove][has draft patch]
Comment on attachment 512406 [details] [diff] [review] Don't set focus to quickFilterBar if message pane has focus. patch not relevant to this bug
Attachment #512406 - Attachment is obsolete: true
(In reply to Wayne Mery (:wsmwk) from comment #16) > Comment on attachment 512406 [details] [diff] [review] > Don't set focus to quickFilterBar if message pane has focus. > patch [2011-02-15] not relevant to this bug ...because it was a tentative patch for bug 564328 (see same patch in attachment 512732 [details] [diff] [review]). Fix for Bug 564328 landed 2011-08-01, where we disentangled the previously shared command for QuickFilterBar and "Find in Message". This bug 424219 is about "Find in this message" input box which, if empty, maintains a too strong grip on focus when user clicks elsewhere.
Summary: when "find in message" is active in message preview and find input field is empty, then focus is stolen by find when clicking on a folder or a message in thread pane → When "Find in This Message" (Ctrl+F) is active in message preview and find input field is empty, then focus is stolen by find when clicking on a folder or a message in thread pane
Btw, I'll add this bug to my collectibles of "TB's disregard of focus" (while admitting we've improved a lot since I started collecting). The common denominator is that users *do* expect focus to follow mouse clicks, and violating that basic UX concept is always asking for trouble.
You need to log in before you can comment on or make changes to this bug.