Set origin with NavigateToString

[jhandley]

When setting HTML to display using ICoreWebView2::NavigateToString I would like to be able set the origin URL used by the browser for the page like you can do with the Android WebView method loadDataWithBaseURL

The origin URL would be used as the base for relative paths for resources. This allows you to set an HTML string that refers to images, scripts and stylesheets that are stored separately. In my case, on Android I set the base URL to a file:// and store images and stylesheets in that directory on disk.

I tried to simulate this using AddWebResourceRequestedFilter but the events only fire for http/https URLs so relative paths in HTML set by NavigateToString do not trigger these events.

I will try to make this work by writing out the HTML to a temporary file and use Navigate with a file:// url but I'd much rather avoid that using the same technique that I'm using on Android.

AB#29796279

[pagoe-msft]

@jhandley - I've added this feature request to our backlog!

[billhenn]

I'm running into the same thing. I'm trying to use a WebView2 to browse a dynamically-generated "preview" file of some HTML. I'd ideally like to use NavigateToString() to keep the preview HTML from every being written to disk, but if I do so, there seems to be no way to dynamically provide it the CSS, images, etc. that are referenced in the HTML since AddWebResourceRequestedFilter doesn't seem to currently work for NavigateToString(). This then makes NavigateToString() effectively useless.

There are two issues here that I'd like to see resolved:

1. AddWebResourceRequestedFilter should have the same feature set for NavigateToString() browsings as for files browsed on disk. If it did, we then could dynamically provide all CSS and images on the fly without ever having to even touch the disk.

2. I love the idea of a "base URL" suggested by @jhandley since in some cases I can see scenarios where we do have the CSS/images already on disk and we want our virtual "preview" file to just think it's in a certain folder so that it can reference them the same as if if it were written on disk.

If both of these issues were resolved, that would make dynamic HTML viewing MUCH better using WebView2. Without those essential things (at least #1 but preferably both), we may have to go look at CefSharp instead, which we would prefer not to do. Thanks for considering adding them.

[jhandley]

@billhenn I ended up using cpp-httplib to run a local web server to serve the content rather than writing it to disk. It is pretty lightweight and easy to set up. For dynamically generated html you can use httplib::Server::Get() to map a url to a lambda that generates the response. If you have files on disk you can use httplib::Server::set_mount_point() to map a url to a folder on disk and it will serve files from that folder. You can combine the two so that http://localhost:1234/foo.html maps to a lambda and any other request to http://localhost:1234 gets mapped to a folder on disk.

[ukandrewc]

@jhandley The events do fire for file:// protocol, but you need to navigate to a file.

@billhenn Can't you just include the resources in the string?

[billhenn]

Thanks for the tip @jhandley, but we write our software in C#, so I'm not sure that would work for us. Regardless, with these couple relative minor enhancements to WebView2, none of this extra effort would be needed and building dynamic previews would be really easy.

@ukandrewc - I'd rather not parse the HTML to try and locate CSS, images, etc. and then inject them inline somehow. I'd like to be able to serve them up on request from WebView2 using the existing events. It's just that the events aren't raised unless the HTML file is on the file system, which is the main issue.

[jhandley]

@billhenn In C# you could probably do something similar with HttpListener but of course would be much simpler for all if WebView2 was enhanced.

[ukandrewc]

@billhenn After I thought that through, I did think it could get tricky ;-)

Do you mind if I ask why you don't want to use a temp file for your content?

[billhenn]

@ukandrewc In one usage scenario, I do write out a temp file for the HTML preview. However the problem is I need to leave it out there until the next render or when the app closes since the WebView processes it asynchronously. I had originally tried deleting it when the WebView2 indicated the content was rendered, but if another preview update request came in there in between, the WebView2 would sometimes show a not found error. Anyhow, all the messing around and managing of preview files gets annoying and if the app crashes, it leaves the preview file there. It all would be much cleaner to simply use NavigateToString() and be able to set the virtual base path.

[ukandrewc]

@billhenn In that case, you could use a skeleton HTML and fill the body from JS?

I do that for a print preview, where I write and navigate to a file on startup with:
<html><head><!--stylesheet, etc--></head><body></body></html>
then add body.innerHTML from ExecuteScriptAsync.

That way, I only navigate once and just change the content when needed.

[billhenn]

@ukandrewc I have a folder hierarchy so the preview could be in any folder. Ideally I wouldn't ever have to write anything to the file system myself if the requested features were added.

[ukandrewc]

@billhenn Fair enough, just a suggestion ;-)

[billhenn]

I appreciate the suggestions @ukandrewc. The app I'm making is a Markdown editor that needs a HTML preview. The Markdown files can be in a large folder hierarchy so I need to be able to preview them at any level. If I write a "~preview.html" file containing the Markdown-to-HTML rendering to the folder where the Markdown file lives, then WebView2 works great. But per what I described above, I really don't want to have to write anything to the file system since the "~preview.html" files stick in the folder until the next preview occurs.

[ukandrewc]

@billhenn Completely understand, I'm just used to working from files, so it seems counter intuitive (to me) to not use temp files. I also find an advantage of easier debugging when I've written some rubbish that's supposed to be HTML ;-)

The only other thing I do is to use a hash of the user path, and save to my own cache folder. Rather than saving to the user's folder.

I can see that what you are asking for, is the same as WebBrowser control, and would be an advantage.