Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find is not available in Markdown Preview mode #2187

Closed
gengelbeck opened this issue Jan 22, 2016 · 16 comments
Closed

Find is not available in Markdown Preview mode #2187

gengelbeck opened this issue Jan 22, 2016 · 16 comments
Assignees
Labels
feature-request Request for new features or functionality markdown Markdown support issues webview Webview issues
Milestone

Comments

@gengelbeck
Copy link

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.
@weinand weinand added the feature-request Request for new features or functionality label Jan 23, 2016
@bpasero
Copy link
Member

bpasero commented Jan 23, 2016

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

@bpasero bpasero added upstream Issue identified as 'upstream' component related (exists outside of VS Code) markdown Markdown support issues labels Jan 23, 2016
@bpasero bpasero removed their assignment Jan 23, 2016
@bpasero bpasero added this to the Backlog milestone Jan 23, 2016
@bpasero bpasero self-assigned this Apr 7, 2016
@bpasero
Copy link
Member

bpasero commented Jun 6, 2016

@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
Copy link
Member

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
Copy link

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.

@mjbvz mjbvz self-assigned this Feb 17, 2017
@mjbvz mjbvz removed the upstream Issue identified as 'upstream' component related (exists outside of VS Code) label Feb 17, 2017
@Huachao
Copy link
Contributor

Huachao commented Feb 24, 2017

@mjbvz any updates on this?

@jrieken jrieken added the webview Webview issues label Feb 24, 2017
@kieferrm
Copy link
Member

kieferrm commented Mar 2, 2017

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

@hoovercj
Copy link
Member

hoovercj commented Mar 2, 2017

@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
Copy link
Member

hoovercj commented Mar 12, 2017

@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)
htmlsearch

@mjbvz
Copy link
Collaborator

mjbvz commented Mar 14, 2017

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
Copy link
Member

@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
Copy link
Collaborator

mjbvz commented Mar 14, 2017

@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
Copy link
Member

bpasero commented Mar 15, 2017

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

@hoovercj
Copy link
Member

@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
Copy link
Member

bpasero commented Mar 17, 2017

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

@hoovercj
Copy link
Member

hoovercj commented Mar 17, 2017

@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
Copy link
Collaborator

mjbvz commented Jul 7, 2017

Fixed by #30016

@mjbvz mjbvz closed this as completed Jul 7, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature-request Request for new features or functionality markdown Markdown support issues webview Webview issues
Projects
None yet
Development

No branches or pull requests

9 participants