Text search doesn't work on github code line numbers |
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Example URL: https://github.com/nwjs/chromium.src/blob/nw22/ui/chromeos/touch_exploration_controller_unittest.cc Steps to reproduce the problem: 1. Open any github source file 2. Open text search box (Ctrl-F) and type existing line number (like 1234 in the given URL) 3. Chrome doesn't highlight line number that was searched for. What is the expected behavior? Chrome should be able to find github line numbers like any other test on the page. What went wrong? Text can't be found, even though it clearly appears on the page. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? No FireFox 53 Chrome version: 58.0.3029.110 Channel: stable OS Version: 58.0.3029.110 (64-bit) Flash Version: Same goes for numbered lists everywhere. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ol
,
May 12 2017
As you can see the line numbers are created via CSS pseudo selector:
.blob-num::before {
content: attr(data-line-number);
}
This text is not part of the user-selectable page text, which might be the very reason github site uses it.
If you want to go to a specific line, append #L123 to the page URL, 123 being the line number.
,
May 12 2017
FWIW, github site provides a hotkey to go to a user-specified line: L
,
May 12 2017
,
May 12 2017
I understand that there are some web technicalities that make this text not quite normal. But I don't think that it justifies breaking natural assumption users have - if I can see it, I can find it.
,
May 12 2017
,
May 12 2017
Just in case, I think I have to nitpick on this: >if I can see it, I can find it. Images are visible too and sometimes have text, and I'm quite sure some users would expect the browser to find it too. I'd say a more general rule is "if I can select it, I can find it" which is the current behavior.
,
May 16 2017
Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.4 using chrome version 58.0.3029.110 and canary 60.0.3100.0. This is non regression issue as the issue seen from M30 old builds. Marking it as Untriaged to get more inputs from dev team. Thanks,
,
May 16 2017
Both Firefox and Safari behave the same way so I'm not sure we should change anything but whoever owns FindInPage can decide.
,
Aug 21
Archiving old bugs that haven't been actively assigned in over a year. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks! |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ezemtsov@google.com
, May 12 2017