Incremental search, in reverse, sometimes SKIPS hits.
Categories
(Toolkit :: Find Toolbar, defect, P4)
Tracking
()
People
(Reporter: dscotese, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Steps to reproduce:
I'm sorry, I was going to paste my entire post here, which I copied from the Help|Submit Feedback page right before I submitted it. But then I copied something else and lost it. But praise be to God, that page reports that "The content of your feedback will be public" which means what I wanted to paste here will be public. I can't find it now, and it was quite some work, so I'll trust that you will be able to find it. I'd be interested in what it says too because I've forgotten.
Actual results:
The highlighted search result after clicking the UP arrow is higher on the page than the a search result that lies between the one that was just highlighted and the one that is now highlighted. In other words, Firefox skipped an in-page search hit. And it isn't a misperception on my part because I can hit the down arrow to highlight the hit that it skipped.
Expected results:
It should have scrolled up only two lines instead of seven (or more) and highlighted one of the two occurrences (of "ee") for block 274736.
To reproduce this bug:
- Visit https://www.blockchain.com/btc/blocks/1386958990748
- Scroll to the end.
- If 274736 is visible in the column of numbers on the left, shorten your browser window and scroll down until it's above the top of the browser window.
- Do CTRL-F to "find in page" and enter "ee" (no quotes) in the box.
- Hit the up arrow and note the numbers on the left of each hit: 274743, 274738, 274731.
- Hit the down arrow and note that the next hit is 274736. It gets skipped when searching backwards.
|
||
Comment 2•7 years ago
|
||
Hi @dscotese, This issue can be reproduced on:
[Platform affected]: Windows, Mac OS X, Ubuntu 16.04
[Firefox versions]: Nightly 68.0a1, Beta 67.0b12, release 66.0.3
Additionally, I've looked on Google Chrome and even there the same behavior occurs. As a conclusion, I guess, first, we should define which is the properly behavior of this functionality => if by shorting to maximum the Firefox window->CTRL+F ->type "ee"->then clicking on the up arrow = the correspondent results shouldn't be highlighted because the Hash serial isn't visible.
Or, in the 2nd way, this response should render only when the window is on a proper size (the Hash serial being visible).
I will add a component to this issue and dev's team will give us a hand if this is an issue or not.
Thanks for your contribution.
|
|
||
Updated•7 years ago
|
|
|
||
Updated•7 years ago
|
I disagree with the two characterizations of "proper behavior." They are:
- the correspondent results shouldn't be highlighted because the Hash serial isn't visible.
The search function will scroll the page so that the result is visible, so the correct result should be highlighted and the page scrolled to display it. - this response should render only when the window is on a proper size
This response should never render because it has skipped the correct result, which is the line for 273736.
I'd say there are two pieces, and I didn't realize that one of them should be reported as a bug:
- Incremental search backwards sometimes misses a result (as shown in this bug report).
- Sometimes a search result is not visible on the screen. This does not happen when the steps for reproducing this bug are followed. However, a slight modification demonstrates this second bug:
(Step 7.) Hit the down arrow repeatedly until the results bar shows that it's on "1 of 36" and note that the page has not scrolled to the top where this hit is located. Scrolling to the top still doesn't make it visible because its in a <ul> with a height of zero until the mouse hovers over the parent element, but that's more of a third issue.
I noticed that the developer tools will highlight this zero-height element (hover over the HTML in the inspector window), and perhaps that kind of highlight would help users identify "hidden hits" like the occurrence of "ee" in "Careers" as in this example. If you like, I can make a new issue (needs to scroll) or two (feature request: highlight containing element in case the highlighted text is not visible).
Please let me know if my contribution can be improved.
|
|
||
Comment 4•7 years ago
|
||
Hi, @dscotese, I'd say that you should report apart those failures base on what you said on comment 3. How do you define a "proper behavior or a in-proper one"?
In step 5 of the steps I provided to reproduce the bug, proper behavior in response to clicking the up arrow when the highlighted 'ee' is in the line that starts with 274738 is to:
- scroll the page up so that the line that starts with 274736 is at about the middle of the screen (it currently scrolls a bit too far because it's trying to get to the line that starts with 274731 instead of the correct line), and
- highlight the second 'ee' in the line that starts with 274736.
|
|
||
Comment 6•7 years ago
|
||
Hi, @dscotese, what I was trying to say is that on all browsers you will test with the shorten window you get the same result. So, 1st - isn't a mozilla bug. 2nd - That's the reason of waiting the dev's confirmation if is an issue or not.
Yes, you're right. Sorry I didn't understand. I played with it a little more and noticed that the reverse search IS skipping hits in Mozilla and not in Chrome. First, to clarify something: In step 3, scrolling as I described actually fixes the problem, because when row 274736 is above the top of the browser, Firefox doesn't skip it. Firefox skips that row only if it is covered by the nav.scrolling element. In fact, when it's on the first visible hit, it will jump from the hit number it's on to the highest hit number above the top of the window - even though there are earlier (and therefore appropriate) hits hidden under the covering nav.scrolling. Chrome does not skip these.
Firefox has identified 36 hits on the page, but when the first visible hit is highlighted and there is at least one hit hidden by nav.scrolling and you hit the up arrow, it skips the hit(s) that were hidden.
You can see that the size of the window doesn't matter if you search that page for :11: - The first hit is in the first row, so advance to the second hit, and then scroll up or down just enough to hide that first row under the nav bar at the top. Now, when it's hidden, and you hit up to get to the 1st hit again, you'll go to hit number 3.
I'm guessing that there is a difference between two pieces of code that each identify the part of the page that should be searched. The search code uses the entire page, but the code that scrolls to a hit only uses the visible parts of a scrollable area (like the table on the blockchain webpage), which means it will (inappropriately) skip occluded parts of a scrollable area.
I stand by my suggestion that the same "highlighting logic" used in the dev tools (when mousing over an element in the inspector) be used to highlight each hit as it comes up (but also do the scrolling, which the dev tools do not do).
|
|
||
Comment 8•7 years ago
|
||
(In reply to dscotese from comment #3)
- Sometimes a search result is not visible on the screen. This does not happen when the steps for reproducing this bug are followed. However, a slight modification demonstrates this second bug:
(Step 7.) Hit the down arrow repeatedly until the results bar shows that it's on "1 of 36" and note that the page has not scrolled to the top where this hit is located. Scrolling to the top still doesn't make it visible because its in a <ul> with a height of zero until the mouse hovers over the parent element, but that's more of a third issue.I noticed that the developer tools will highlight this zero-height element (hover over the HTML in the inspector window), and perhaps that kind of highlight would help users identify "hidden hits" like the occurrence of "ee" in "Careers" as in this example. If you like, I can make a new issue (needs to scroll) or two (feature request: highlight containing element in case the highlighted text is not visible).
Indeed, this is correct behavior and the difference between semantic and visual matching; we try our hardest to not match any search strings that are not immediately visible to the eye, unless they can be scrolled to.
We often had bugs reported that said things along the lines of 'I have to search through matches that I can't even see!'. So the text may appear in the markup, but that's not all that comprises a document; there's styling and behavior to take into account as well. This is difficult to get right, so there may be bugs, but I'd prefer these to be filed as separate issues.
|
|
||
Comment 9•7 years ago
|
||
I'd like to get to a single ask here, if you don't mind, scotese. What is it specifically that you'd like to see fixed here?
|
Reporter | |
Comment 10•7 years ago
|
||
The fact that the hit counter ("36 of 36") decreases by more than one when you hit the up arrow is enough information for the user who knows what's going on. For everyone else (most people) a simple fix would be to add a modal dialog with a 'I got it, please never show this again.' checkbox that explains "Some hits have been skipped because they are not visible - advancing to them may uncover them."
A better solution is already in a different bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1546259. If highlighting (instead of skipping) a hit which (because it) is not visible is the chosen solution to 1546259 then I think this bug (1544342) should be closed.
|
|
||
Comment 11•6 years ago
|
||
It's been a year and the likelihood of this issue getting fixed is very low. It's very much possible that this behavior has improved over time, since Emilio has landed a number of fixes.
Description
•