WordPress.org

Make WordPress Core

Opened 2 months ago

Last modified 33 hours ago

#42586 new defect (bug)

Code Editor: Inconsistent results between finding in CodeMirror vs browser

Reported by: wpress2010 Owned by:
Milestone: 4.9.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 8 weeks ago.
before search
after search.png (107.6 KB) - added by thrijith 8 weeks ago.
after search
alt-f.png (36.1 KB) - added by sasiddiqui 6 weeks ago.
Usse alt+f for persistent search as browser instead of ctrl+f
42586.patch (600 bytes) - added by Desertsnowman 5 weeks 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 (22)

#1 @johnbillion
2 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
2 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
2 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
2 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
8 weeks 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 8 weeks ago by dd32 (previous) (diff)

@thrijith
8 weeks ago

before search

@thrijith
8 weeks ago

after search

#6 @thrijith
8 weeks 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 8 weeks ago by thrijith (previous) (diff)

#7 @dd32
7 weeks ago

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

#8 follow-up: @thrijith
7 weeks 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
7 weeks 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
7 weeks 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
7 weeks 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
7 weeks ago

  • Component changed from General to Customize
  • Focuses accessibility added

#13 @westonruter
7 weeks 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 6 weeks ago by westonruter (previous) (diff)

#14 @westonruter
6 weeks 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
6 weeks ago

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

#15 @sasiddiqui
6 weeks 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.


6 weeks ago

@Desertsnowman
5 weeks ago

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

#17 @Desertsnowman
5 weeks 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 5 weeks ago by Desertsnowman (previous) (diff)

#18 @dd32
33 hours ago

  • Milestone changed from 4.9.2 to 4.9.3

Bumping to 4.9.3 due to 4.9.2s release

Note: See TracTickets for help on using tickets.