Page MenuHomePhabricator

Browser Ctrl-F search can't search text outside of current view
Closed, ResolvedPublic8 Estimated Story Points

Description

Steps to reproduce

  1. Make sure Syntax highlighting is on and ready
  2. Open random long article
  3. Ctrl+F
  4. Insert Category: (some part of text, which is at the end of the article and user have to scroll to see it) and hit enter

Expected behavior
If that long article is categorized, text should be found by browser internal search

Current behavior
This fails in CodeMirror as if the text outside of view is not there

Compare screenshots of the same article searched by Opera's search function with syntaxhighlight on and off:

Snímek z 2017-08-29 20-56-01.png (741×1 px, 224 KB)

Snímek z 2017-08-29 20-56-10.png (741×1 px, 168 KB)

Event Timeline

Dvorapa renamed this task from Opera browser search can't search text outside of view to Opera browser search can't search text outside of current view.Aug 29 2017, 7:04 PM
Dvorapa removed a project: SyntaxHighlight.
Niharika renamed this task from Opera browser search can't search text outside of current view to Browser search can't search text outside of current view.Aug 29 2017, 10:52 PM
DannyH set the point value for this task to 8.
DannyH edited projects, added Community-Tech-Sprint; removed Community-Tech.

Maybe we should avoid browser search completely like CodeEditor does and address Ctrl+F and related shortcuts to the WikiEditor (2010)'s own search dialog

This comment was removed by Dvorapa.
DannyH renamed this task from Browser search can't search text outside of current view to Browser Ctrl-F search can't search text outside of current view.Aug 31 2017, 5:12 PM

Change 375402 had a related patch set uploaded (by Niharika29; owner: Niharika Kohli):
[mediawiki/extensions/CodeMirror@master] Implement the search add-on for CodeMirror

https://gerrit.wikimedia.org/r/375402

Maybe we should avoid browser search completely like CodeEditor does and address Ctrl+F and related shortcuts to the WikiEditor (2010)'s own search dialog

Unfortunately, the wikieditor search dialog is not really suited for most of my needs at least. It functions as a popup, and blocks a big part of the window, it does not highlight all the found phrases and it /only/ searches in the text window. Also the way it responds (once you hit enter, it looses focus on the search but turns to the edit text, so if you hit another enter to go to the next instance, it won't - etc) is not what I most frequently need when editing large pages with lots of repetition, or when i'm comparing two pages side by side. I would not support ctrl+F to be activating the wikieditor search dialog. They seem to serve a different purpose.

Maybe try to set viewportMargin to Infinity when ctrl+F pressed?

@Niharika yes, I understand about cost. I would prefer to find a balance between speed and ease of use.

For example render everything on idle. As a variant to set viewportMargin to Infinity when the user does not change the text for some time and return one to optimal size when the user starts editing the text for reduce rendering time.

For example render everything on idle. As a variant to set viewportMargin to Infinity when the user does not change the text for some time and return one to optimal size when the user starts editing the text for reduce rendering time.

I was wondering about that. "render everything on idle". We can try that approach and do some performance testing to see if that's more feasible.

Do remember that 'on idle' is something other than machine performance. If you take an older machine, it won't really matter when you load something, the sheer size (of memory usage and graphics size) will likely do you under. Scroll performance especially will likely tank for those users.

It's worth a try of course, but those problems are likely hard to measure (especially since the worst performing browser platforms also have the least usable metrics facilities). Tough call...

Change 376081 had a related patch set uploaded (by Niharika29; owner: Niharika Kohli):
[mediawiki/extensions/CodeMirror@master] Render everything as long as user doesn't start typing/moving cursor

https://gerrit.wikimedia.org/r/376081

Just to mention that I'm experiencing this issue using Firefox 55.0.3 on Mac OS.

Change 376081 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] Render everything as long as user doesn't start typing/moving cursor

https://gerrit.wikimedia.org/r/376081

For the ticket watchers - the above patch fixes the ctrl+f issues but it might show some lag when editing large articles. If this happens, please report it here along with:

  1. Link to the page/section you were editing
  2. Some detail about the machine you were editing on (for example: Dell, Windows, i5 processor)

Thanks.

Maybe try to set viewportMargin to Infinity when ctrl+F pressed?

https://github.com/codemirror/CodeMirror/issues/4491#issuecomment-271615629

As a side note, I have an idea that I didn't see mentioned either here or in the linked GitHub issue – could CodeMirror render all the "invisible" area, but without syntax highlighting? As I understand, it's the highlighting that is expensive, not plain text. Syntax highlighting would be applied when the text is scrolled into view. I haven't worked with CodeMirror much, so I have no idea if this might be difficult to implement.

kaldari subscribed.

Fixed by setting viewportMargin to Infinity (which may have negative performance implications).

@matmarex: I added your suggestion upstream.

Change 375402 abandoned by Niharika29:
[WIP] Implement the search add-on for CodeMirror

Reason:
We chose to make viewport:Infinity to render it all. Let's see how that goes.

https://gerrit.wikimedia.org/r/375402