Find is not available in Markdown Preview mode

[gengelbeck]

Find is not available in Markdown Preview mode

Feature Request?

This may be a feature request, but I would like to search my Markdown in Preview Mode.

Currently this action is not available.

Repro Steps

1. Create a markdown document
2. Go to Preview Mode
3. Try a Find - Ctrl-F (Cmd-F)
4. Find is not available.

[bpasero]

This might require upstream support in Electron to reveal the native find box.

[bpasero]

@jrieken @kieferrm fyi would be cool to be able to get native search working in the webview. I think there is API: https://github.com/electron/electron/blob/master/docs/api/web-view-tag.md#webviewfindinpagetext-options

[hoovercj]

This is needed, especially now that "release notes" get opened in the editor. There is no way to search through the release notes to find information.

Another use case: I bundle a handful of examples and doc/manual pages with an extension that I open using previewHTML and the docs are unsearchable. Currently the only alternative I know is to open the files directly, which allows them to be searchable but also editable and poorly formatted which is undesirable.

[mholtzhausen]

Is there any movement on this issue? There is a very useful extension that allows opening the README.md files of node_modules right from the require statement. The feature is hamstrung by the fact that previews are unsearchable.

[Huachao]

@mjbvz any updates on this?

[kieferrm]

It hasn't made it yet high enough on our backlog. Sorry about that.

[hoovercj]

@kieferrm @mjbvz I briefly looked into this last week to see whether a PR for this was possible. I could easily tap into the webview api manually using the devtools and it worked well. The hard part was trying to use the existing "find/replace" widget. The existing contribution exists in code editors which the html preview is not.

So my questions are:

1. Are you open to a PR on this issue?
2. Does it seem possible (or desireable) to use the exisiting find widget? For UI consistency this seems desireable to me but only if the widget can be customized to not show the replace box and the regex option. If so, any tips on HOW to reuse it would be great.

[hoovercj]

@mjbvz and @kieferrm I don't see any mention of this issue in the march milestone (too many other great things on the list :D ), so I looked into how @mjbvz's closed PR could be combined with the new preferences search widget and put together a quick prototype of search. As you can see in the .gif below, I've put zero work into the UI, only repurposed the pieces from the preferences search, but it works really well.

There are a couple other features that are in or hopefully will be in with the next release (passing contents to a new untitled file and an option to preserve focus for HTML previews), and this search in HTML preview is the last big feature needed to complete an end-to-end story for one of my extensions, so getting this in the march release would help me out, and I'm sure it would help others, too.

If the team is interested, I'd love to keep working on this to help close this issue and take some work off of your plates. My main concern is that #18383 is closed so I don't want to rely on that if it was closed because there is a better approach/critical flaw in it.

(note: forgive the gif lag, my laptop freaks out when I record gifs)

[mjbvz]

Glad to see that you are looking into this. Sorry for not responding sooner.

I don't think there was anything technically wrong with the approach in #18383, we just didn't have a need for it in the end.

This feature is certainly something we would like supported and your prototype looks very promising. Is there anything blocking you currently or anyway we could help you out? If you share your code, I'd also be happy to provide feedback on the work so far

[hoovercj]

@mjbvz there's nothing blocking me from a "can I make something work" standpoint. However, making something you'll merge is a different story :-)

The main consideration at this point is the UI (which then drives some technical aspects). The simpler it is, the easier it is to contribute as a community member. If it can be a simple input box with placeholder text like 'Find in page...' and no buttons (relies on enter/shift+enter), I can get a PR together easily.

If it needs buttons (previous/next/close), I just need guidance on whether I should be:

• Reusing base/browser/ui/findInput
• Rolling my own simpler find input that copies the look of the code editor find
• Styling the find to look like chrome's so it matches the "htmlPreview is like a browser" idea

Also, if I need to include my own styles, I could use a quick explanation of how the css imports work. It is magic to me that import 'vs/css!./findInput'; at the top of findInput.ts somehow imports a css file :-)

[mjbvz]

@alexandrudima and @bpasero may be able to speak more to this, but ideally I would see this reusing the findWidget, with the options for regexp search and case sensitive search hidden. This would presumably be backed by a new findModel to handle interaction with the webview.

The advantage of reusing these components is that the experience would be consistent with the rest of the editor. We would also get a lot of functionality for free, such as search history. But I'm not sure how easy generalizing these objects will be

[bpasero]

+1 for having the same search experience in editor and preview (= find widget).

[hoovercj]

@bpasero @mjbvz

I had initially tried to reuse FindWidget and I've looked into it again, but I'm caught up on the fact that HtmlPreviewPart extends BaseEditor, but FindWidget expects an ICodeEditor which looks to me to be a completely different class hierarchy.

The parts of ICodeEditor that the FindWidget relies on are:

• Configuration
  • getConfiguration() to get the layoutInfo.width to determine whether to use the narrow/reduced/collapsed find widget.
  • onDidChangeConfiguration to determine the readOnly state to decide if replace should be available
• Selection
  • onDidChangeCursorSelection to determine if toggleSelectionFindButton should be active
  • getSelection() to determine which text to find through
• Overlay
  • addOverlayWidget to add itself as an overlay widget
• Actions
  • getAction to run actions like next/previous

It seems that HtmlPreviewPart would need to implement these things to use the FindWidget. Does that sound right?

[bpasero]

@hoovercj shouldn't you be looking at FindInput instead?

[hoovercj]

@bpasero I can look there instead, yes, but you both mentioned FindWidget specifically and FindWidget is the class that actually has the buttons, the results label, etc.

But I can absolutely look at just using the FindInput and draw inspiration from how FindWidget uses it to build a similar search experience (minus regex, etc.).

[mjbvz]

Fixed by #30016