Find as you type = off pref, should respect typeaheadfind and not allow autostart

NEW
Assigned to

Status

()

P2
normal
15 years ago
a month ago

People

(Reporter: Peter6, Assigned: spillner, Mentored, NeedInfo)

Tracking

(Depends on: 1 bug)

1.8 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [good-next-bug])

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
If Use Find as you type in options is off only
userpref accessibility.typeaheadfind is set to false
userpref accessibility.typeaheadfind.autostart is left default (=true)

For people using chats and fora it's extremely annoying if you use ' or / and
the autostart starts the find toolbar and moves focus to that input.

expected:
if 
accessibility.typeaheadfind is set false
accessibility.typeaheadfind.autostart should respect that and regarless of its
value not autostart (respect accessibility.typeaheadfind false).

Comment 1

15 years ago
This bug is fixed with the patch in bug 251073
Depends on: 251073
OS: Windows 2000 → All
Hardware: PC → All
Summary: Options , Find as you type = off , should respect typeaheadfind and not allow autostart → Find as you type = off pref, should respect typeaheadfind and not allow autostart
(Reporter)

Comment 2

15 years ago
*** Bug 264814 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 3

15 years ago
(In reply to comment #1)
> This bug is fixed with the patch in bug 251073

so typing a / or a ' on a page (not in an input) causing the findbar to popup is
designed behaviour ?
I though this would be disabled, only leaving you the option to press F3 to
activate it ?

Comment 4

15 years ago
(In reply to comment #3)
> (In reply to comment #1)
> > This bug is fixed with the patch in bug 251073
> 
> so typing a / or a ' on a page (not in an input) causing the findbar to popup is
> designed behaviour ?
> I though this would be disabled, only leaving you the option to press F3 to
> activate it ?

The final patch to fic bug 251073 was not that patch that included the fix for
this bug.  I am working on a new patch to fix the remainder of the preference
issues including this one.

Comment 5

14 years ago
this bug is fixed with the patch in bug 265915
Depends on: 265915
(Reporter)

Comment 6

14 years ago
*** Bug 290625 has been marked as a duplicate of this bug. ***

Comment 7

14 years ago
Possibly related to bug 220900?
Depends on: 220900

Comment 8

14 years ago
In v1.06 on MacOS X (10.3.9), the preference "Begin finding as you begin typing"
controls the *autostart* mechanism of typeaheadfind.  However, the checkbox will
modify accessibility.typeaheadfind, *NOT* accessibility.typeaheadfind.autostart.

In addition, it appears that accessibility.typeaheadfind.autostart is completely
ignored (true/false make no difference in behavior), and
accessibility.typeaheadfind controls only the autostart mechanism.  There
appears to be no way to totally disable typeaheadfind because of this.

Comment 9

13 years ago
*** Bug 321418 has been marked as a duplicate of this bug. ***

Comment 10

13 years ago
In v1.5.0.1 for MacOS X, the bug I described in comment #8 is still present... the two typeaheadfind preferences are not behaving properly, as outlined in that comment. 

Updated

13 years ago
Assignee: firefox → nobody
QA Contact: fast.find

Comment 11

13 years ago
The same problem occurs in Firefox 2.0 beta 1 (20060710) on Windows

Comment 12

13 years ago
Sorry, the problem in the latest Windows beta is that any typing outside a text field will activate type-ahead find, even if accessibility.typeaheadfind.autostart is false.  The MozillaZine knowledge base links to this bug for that problem. :-(

Comment 13

13 years ago
*** Bug 348187 has been marked as a duplicate of this bug. ***
Blocks: 363083

Updated

12 years ago
Version: 1.0 Branch → 2.0 Branch
Product: Firefox → Toolkit

Updated

9 years ago
Duplicate of this bug: 532642

Updated

4 years ago
See Also: → bug 1210212
Priority: -- → P5
Duplicate of this bug: 1412423
The history of the 'autostart' pref wasn't very clear to me, until I dived a little deeper into CVS and bugzilla history.
So this was implemented in bug 176296, which was back when _any_ keystroke would initiate a find-in-page and "'" or "/" were used to switch between text-mode and links-only-mode.

Today these keys are used as activators for Quick Find (showing a minimally marked up findbar), and the 'autostart' pref is not used anymore.
Additionally, the 'accessibility.typeaheadfind.autostart' and 'accessibility.typeaheadfind.enabletimeout' are not used anymore.

Therefore it seems prudent to ensure that
 1. 'accessibility.typeaheadfind.autostart = false' disables Quick Find for those who wish it,
 2. 'accessibility.typeaheadfind.enabletimeout' is removed from all.js.

Upping priority, since this bug is now actionable.
Mentor: mdeboer
Priority: P5 → P2
Whiteboard: [good-next-bug]

Updated

7 months ago
Duplicate of this bug: 1483209
(Assignee)

Comment 18

7 months ago
- The accessibility.typeaheadfind preference turns off ALL FAYT functions when set to 'false'
  - The keystroke-interpretation code in FindBarChild.jsm and findbar.xml now respects both the accessibility.typeaheadfind.manual and typeaheadfind.autostart preferences
  - Documents of any type can manually inhibit FAYT with the "disablefastfind" document element attribute (previously restricted to the chrome: and about: protocols)
  - Corrected & extended the pertinent unit tests (browser_fastfind* test modules)
(Assignee)

Comment 19

7 months ago
Uploaded patch at https://phabricator.services.mozilla.com/D3404 to simplify/correct this to what I think is more intuitive logic:
   * Setting accessibility.typeaheadfind to 'false' inhibits ALL fast-find triggers
   * When accessibility.typeaheadfind and accessibility.typeaheadfind.manual are both true, typing a / or ' will trigger the fast-find dialog
   * When accessibility.typeaheadfind and accessibility.typeaheadfind.autostart are both true, typing any character except a space will trigger the fast-find dialog
   * Note that when all three preference variables are true, the manual trigger characters (/ or ') will trigger but not populate the dialog, i.e. you would have to type ' or / twice to begin a search string with those characters.  When autostart is true but the manual trigger is not, ' and / are treated exactly like any other keys.  This was poorly defined before and this convention seems preferable (less confusing to those used to the manual shortcuts).

If accepted, http://kb.mozillazine.org/Accessibility.typeaheadfind should be updated to reflect the new behavior.

Even if the patch is not accepted, someone should correct the relevant variable names in the new toolkit/actors/FindBarChild.jsm to match toolkit/content/widgets/findbar.xml (leading underscores in _findAsYouType, _manualFAYT)--- right now this typo breaks most FAYT behavior.
Comment on attachment 9000194 [details]
Bug 254592 - Updated "Find As You Type" (FAYT) to resolve https://bugzilla.mozilla.org/show_bug.cgi?id=254592, specifically: r=mikedeboer

Kris Maglione [:kmag] has approved the revision.
Attachment #9000194 - Flags: review+
Assignee: nobody → spillner
Keywords: checkin-needed
Hi! When trying to land this on autoland trough phabricator(lando) I received the following error:

Error: We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again. (255, 'applying /tmp/tmpjkVhcf\npatching file toolkit/content/widgets/findbar.xml\nHunk #2 FAILED at 327\n1 out of 16 hunks FAILED -- saving rejects to file toolkit/content/widgets/findbar.xml.rej\nabort: patch failed to apply', '')
Please see Comment 21. Thanks!
Flags: needinfo?(spillner)
Keywords: checkin-needed
(Assignee)

Updated

7 months ago
Flags: needinfo?(spillner)
Keywords: checkin-needed
Hi spillner

The commit message for the patch needs fixing.

You can use this as guideline: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities
Flags: needinfo?(spillner)
Keywords: checkin-needed
(Assignee)

Comment 24

7 months ago
Reset to original commit message.  I've also submitted the following text to the MozillaZine knowledge base thread as a correction for http://kb.mozillazine.org/Accessibility.typeaheadfind:

"When accessibility.typeaheadfind is set to false, all Find As You Type functionality is disabled.  When both accessibility.typeaheadfind and accessibility.typeaheadfind.manual are set to true, typing a ' or / will open the Find As You Type window and move the cursor focus there.  If accessibility.typeaheadfind and accessibility.typeaheadfind.autostart are both true, typing anything other than a space will open the Find As You Type window.  If accessibility.typeaheadfind.timeout is set to a value greater than zero, the Find As You Type window will disappear that many milliseconds after the last keypress."
Flags: needinfo?(spillner)
Keywords: checkin-needed
The issue with the commit message is the first line - you're basically referencing the bug number twice and not clearly summarizing what the patch is actually doing. I would expect it to be something more along the lines of:
Bug 254592 - Update "Find As You Type" (FAYT) to respect the accessibility typeaheadfind preferences. r=kmag

Or something to that effect. Anyway, that's more in line with our usual conventions for commit messages.
Flags: needinfo?(spillner)
Keywords: checkin-needed
(Assignee)

Comment 26

7 months ago
The patch fixes the bug.  The next three lines of the commit message describe the new behavior.  The tests provide some level of confidence that the browser satisfies that specification.  I don't see much value in anything either shorter or longer.  Feel free to edit it yourself if I'm missing something.
Flags: needinfo?(spillner)

:mikedeboer, could you fix the issue with the commit message ?

Flags: needinfo?(mdeboer)
You need to log in before you can comment on or make changes to this bug.