Open Bug 424219 Opened 18 years ago Updated 2 years ago

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

Categories

(Thunderbird :: Mail Window Front End, defect, P3)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
defect

Tracking

(Not tracked)

People

(Reporter: wsmwk, Unassigned)

References

Details

(Keywords: regression, useless-UI, ux-consistency)

User Story

**STR**

1. View any message (message1) in 3-pane message preview.
2. Press Ctrl+F to search for words in message text (do **not** enter a search word)
3. Click once(!) on another message (message2) in the message list, then press cursor up/down to verify message list focus (--> fails, this bug), and look at find bar (--> still has the focus after we clicked another focusable element, this bug).
4. Click once again on the other message (message2) in the message list, press cursor up/down once (--> works once), and once again (--> fails again, find bar hijacks focus again, this bug).

**Actual result**

step 3: Clicking once on a message in message list should move the focus from find bar input to the message row item in the message list, but does not. Instead, focus jumps back to the find bar, and you can see blinking cursor there. There's no focus in message list, as you can test with cursor up/down which does not select another message.

step 4: Clicking another time on same message in message list does transfer the focus into the message list now, pressing cursor once works to select another message, but if you press cursor once more, focus is stolen again by find bar (back to the find bar input), and subsequent keypresses of cursor do nothing except scroll the message.

Bottom line: as long as empty find bar is open, it is not really possible to focus another message in the message list, nor a folder in the folder list, and in turn it is not possible to navigate those lists via cursor keys.

**Expected result**

ux-principle: Focus follows mouse click
- clicking on a message in message list must remove focus from empty find bar and place it on the message in message list, allowing keyboard navigation there
- clicking on a folder in folder list must remove focus from empty find bar and place it on the folder in folder list, allowing keyboard navigation there

Attachments

(1 file, 1 obsolete file)

hidden close x.png
11.84 KB, image/png
Details
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
Flags: 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.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
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! ;))
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
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.
Keywords: ux-consistency
OS: Windows Vista → All

Omg, really!? 13 years and 7 duplicates including recent! Can we please fix this? Just opening Find bar and then leaving it open can still steal keyboard focus willy-nilly and prevent users from navigating or any action in the rest of the application (message list, folder list)?

Severity: normal → S2
Keywords: useless-UI
Priority: -- → P3
Hardware: x86 → All
Whiteboard: [patchlove]

I just noticed that the close “x” of the Find bar is hidden by the Today pane if enabled when checking bug 1675750.

A user could either close the Today or Folder pane to make the close “x” usable.

(In reply to Thomas D. (:thomas8) from comment #24)

Omg, really!? 13 years and 7 duplicates including recent! Can we please fix this? Just opening Find bar and then leaving it open can still steal keyboard focus willy-nilly and prevent users from navigating or any keyboard action in the rest of the application (message list, folder list)?

Flags: needinfo?(mkmelin+mozilla)

Seems WFM on linux/trunk. Walt, do you see this still?

Flags: needinfo?(mkmelin+mozilla)

(In reply to Magnus Melin [:mkmelin] from comment #27)

Seems WFM on linux/trunk. Walt, do you see this still?

I don't see any stolen focus problems.

Still see a close "x" hidden by the Today Pane with a search term entered.

Edit: Or do I have my Folder pane set too wide? Thread and Message pane too narrow?
Forget about Vertical layout. Works best in Wide layout.

Attached image hidden close x.png —

Still seeing this fail in Daily 83.0a1 (2020-12-04) (64-bit) and Release 78.5.1 (64-bit) on Windows 10.

Please note: Exactly as Wayne reported in comment 0:

  • Search field must be empty(!) to reproduce
  • Only every first click on a message or folder fails to move the focus to the message or folder (this bug) - focus still stuck in find bar input - , but another (second) click on the same message/folder will then move the focus to the message or folder as it should.
Flags: needinfo?(wls220spring)

Ctrl+F search field empty when opened.
Flashing | in the search field with first message selected.

I don't expect to see the focus in the search field on the first click of a selected folder because no messages are showing in the Message pane. It is blank until I select a message in the Thread pane.
The focus then moves to the search field.

WFM using 78.5.1 and 85.0a1 on Windows 10 and Ubuntu 18.04.

Flags: needinfo?(wls220spring)

(In reply to WaltS48 [:walts48] from comment #31)

The focus then moves to the search field.
WFM using 78.5.1 and 85.0a1 on Windows 10 and Ubuntu 18.04.

OK. I think you are misunderstanding this bug. Not your fault, there are no clean STR, and description does not follow the prescribed format (it was long back...). The bug here is that the focus sticks in the empty search field, and does not follow single mouse clicks on another message in the message list or single click into folder list (because find bar hijacks the focus after any first click or cursor key navigation in message/folder list).

Sorry, but could you pls try again, using proper STR which I added in "User story" above?

User Story: (updated)
Flags: needinfo?(wls220spring)
User Story: (updated)

(Commenting on User Story)

STR

  1. View any message (message1) in 3-pane message preview.
  2. Press Ctrl+F to search for words in message text (do not enter a
    search word)
  3. Click once(!) on another message (message2) in the message list, then
    press cursor up/down to verify message list focus, and look at find bar.
  4. Click once again on the other message (message2) in the message list,
    press cursor up/down once, and once again

Actual result

step 3: Clicking once on a message in message list should move the focus
from find bar input to the message row item in the message list, but does
not. Instead, focus jumps back to the find bar, and you can see blinking
cursor there. There's no focus in message list, as you can test with cursor
up/down which does not select another message.

step 4: Clicking another time on same message in message list does transfer
the focus into the message list now, pressing cursor once works to select
another message, but right after that, focus is stolen again by find bar
(back to the find bar input), and subsequent keypresses of cursor do nothing
except scroll the message.

Bottom line: as long as empty find bar is open, it is not really possible to
focus another message in the message list, nor a folder in the folder list,
and in turn it is not possible to navigate those lists via cursor keys.

Expected result

ux-principle: Focus follows mouse click

  • clicking on a message in message list must remove focus from empty find
    bar and place it on the message in message list, allowing keyboard
    navigation there
  • clicking on a folder in folder list must remove focus from empty find bar
    and place it on the folder in folder list, allowing keyboard navigation there

Sorry, I'm out.

I'm not a heavy find bar or keyboard user and see no problem for navigating around the application with the find bar enabled.

Tested with 78.5.1 on Windows 10 and see the same results as on Ubuntu 18.04.

Flags: needinfo?(wls220spring)
User Story: (updated)
User Story: (updated)

Wayne (reporter), are you able to reproduce on Windows? Please use precise STR of user story!

Flags: needinfo?(vseerror)

STR in user story easily reproduces on with 84 beta on Mac and I agree that step 4 restores correct message list navigation.

Not so on Windows, beta or 78. Doing step 4 Clicking in the message list does NOT restore message list navigation - focus remains in the mesage

Flags: needinfo?(vseerror)

One observation in Thunderbird 91.3.0 that might help fix this bug:

  1. Open TB in 3-pane mode and open the search field for the message content and leave it empty as described in the report
  2. Start repeatedly and rapidly hit the up or down arrow buttons or page up/down buttons
  3. While continuing to rapidy hit the button, click the currently selected message in the message list (doesn't work on other messages)

As long as you hit the arrow keys rapidly enough, the message pane won't be updated and the focus won't be stolen.

Experiencing this on Windows Thunderbird 115.2.0 (64-bit)
"Find in Page" open with empty field, when selecting email from list whether with keyboard or mouse, "Find in Page" field steals the focus.

Close the "Find in Page" or have content in the field, email selection behavior works as expected.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: