WordPress.org

Make WordPress Core

Opened 20 months ago

Last modified 5 weeks ago

#42586 new defect (bug)

Code Editor: Inconsistent results between finding in CodeMirror vs browser

Reported by: wpress2010 Owned by:
Milestone: 5.3 Priority: high
Severity: major Version: 4.9
Component: General Keywords: needs-patch
Focuses: accessibility, administration Cc:

Description

When in the Appearance/Editor, f'rinstance, when editing a child theme's CSS file, the Ctrl-F (Search) no longer works. SOMETIMES it will find a string IF that string is on the VISIBLE portion of the screen. It will NOT find that string in the file if the string is NOT visible.

Sometimes it will not find the string at all - visible or not.

A serious impeiment to the Editor!

Attachments (4)

before search.png (121.8 KB) - added by thrijith 20 months ago.
before search
after search.png (107.6 KB) - added by thrijith 20 months ago.
after search
alt-f.png (36.1 KB) - added by sasiddiqui 20 months ago.
Usse alt+f for persistent search as browser instead of ctrl+f
42586.patch (600 bytes) - added by Desertsnowman 20 months ago.
This simply adds Ctrl-F and Cmd-F (keeping . both Mac and PC) bound to findPersistent as extra keys.

Download all attachments as: .zip

Change History (46)

#1 @johnbillion
20 months ago

  • Component changed from Editor to General
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.9.1
  • Priority changed from normal to high
  • Severity changed from normal to major

I just noticed this too. The search (which overrides the built-in browser search) is unusable. It doesn't allow for moving between instances of search results.

#2 @johnbillion
20 months ago

Actually, navigating between results can be done with cmd+g but there's no visual indication of this, like there is with the browser's built-in search.

#3 @melchoyce
20 months ago

Are you getting any console errors? I'm able to search using the code editor's built in search without issue (though there isn't a way to move to the next result or back, but I don't think it ever had that?)

#4 @wpress2010
20 months ago

I am not sure what you are referring to here. The "built-in editor" apparently is only called when you click on the link in the stylesheet file when in the Editor - a new message above the editing area that says,

"Did you know?

There’s no need to change your CSS here — you can edit and live preview CSS changes in the built-in CSS editor."

Foolish message, as I AM editing the child theme's CSS file! This new "feature" is just some kind of "dumbing down" of the admin functions, IMHO.

Is there a way to invoke this "built-in CSS editor" in the actual CSS file? I personally think that making styling changes via the theme's "Additional CSS" Customize tab is BAD practice. That's what a child theme is for!

#5 @dd32
20 months ago

Who's owning this for 4.9.1?

Looking at the editor, I worked out that Cmd+f is search, Cmd+f, Enter then re-opens the search and advances on to the next result
I'd have not guessed that Cmd+g is the next search result (Cmd+shift+g is the previous).
https://codemirror.net/doc/manual.html#addons has a bunch of search related things which might help, but I can't actually tell what if any of those addons are within the minified build we're using.

Sidenote: We're running version 5.29.1-alpha-ee20357 of codemirror, 5.32.0 was released 2 days ago, and there's been 3 releases since it was commited.

Last edited 20 months ago by dd32 (previous) (diff)

@thrijith
20 months ago

before search

@thrijith
20 months ago

after search

#6 @thrijith
20 months ago

there is no ui to jump to next or previous "search term" but it highlights all the "search term" and displays it on the scroll bar. PFA

Edit : attachments added are of version 5.0 but it's working in 4.9 also.

Last edited 20 months ago by thrijith (previous) (diff)

#7 @dd32
20 months ago

@thrijith Is the context of those screenshots a patch which was missed from being attached?

#8 follow-up: @thrijith
20 months ago

@dd32 no it's highlighting the "search term" without any patch in 4.9 but there is no way to to jump from one result to another other than using Ctrl + g for next and Ctrl + Shift + g for previous as you mentioned in your comment.

#9 in reply to: ↑ 8 @dd32
20 months ago

Replying to thrijith:

@dd32 no it's highlighting the "search term" without any patch in 4.9 but there is no way to to jump from one result to another other than using Ctrl + g for next and Ctrl + Shift + g for previous as you mentioned in your comment.

Ah right okay, I don't get the scrollbar highlighting, perhaps because I'm on Chrome for Mac.

#10 @wpress2010
20 months ago

Oddly enough, the problem seems to have resolved itself, and now (at least in Firefox /Win 56.0.2) the search works as expected. Ctrl-F to open the Search box at the top left of the Editor screen, and then F3 to advance to next instance of search target.

When I initially reported the lack of expected Search behavior, Ctrl-F did NOT open the Search box.

#11 @johnbillion
20 months ago

  • Milestone changed from 4.9.1 to 4.9.2

The search behaviour actually varies depending on whether your cursor is focused in the code editor or not. If it is, it uses the code editor search functionality, if not the default browser functionality remains.

Punting due to lack of a patch.

#12 @johnbillion
20 months ago

  • Component changed from General to Customize
  • Focuses accessibility added

#13 @westonruter
20 months ago

  • Component changed from Customize to General
  • Summary changed from Search function in Editor now broken with update to 4.9 to Code Editor: Inconsistent results between finding in CodeMirror vs browder

The only thing I can think of doing here is intercept any “Cmd-F” commands and route them into CodeMirror. This would mean, however, that a user would not be able to do a find to locate a file in the file list, which would be unfortunate. Maybe the solution here would be to show a notice when doing “Cmd-F” when not focused on CodeMirror to prompt the user to focus on CodeMirror to do a find of code.

CodeMirror only loads the current viewport into the DOM, so that is why the browser's find does not match results as it would in a textarea. This is for performance.

Code editor tickets we're keeping in the General component.

Last edited 20 months ago by westonruter (previous) (diff)

#14 @westonruter
20 months ago

  • Summary changed from Code Editor: Inconsistent results between finding in CodeMirror vs browder to Code Editor: Inconsistent results between finding in CodeMirror vs browser

@sasiddiqui
20 months ago

Usse alt+f for persistent search as browser instead of ctrl+f

#15 @sasiddiqui
20 months ago

To have persistent Search, moving to the next position on enter key you need to use alt+f instead ctrl+f.

Here are some keybindings which are used for search/replace functionality.

Ctrl-F / Cmd-F

Start searching

Ctrl-G / Cmd-G

Find next

Shift-Ctrl-G / Shift-Cmd-G

Find previous

Shift-Ctrl-F / Cmd-Option-F

Replace

Shift-Ctrl-R / Shift-Cmd-Option-F

Replace all

Alt-F

Persistent search (dialog doesn't autoclose, enter to find next, Shift-Enter to find previous)

Alt-G

Jump to line

This ticket was mentioned in Slack in #core by jorbin. View the logs.


20 months ago

@Desertsnowman
20 months ago

This simply adds Ctrl-F and Cmd-F (keeping . both Mac and PC) bound to findPersistent as extra keys.

#17 @Desertsnowman
20 months ago

This patch also prevents taking over the browsers Ctrl/Cmd-F as it only works if the editor is selected. Might be good to keep the Alt-F as well for users who already expect that.

Also, the behaviour of findPersistent allows for pressing enter to jump to the next match as well as pressing Cmd/Ctrl-f cycles the matches as well.

Last edited 20 months ago by Desertsnowman (previous) (diff)

#18 @dd32
18 months ago

  • Milestone changed from 4.9.2 to 4.9.3

Bumping to 4.9.3 due to 4.9.2s release

This ticket was mentioned in Slack in #core by desrosj. View the logs.


18 months ago

#20 @SergeyBiryukov
18 months ago

  • Keywords has-patch needs-testing added; needs-patch removed

This ticket was mentioned in Slack in #core by williampatton. View the logs.


18 months ago

#22 @Clorith
18 months ago

The patch looks fine, some considerations from testing it out though:

We should grab some styles for the active search result, currently all search results, and the active one, get the same yellow color, making it impossible to distinguish which one you are currently observing as the active result, this is especially bothersome as you can't "find backwards" if you go too far.

Another is that the current implementation only works if the CodeMirror window has focus, this is not the default state, so if I pick a file to edit and then instantly hit ctrl/cmd+f to find what i need, I'll still get the browser search. It might be worth considering either auto-focusing the editor, or hijacking the search command on the editor pages only to provide a better user experience.

#23 @SergeyBiryukov
18 months ago

In my quick testing, having a persistent search on Ctrl/Cmd+F is indeed more intuitive than using Alt+F, which doesn't work for me on Windows.

Let's get 42586.patch in (but keep Alt+F just in case) and continue iterating in 4.9.4.

#24 @SergeyBiryukov
18 months ago

In 42625:

Code Editor: Add Ctrl/Cmd+F as aliases for persistent search for more intuitive behaviour.

Keep Alt+F as well for users who already expect that.

Props Desertsnowman.
See #42586.

#25 @SergeyBiryukov
18 months ago

In 42626:

Code Editor: Add Ctrl/Cmd+F as aliases for persistent search for more intuitive behaviour.

Keep Alt+F as well for users who already expect that.

Props Desertsnowman.
Merges [42625] to the 4.9 branch.
See #42586.

#26 @SergeyBiryukov
18 months ago

  • Keywords needs-patch added; has-patch needs-testing removed
  • Milestone changed from 4.9.3 to 4.9.4

Let's address comment:22 in 4.9.4.

#27 @dd32
18 months ago

  • Milestone changed from 4.9.4 to 4.9.5

Bumping, 4.9.4 has been released.

This ticket was mentioned in Slack in #core by danieltj. View the logs.


16 months ago

#29 follow-up: @audrasjb
16 months ago

Hello,

As far as I know, it still needs a patch to address comment:22

4.9.5 beta release is planned for next Tuesday so we'll need a patch in the next few days otherwise it will be punted to 4.9.6 (which is not that bad).

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


16 months ago

#31 @audrasjb
16 months ago

  • Milestone changed from 4.9.5 to 4.9.6

Bumping to 4.9.6 due to 4.9.5 beta release.

This ticket was mentioned in Slack in #core by desrosj. View the logs.


15 months ago

This ticket was mentioned in Slack in #core by desrosj. View the logs.


15 months ago

This ticket was mentioned in Slack in #core by desrosj. View the logs.


15 months ago

#35 @desrosj
15 months ago

  • Milestone changed from 4.9.6 to 4.9.7

Punting to 4.9.7 due to lack of progress.

#36 @desrosj
14 months ago

  • Milestone changed from 4.9.7 to 4.9.8

Moving all tickets in 4.9.7 to 4.9.8.

#37 in reply to: ↑ 29 @pbiron
12 months ago

4.9.8 beta release is scheduled for next Tues (July 17).

Any chance comment:22 will be addressed by then or should be punt to 4.9.9?

#38 @pento
12 months ago

  • Milestone changed from 4.9.8 to Future Release

This needs an owner for it to be milestoned.

#39 @afercia
10 months ago

Looking at what's left to do, see comment:22

I see codemirror uses a cm-searching CSS class to highlight all the matches but I couldn't find any CSS class used for the current "active" match so I'm not sure this can be done. Anyone have found a way to do it? Otherwise I'm afraid there's nothing we can do and it should be addressed upstream.

Another is that the current implementation only works if the CodeMirror window has focus, this is not the default state, so if I pick a file to edit and then instantly hit ctrl/cmd+f to find what i need, I'll still get the browser search. It might be worth considering either auto-focusing the editor, or hijacking the search command on the editor pages only to provide a better user experience.

I kindly disagree :)

  • auto-focusing is an option when there's only one, very specific, task to complete and there are no other possible workflows (e.g. landing in a page or a modal with nothing else then a form to fill in). This is not the case in this page, where there are many possible workflows and auto-focusing the editor would be far from ideal for keyboard users
  • native browser functionalities shouldn't be "hijacked" unless there's a really, really, good reason to do that. Making the Alt+F / Ctrl/Cmd+F search limited to the editor area would not allow to search in the rest of the page: as a used, I would like to search, for example, in the list of files in the sidebar (which can be pretty long) or in any other part of the page

@SergeyBiryukov @Clorith given the above, not sure this ticket should stay open :) thoughts?

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


10 months ago

#41 @Clorith
10 months ago

It seems, from a quick glance, that CodeMirror expects you to style selected text for this, as it appears to selected the "active" text.

I understand the disagreement with the find feature though, but I'd like to make a counter-argument here that the editing of files is the primary focus, and that the files list on the side isn't very search friendly if files are in directories (as they will be in many cases). It just felt "unnatural" that I can't just search to find what i need in the code editor right away without extra interactions, but I will admit that I have limited experience with these use cases, and will defer to your experience here.

#42 @desrosj
5 weeks ago

  • Milestone changed from Future Release to 5.3

Let’s wrap this up in 5.3.

Note: See TracTickets for help on using tickets.