Search in page (CTRL+F) not working correctly
I have discovered that Firefox 58.0 (64-bit) exhibits peculiar behaviour when searching the text on a page (CTRL+F).
The "Highlight All" option is checked. The "Match Case" option is NOT checked. The "Whole Words" option is NOT checked.
The number of matches shown in the status bar appears to be correct ("31 matches", for example). However, when pressing F3 to skip to the next match, or when clicking the down arrow to skip to the next match, it skips past a semi-random number of matches. For example, the sequence might be:
1 of 31 matches 8 of 31 matches 9 of 31 matches 10 of 31 matches 11 of 31 matches 16 of 31 matches 17 of 31 matches
and so on.
accessibility.typeaheadfind.casesensitive is set to the default value. Can you think of any other reason I might be seeing this strange and frustrating behaviour?
被選擇的解決方法
Actually, I think it's an example of the bug fixed here:
Bug 1430187 search only searches visible area of textarea
This is fixed in the current "Nightly" release of Firefox 60 and is scheduled to be fixed in Firefox 59. I don't know if that change will be uplifted to Firefox 58 for a minor point release. They usually will only do that if (A) someone makes the case for it and (B) the risk of the change is very low (this varies because a working patch for a later version may not necessarily work on an earlier version due to dependencies on other changes).
從原來的回覆中察看解決方案 👍 0所有回覆 (17)
Maybe some of the matches are in a frame or they are in a hidden part of the page or a specific element has more references. You can try to use the page source (Ctrl+U) to see if you can identify the missing matches.
Can you post a link to a publicly accessible page (i.e. no authentication or signing on required)?
由 cor-el 於
https://ogc.rpglibrary.org/index.php?title=Bulletproof_Blues_3e_EN:Powers
CTRL+F Search for "endurance" (match case OFF, whole words OFF) 1 of 42 matches 2 of 42 matches ... 8 of 42 matches 9 of 42 matches 12 of 42 matches
And it does it going "up", as well, but not the same way.
11 of 42 matches 10 of 42 matches 7 of 42 matches 6 of 42 matches
The entries that it skips are consistent, and happens whether I type F3 or I click the "down" arrow by the search box. This is not a case of my accidentally double-clicking.
I get 41 matches via Find and I get all 41 via next and previous. The page source shows #26 as being in a link, so that would make 42 in total.
Did you try Safe Mode in case an extension is interfering?
Yes. Safe mode == exact same behaviour.
One possibility is that your Firefox program files got corrupted during the update and need to be replaced. Before banging our heads against the wall any further, I think you should try:
Clean Reinstall
We use this name, but it's not about removing your settings, it's about making sure the program files are clean (no inconsistent or alien code files). As described below, this process does not disturb your existing settings. It's not essential to uninstall Firefox, but you can if you like, saying No to any request about removing personal data.
It only takes a few minutes.
(A) Download a fresh installer for Firefox to a convenient location:
https://www.mozilla.org/firefox/all/
(B) Exit out of Firefox (if applicable).
If you use Microsoft Office, please change your default browser to Internet Explorer before the next step.
(C) Using Windows Explorer/My Computer (hold down the Windows key and press E), right-click > rename the program folder as follows (you might have one or both):
C:\Program Files (x86)\Mozilla Firefox =to=> C:\Program Files (x86)\OldFirefox
C:\Program Files\Mozilla Firefox =to=> C:\Program Files\OldFirefox
(D) Run the installer you downloaded in step (A). It should automatically connect to your existing settings.
Any improvement?
That seems truly unlikely, since it happens on two different computers (my desktop and my laptop), both running FF 58.0. I think this is just a bug. What's the best way to report this bug?
I've tested the same site on Chrome, so I don't think it's something on the web page. I will try a different page in FF and see what happens.
I have found another site, and FF has the same behaviour. Here are the steps:
Go here: https://en.wikipedia.org/wiki/Golden_jackal
Click "edit", so that you are looking at the editable text. Click in the text window on the first line (the one that says "{{featured article}}".
CTRL+F, and type "asia". In the status bar you will see, "4 of 46 matches".
See? It has already skipped the first three matches. Place the cursor at the very top of the page, and click the "down" arrow (of type F3, it does the same thing). You will see:
4 of 46 matches (first three skipped) 5 of 46 matches ... (no skips) 17 of 46 matches 18 of 46 matches 20 of 46 matches (skipped 19) 22 of 46 matches (skipped 21)
Going "up" from here skips different matches, but it always skips the same ones.
22 of 46 matches 21 of 46 matches 18 of 46 matches (skipped 19 and 20) 17 of 46 matches 16 of 46 matches 15 of 46 matches 13 of 46 matches (skipped 14)
Which matches get skipped, in either direction, seems random, but they are also consistent -- the same ones are skipped every time. But different ones are skipped going "down" than when going "up".
What's the best way to report this bug?
You can file a bug report here: https://bugzilla.mozilla.org/
However, let's see whether we can refine the description.
- It doesn't seem to occur in page text, but the skipping occurs in <textarea> controls
- Skipping occurs after Firefox has selected the last visible match in the textarea and moves towards the next match, for some reason it may skip over matches to reach a later one
Here's an excerpt of that article as a test case: https://www.jeffersonscher.com/temp/find-asia.html
It's hard to describe what is happening there in sensible terms.
選擇的解決方法
Actually, I think it's an example of the bug fixed here:
Bug 1430187 search only searches visible area of textarea
This is fixed in the current "Nightly" release of Firefox 60 and is scheduled to be fixed in Firefox 59. I don't know if that change will be uplifted to Firefox 58 for a minor point release. They usually will only do that if (A) someone makes the case for it and (B) the risk of the change is very low (this varies because a working patch for a later version may not necessarily work on an earlier version due to dependencies on other changes).
Holy cow! I think you are probably right!
That is good news. I will wait for 59. Thanks, everyone!
This bug is still occurring on macOS, on Firefox 61.0.1, as well as on Safari. I have asked a question about this on the Super User Q&A community of the website Stack Exchange, which includes a link to a file for testing and reproducing. If you have a fix, please provide info.
Hi Vincent_Mia_Edie_Verheyen, this could be related to the earlier bug, but it's a different scenario because it's within an SVG drawing and visible matches are skipped, not just ones that require scrolling.
You may want to start a new thread or file a new bug on Bugzilla.
Hi jscher2000, following your recommendation I have now filed a bug report at Bugzilla:
Did you make sure that all find settings are default?
You can paste this regexp in the search bar on about:config:
- /^accessibility.typeaheadfind|^findbar/
These are my config settings for any string including "find" (they are all of status "default", except for "accessibility.typeaheadfind.flashBar", which is of status "modified"):
boolean
- accessibility.typeaheadfind ⚫ false
- accessibility.typeaheadfind.autostart ⚫ true
- accessibility.typeaheadfind.enablesound ⚫ true
- accessibility.typeaheadfind.enabletimeout ⚫ true
- accessibility.typeaheadfind.linksonly ⚫ false
- accessibility.typeaheadfind.prefillwithselection ⚫ false
- accessibility.typeaheadfind.startlinksonly ⚫ false
- findbar.entireword ⚫ false
- findbar.highlightAll ⚫ false
- findbar.modalHighlight ⚫ false
- services.sync.prefs.sync.accessibility.typeaheadfind ⚫ true
- services.sync.prefs.sync.accessibility.typeaheadfind.linksonly ⚫ true
integer
- accessibility.typeaheadfind.casesensitive ⚫ 0
- accessibility.typeaheadfind.flashBar ⚫ 0
- accessibility.typeaheadfind.matchesCountLimit ⚫ 1000
- accessibility.typeaheadfind.timeout ⚫ 5000
- findbar.iteratorTimeout ⚫ 100
string
- accessibility.typeaheadfind.soundURL ⚫ beep
- browser.safebrowsing.provider.google4.gethashURL ⚫ https://safebrowsing.googleapis.com/v4/fullHashes:find?$ct=application/x-protobuf&key=%GOOGLE_API_KEY%&$httpMethod=POST
- extensions.webextensions.themes.icons.buttons ⚫ back,forward,reload,stop,bookmark_star,bookmark_menu,downloads,home,app_menu,cut,copy,paste,new_window,new_private_window,save_page,print,history,full_screen,find,options,addons,developer,synced_tabs,open_file,sidebars,share_page,subscribe,text_encoding,email_link,forget,pocket
由 user1522428 於