Closed Bug 296720 Opened 20 years ago Closed 19 years ago

Can't get to links using FastFind (Ctrl+F)

Categories

(Toolkit :: Find Toolbar, defect)

Product:
Toolkit
Component:
Find Toolbar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8final

People

(Reporter: brendan, Assigned: masayuki)

References

Details

Attachments

(2 obsolete files) 

When using FastFind to find a link, or when typing any findable text, Enter
should go to the document view, not to the Find: textbox.  With links, this
allows easy keyboard-only link navigation.  I thought this was how FastFind was
meant to work, but it's easy for me (on Linux FC3 anyway) to show this bug.

/be
*** Bug 296840 has been marked as a duplicate of this bug. ***
Ok, so repeating here what I said on IRC:

* Ctrl-F, type some text, hitting Enter cycles, in virtually every app I've ever
used.  Breaking that is bad.
* Actually searching in links-only mode works just fine (using ' to invoke the
find bar).  Its only in normal text searches that this doesn't happen.
* FAYT still works like this

What we can do to mitigate the conflict somewhat:
* matched text should be selected when the find toolbar is dismissed (so if text
searching is the current context, but you find a link, you can still get to it
without more pain than hitting Esc
* hitting ' to trigger links-only mode should work even if the findbar is
already open.
(In reply to comment #2)
> * hitting ' to trigger links-only mode should work even if the findbar is
> already open.

You don't really mean "you can't fastfind for things with apostrophes any more",
right?
Ctrl-F in other apps, as Miguel points out
(http://tirania.org/blog/archive/2005/May-10.html), is a lame modal -- or at
least flying-over-what-it-found -- dialog.  So long as such a dialog has focus,
sure, Enter should cycle.

But we don't have such a lame flying in your face dialog.

FastFind is modeless, more like Emacs isearch than a traditional Ctrl-F dialog.
 We should not be adding modality by treating the Find textbox as focused for
all keyboard inputs.  This is important, and IIRC it was a feature of FAYT
before the FastFind evolution.  There are other bugs (on file, I hope -- I've
cursed and slacked instead of filing them) where focus seems to get stuck in the
FastFind textbox.  Anyone else see these?

Another point: Ctrl-G cycles too.

What about this idea: Enter cycles if the user has focused the FastFind toolbar
or textbox; otherwise (focus still on the doc, user didn't move it), Enter goes
to the content.

Alternative idea: Enter goes to the content if a link has been found, else it
cycles.  This seems worse, as we don't know what non-link content might do with
Enter, so breaking the tie just based on the element that was found could be
painfully simplistic.

/be
Yeah, I'm having a hard time thinking of other apps that have non-modal search
and use enter that way.  I never even thought to use it that way, using
cmd/ctrl-g instead like it says in the menu, and like I do even on the other
modal-pain find dialogs in apps I use.

Please, though, no match-dependent magic!  Wreaks havoc on muscle memory,
however you train yourself.
(In reply to comment #5)
> Please, though, no match-dependent magic!  Wreaks havoc on muscle memory,
> however you train yourself.

I withdraw my "Alternative idea".

It's clear to me that focusing the FastFind textbox in such a way that Enter
goes there is wrong.  Let the user click to focus in that way.  The focus model
is not the same as for a flying-in-your-face dialog.  FastFind is different --
or should be (wherefore this bug).

/be
Flags: blocking-aviary1.1+
(In reply to comment #6)
> is not the same as for a flying-in-your-face dialog.  FastFind is different --
> or should be (wherefore this bug).


And its dup, bug 296840 -- which points out the misleading effect of
highlighting the found link text.  It's not the highlighting, though that is
particularly misleading.

Try this in this bug: click in the "Reassign bug to [nobody@mozilla.org]"
textbox, and hit tab three times.  The "View Bug Activity" link will be focused
with a dashed box around it.  Now type "Format" and see how FastFind not only
highlights the first word of the next link, "Format For Printing" -- it also
puts the dashed focus ring (box, whatever) around that link, just as tabbing did
for the "View Bug Activity" link.

We are miscuing the user and stealing focus.  This bug should be fixed for 1.1.
 Mconnor, can you take it?

/be
(In reply to comment #7)
> 
> Try this in this bug: click in the "Reassign bug to [nobody@mozilla.org]"
> textbox, and hit tab three times.  The "View Bug Activity" link will be
> focused with a dashed box around it.  Now type "Format" and see how FastFind
> not only highlights the first word of the next link, "Format For Printing" --
> it also puts the dashed focus ring (box, whatever) around that link, just as
> tabbing did for the "View Bug Activity" link.

And (duh) hitting Enter in this case will activate the link.

It's only when Ctrl-F is used that focus goes to the FastFind textbox.  Ok,
sorry for rehashing all this.  I still think we ought to let Enter go to the
link, for the same reason we do when FastFind is implicitly finding (in the
"Format" case above).

/be
Mmm, I now dimly recall this focus-on-CtrlF behaviour as being intentional to
preserve pre-fastfind behaviour.  Can't find the bug comment about it, though.
shaver, I was unclear, sorry, ' with focus in the content area should switch the
search context, but if focus is in the search textbox it should recognize the '
character like any other.  And there may or may not be a bug comment about it,
this wasn't exactly a feature that was managed through the Bugzilla process.

The problem really comes down to the fact that we have three distinct search
modes: FAYT-like, FAYT-links-only, find-dialog-without-annoying-modality.  Just
because we've dropped the modal part doesn't mean that the expected results for
Ctrl-F, "foo", Enter aren't long-established.  All three have different expected
results, and all three can be invoked separately (even with the autostart
behaviour disabled).  There's room for improvement, yes, but I don't think we
want to make Ctrl-F act vastly different because we prefer FAYT's behaviour. 
Use / (FAYT) or ' (linksonly) if you want that behaviour.
Assignee: nobody → mconnor
Not sure what "room for improvement... no change" means.  We ought to simplify
where possible.  Would we get bugs if we made Enter go to the content area
unless the user had clicked on the FastFind textbox?

Preserving pre-FastFind behavior seems like exactly the wrong thing, given how
much better FastFind is than the old flying Find dialog.

At this point I am going to go reexamine my usage patterns to check whether I
really hit Ctrl-F in all those cases where Enter seemed to go to the wrong place.

/be
Flags: blocking-aviary1.1+ → blocking-aviary1.1?
Summary: FastFind should send Enter key to link handler → FastFind (Ctrl+F) should send Enter key to link handler
(In reply to comment #11)
> Not sure what "room for improvement... no change" means.  We ought to simplify
> where possible.

The improvements are the ones I mentioned initially (if using Ctrl-F and you
have a match, on hitting Esc to dismiss the toolbar focus goes to the match, and
allowing for switching search contexts). 

> Would we get bugs if we made Enter go to the content area
> unless the user had clicked on the FastFind textbox?

We got bugs because it wasn't a dialog anymore, so I'm quite sure making
functional changes that break user expectations would definitely get bugs/crying
grandmas.

> Preserving pre-FastFind behavior seems like exactly the wrong thing, given how
> much better FastFind is than the old flying Find dialog.
> 
> At this point I am going to go reexamine my usage patterns to check whether I
> really hit Ctrl-F in all those cases where Enter seemed to go to the wrong place.

I'm ashamed to admit that Ctrl-F/foo/Enter is my habit, but I grew up on Windows
editors and apps, and I remain bound by those. (FYI, Editpad implemented this
type of find bar-like beast, and it acted the same way, sans FAYT).

Ctrl-F and its standard behaviour is the most common application shortcut on
Windows (I was discussing that last week with aaronlev), and breaking that
expectation is a massive usability hit.  Even if users adapt, switching between
Office and Firefox is going to be painful since the same very common shortcut
acts differently.  Since Thunderbird doesn't use the findbar, even that could be
confusing. Sure, its "better" as a concept, sort of (I have to move my hands
more to hit Ctrl-G/F3 instead of Enter), but for something this common, we can't
break ranks.

Two weeks ago I was arguing in another bug with blake about Enter going to
links, and initially I thought along the same lines as you.  But going deeper,
and considering typical behaviour across multiple apps, I reached the conclusion
that we can't break this.
How about a modifier key + Enter for link activation after Ctrl-F driven find?

/be
Yeah, thought about that too...

Currently Shift-Enter is Find Previous, Ctrl-Enter is/was Highlight, but since
that's in books and stuff, blake convinced me that it should get added back...

Alt-Enter could work, but that introduces a nice inconsistentcy with FAYT and
normal keyboard nav (since that is Save As in content... which is another set of
conflicting shortcuts...)

As much as I hate this idea on general principle, there could be room for a pref
for which mode Ctrl-F triggers... its not an "extra codepaths" type pref, its
just affecting which action is bound to Ctrl-F.  In a future where configurable
keybindings exist, this is a separate action that would be an option, so this is
mostly anticipating that type of change.
if i used this product and enter with focus not in the content area (read: in
whatever the searching area is called) didn't find next i'd complain that enter
doesn't match the behavior of windows *notepad* where the find dialog is *not*
modal.
Note that I never said Ctrl-F Find was "modal" in the "hogs events" sense --
just that it was a separate window, not an isearch-like thing.  Modalities of
all kinds are a problem in UI.

This bug and its dup may say that we should make Ctrl-F driven FastFind less
modal, but it sounds like not, or at least not without a better idea.  Mconnor,
feel free to use this well for now, or future it, or invalid it.

/be
A lot of related stuff has happend in the IME bug (bug 259454). We're now
focusing both the link and the text field (in FAYT mode).
Depends on: 259454
*** Bug 300197 has been marked as a duplicate of this bug. ***
By bug 259454 is fixed, we can get some ways.

E.g.,
1. We can fire the Enter Key event on link element by Enter Key event of find
toolbar if an link is found already.
https://bugzilla.mozilla.org/attachment.cgi?id=188774
2. We can not fire the Enter Key event on link element. But if type ESC Key on
find toolbar, we can set the focus to found link.
https://bugzilla.mozilla.org/attachment.cgi?id=188776
OS: Linux → All
Hardware: PC → All
> 1. We can fire the Enter Key event on link element by Enter Key event of find
> toolbar if an link is found already.
> https://bugzilla.mozilla.org/attachment.cgi?id=188774

see comment 5.  That's not going to happen.

> 2. We can not fire the Enter Key event on link element. But if type ESC Key on
> find toolbar, we can set the focus to found link.
> https://bugzilla.mozilla.org/attachment.cgi?id=188776

That's one part of the solution I was thinking about, can you attach that patch
to this bug?
Attached patch Patch (obsolete) — — Splinter Review 
Here, Mike.
Attachment #188839 - Flags: review?(mconnor)
Attachment #188839 - Flags: review?(mconnor)
Attached patch Patch (obsolete) — — Splinter Review 
I found my mistake in bug 259454.

> -    foundLink.style.outlineOffset = "0;";
> +    foundLink.style.outlineOffset = "0";

It's fixed too in this patch. (That problem has no problem. Because it is
invalid value for CSS spec.)
Attachment #188839 - Attachment is obsolete: true
Attachment #188908 - Flags: review?(mconnor)
Will re-evaluate after I review the patch in this bug.
Flags: blocking-aviary1.1? → blocking1.8b4+
Summary: FastFind (Ctrl+F) should send Enter key to link handler → Can't get to links using FastFind (Ctrl+F)
Comment on attachment 188908 [details] [diff] [review]
Patch

this is what I had in mind, great!
Attachment #188908 - Flags: review?(mconnor)
Attachment #188908 - Flags: review+
Attachment #188908 - Flags: approval1.8b4+
let's make this the fix for 1.8b4, and resolve this bug and move on if there's
further changes to be considered.
Assignee: mconnor → masayuki
Comment on attachment 188908 [details] [diff] [review]
Patch

checked-in.
Attachment #188908 - Attachment is obsolete: true
Should I mark it to FIXED?
I'm marking to FIXED this.
Please file a new bug if we need more discussion.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: