Find doesn't always start searching from the top of a page

RESOLVED WONTFIX

Status

()

Toolkit
Find Toolbar
--
minor
RESOLVED WONTFIX
12 years ago
9 years ago

People

(Reporter: mmortal03, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060722 BonEcho/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060722 BonEcho/2.0b1

Find isn't always starting from the top anymore, i.e. FAYT isn't always going to the first instance on the page.  It is instead starting to search on the part of the page that you are viewing.  In theory, this might be useful, but in reality, this is very unpredictable and makes exhaustive searches harder to do. 

For example, if I am searching for something on a page, I always want to have it start at the beginning, so that I know that I have covered the entire page once  I have reached the bottom (and, to know this from wherever I am at on the page).

This feature might be appropriate for quick find, but not for the regular find.

Reproducible: Always

Steps to Reproduce:
1.) Go to a page that has the same word more than once.
2.) Scroll down so that one of the words lower on the page is viewable, but one of the ones higher on the page is not.
3.) Search for that word.
Actual Results:  
Find As you type doesn't go to the first instance of the word on the page.  Instead, it highlights the first instance that is visible to the user.

Expected Results:  
Find As You Type should go to the first instance of the word on the page.

Comment 1

12 years ago
Actually, it doesn't depend on what is visible. It starts at that point where you clicked (put an "invisible cursor"). If you don't click on the page, search starts at the beginning (even if you view the bottom). I like that feature (but you have to know how it works)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060727 Minefield/3.0a1
(Reporter)

Comment 2

12 years ago
I didn't know about the invisible cursor, but talk about not being intuitive!  Anyone who doesn't know this are either going to think what I thought, or they are going to be completely confused by what they perceive as erratic behavior.

The invisible cursor idea is great, "if you know how to use it."  It should therefore NOT be on by default.
(Reporter)

Comment 3

12 years ago
I think the best bet would be to put a check box on the Find bar.  It definitely has enough space next to it do do this.

Call it "Search from last clicked point on page" or something that conveys that same meaning but in a more concise manner, and make it unchecked by default, and have it retain its state.

Comment 4

12 years ago
I can confirm the issue that the reporter has outlined.  For some reason I'm not able to change status to NEW, though.  And severity should probably be bumped down to MINOR.  And this probably affects all platforms and OSes, but I can't confirm that on my own.

Also, I'm really curious if this is a recent change in functionality or if we're just noticing it now.  Does anyone know?  I use find all the time, but I've never noticed this before.

As far as what to do about it, would anyone care to explain to their grandmother how the "invisible cursor" works?  Didn't think so.  I do agree with Johannes that once you know how it works, it really is a nice feature.  On the other hand, I think that's exactly what extensions are for.  The average Firefox user out there just won't understand how it currently works.

The most confusing aspect is that I can scroll down this page a couple screens, search for "find", and it jumps back to the very top.  Now if I do that again, but I click somewhere on the page after scrolling, it goes to the first instance after where I click.

I really think it should always start searching at the top of the page by default.  The behavior could easily be controlled by a few hidden prefs and/or extensions (anyone interested in writing PimpMyFind?).
(Reporter)

Comment 5

12 years ago
I agree.  There are many other situations where we click on a page and not have any inclination to be setting the position of an invisible cursor.  Then, we go to Find something, we get what appears to be unpredictable behavior.  

Which made me consider this invisible cursor concept further.  So, is the invisible cursor placed only when the Find bar is open, or is is placed whenever you click on a page?  There are way too many variables involved with it for it to be invisibly thrown at the masses. (pun intended)

Comment 6

12 years ago
Omg, you are talking like this is the end of the world! 
I really don't want to accept a change of this behaviour, because:
 - It's not like you miss search results (You can always continue search)
 - When you look on the bottom of the site, why should the search start at top?
 - You will not have to "explain search" to your grandma, because this bug being opened 2006-07-28  means a long time of "Hey, Firefox's search is awesome".
