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

NEW
Unassigned

Status

Thunderbird
Mail Window Front End
10 years ago
5 years ago

People

(Reporter: wsmwk, Unassigned)

Tracking

({regression})

x86
Windows Vista
regression
Bug Flags:
blocking-thunderbird3 -
wanted-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patchlove])

Attachments

(1 obsolete attachment)

(Reporter)

Description

10 years ago
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
(Reporter)

Comment 1

10 years ago
has workaround. But is regression, and workaround is not terribly obvious.
nominating  	 blocking‑thunderbird3
Flags: blocking-thunderbird3?
it does seem broken.
Flags: blocking-thunderbird3? → blocking-thunderbird3+

Updated

10 years ago
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.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0rc1
(Reporter)

Updated

8 years ago
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! ;))
Duplicate of this bug: 550888
Duplicate of this bug: 554308

Comment 8

7 years ago
Created attachment 512406 [details] [diff] [review]
Don't set focus to quickFilterBar if message pane has focus.
Attachment #512406 - Flags: review?(bienvenu)

Comment 9

7 years ago
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.

Comment 12

7 years ago
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.)
(Reporter)

Comment 14

5 years ago
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 → ---
(Reporter)

Comment 15

5 years ago
(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]
(Reporter)

Comment 16

5 years ago
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
Whiteboard: [patchlove]
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.