I like it that search starts where I work. Therefore I'm voting against this bug.
And no, I don't want all the cool features in extensions.
Severity: normal → minor
OS: Windows XP → All
Hardware: PC → All
(Reporter)

Comment 7

12 years ago
Sorry if I didn't make it clear enough before:  If this bug is fixed properly, you will NOT lose your favorite new behavior, and you will not need an extension.  Thanks for the outburst.

Comment 8

12 years ago
This is not a new bug, but rather the longstanding behavior of the find bar for years.  (You're welcome to prove me wrong by giving an exact regression range, but no one has changed the code around this any time recently, and it's certainly designed behavior I've been using ever since I started using Firefox.)

Searching in the visible area or from the cursor is EXTREMELY useful and basically makes searches _usable_ in very long pages.  If the only time you went to the next match (instead of the first match) was when you still had the previous match highlighted, you basically wouldn't be able to search long pages at all.

WONTFIX.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 9

12 years ago
Peter, I am not asking that the feature be removed.  It is useful, I don't disagree with you on that.  I have considered the situation further, and would appreciate your input on it.

First of all, I apologize that I hadn't noticed it before.  It amazes me that I never saw this until recent Bon Echo builds, but I will definately take your word for it, that it was there.

So, my next question has become:  So which does it do when no clicks have been made? Does it start searching in the viewable area if no clicks have been made, or does it start searching where the invisible caret has been initially set?

From what I have tested, it looks to be the latter case.  In other words, it is NOT starting to search in the viewable area as I had previously interpreted, which would be more useful, but instead is starting to search wherever the invisible caret is initially set, which is often NOT in the viewable area.  I do not know the rules for where the invisible caret is initially placed before a user clicks on a page, but it isn't always the viewable area, and it isn't always the top of the page, either.

That being said, continuing with my train of though from my above posts, and based on this new information, it would seem much more intuitive to have it search from the caret ONLY in Caret Browsing mode by default (accessible by F7, which makes the caret visible).  HOWEVER, a sticky option box should be placed on the Find bar, off by default, called "Search Using Caret Browsing Mode", which would temporarily place the browser in Caret Browsing Mode ONLY while the Find bar was visible.  That way, we would have a much more discoverable feature, and, because the caret would now be visible, it would also be very intuitive.

Further, this would solve the problem of having to keep the browser in Caret Browsing Mode for your feature to work, which would otherwise interfere with normal keypad scrolling behavior.

Obviously, when the sticky check box would be unchecked, searches would start from the top.

I still hold the opinion that The invisible caret situation is confusing, because even what we first think it is doing (searching the viewable area) isn't what it is actually doing.  This way, no more confusing users with the invisible caret position, but then everybody still gets the feature that they want.

Comment 10

12 years ago
(In reply to comment #9)
> So, my next question has become:  So which does it do when no clicks have been
> made? Does it start searching in the viewable area if no clicks have been made,
> or does it start searching where the invisible caret has been initially set?

The code is somewhat confused because it was mangled into its current form around the 1.0 timeframe.

The apparent intent of the code is that we search from the first visible element (the "viewable area") is the following is all true:
* The user had no previous search text
* Caret browsing is off
* The selection is collapsed
* Nothing has focus

If any of these are false, we search from the existing selection/focused element/beginning of page.

I'm willing to believe there's a bug in the algorithms that makes the code not actually do this all the time, but that's what I think it intends to do.

> HOWEVER, a sticky option box should be placed
> on the Find bar, off by default, called "Search Using Caret Browsing Mode",
> which would temporarily place the browser in Caret Browsing Mode ONLY while the
> Find bar was visible.  That way, we would have a much more discoverable
> feature, and, because the caret would now be visible, it would also be very
> intuitive.

This isn't intuitive at all.  Caret browsing is incredibly confusing to many users, and toggling in and out of it based on whether the find bar had focus would only multiply that nightmare.  On top of that, bizarrely confusing feature tweaks don't belong in checkboxes on the find bar, whose UI is already heavy.  This is the sort of thing extensions are for.
(Assignee)

Updated

9 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.