EdgeViewer - Modern HTML viewer plugin

[rg_software]

Hi all,

I have created an early version of an HTML viewer plugin, based on MS Edge core. Since it has Chromium under the hood, it should be superior to HTMLView in terms of HTML compatibility. In addition to HTML, the plugin supports Markdown and AsciiDoc, so it can be used instead of my older Markdown plugin.

On the negative side, this version is slower to load (I am considering preloading the engine in the background; TBD) and requires Windows 10 or possibly Win 7/8 with Webview2 Runtime installed.

Your suggestions for eventual improvements are welcome.

[Sir_SiLvA]

Suggestion: make the plugin so that 32- and 64bit can be in the same folder.

[Horst.Epp]

Why is a sub-dir EBWebView created under the Home-dir of TC
and not in the Plugins dir where the viewer plugin itself is installed ?

[deus-ex]

First of all, thank you for your initiative to offer an alternative to the rather old yet working HTMLView plugin.

Your suggestions for eventual improvements are welcome.

Is it possible to add support for showing directories, just like in the old HTMLView plugin? I'm using the HTMLView plugin to display graphic image files as thumbnails in quick-view mode. I find neither of the other available solutions, like the Irfanview plugin or TC's built-in thumbnail view, as convenient to quickly browse through several directories in search of a certain image.

If support for such a thumbnail view is doable, it would be great to be able to configure the size of the thumbnail size, preferably from within the plugin. With the old HTMLView plugin, you can set the thumbnail size by choosing a preset for the thumbnail view in Windows file explorer, but the available options there to choose from are rather limited, especially with regard to high-dpi monitors.

[petermad]

I get the error: "Cannot create WebView2. Error code: 127" when I try to open a .htm file with the viewer under Windows 7, It does open the files under Windows 10 though.

I will try and see if I can download Webview2 somewhere for Windows 7

[rg_software]

OK, some replies to the comments so far:

make the plugin so that 32- and 64bit can be in the same folder.

I had some tech issues wth that, but they are resolved, and the next revision will have a single 32/64 package.

Why is a sub-dir EBWebView created under the Home-dir of TC

This is suggested in the dev guide. TC gives me the "suggested location+name of the ini file where the plugin could store its data. This is <...> the same directory as the wincmd.ini. It's recommended to store the plugin data in this file or at least in this directory, because the plugin directory or the Windows directory may not be writable!"

I didn't think this is something to argue about at all; but if there is any real need for customizing the data directory, I can add it to the ini file.

Is it possible to add support for showing directories, just like in the old HTMLView plugin?

Yes, it is doable. Any idea how to register 'directories' in the extensions list? Maybe I'll have to abandon this list completely, just like HTMLView...

I will try and see if I can download Webview2 somewhere for Windows 7

It is supposed to be here.

[Horst.Epp]

Why is a sub-dir EBWebView created under the Home-dir of TC

This is suggested in the dev guide. TC gives me the "suggested location+name of the ini file where the plugin could store its data. This is <...> the same directory as the wincmd.ini. It's recommended to store the plugin data in this file or at least in this directory, because the plugin directory or the Windows directory may not be writable!"

I didn't think this is something to argue about at all; but if there is any real need for customizing the data directory, I can add it to the ini file.

I use a portable TC tree and don't like having new dirs on the top level which are not belonging to TC itself.
Why don't you store the EBWebView dir inside of your plugins dir ?

[rg_software]

Why don't you store the EBWebView dir inside of your plugins dir ?

"because the plugin directory or the Windows directory may not be writable!" -- says the documentation. I simply comply with the TC-suggested rule. Anyway, I'll make it customizable.

[nsp]

Why don't you store the EBWebView dir inside of your plugins dir ?

I support this as well.

If you look at many plugins that needs specific files it is by default inside plugin folder or configurable. You can use suggested file for simple configuration data. In your case, it is lsplugin.ini where you can create a single section to store configuration data. This does not means that it is the best place for an a plugin internal folder. If it is a cache use %temp%. If it is persistent, the best is to use plugin folder.

All the one that use specific sccop, chocolatey,.... TC installation will have issue with folder under TC root.

[Dalai]

2rg_software
Creating directories without the user's consent is not a good approach. I suggest to make it configurable, or at least partly configurable. My plugins prefer a settings file in their plugin directory, but they fall back to what TC provides if the former is not found.

Example: My Services2 plugin looks for %COMMMANDER_PATH%\Plugins\Services2\Services2.ini (if the plugin is installed there, of couse). If this settings file doesn't exist (which is the default), the location provided by TC - fsplugin.ini - is used. For TC installations this would be somewhere under %AppData%\Ghisler.

If you have to save more data, use a separate file in the same directory provided by TC, just like WebDAV and the SFTP plugin do for example.

Regards
Dalai

[petermad]

2rg_software
I noticed that the plugin does not show images or play sound-clips or show iframe content, if the content file is not in the same folder or a subfolder to the .htm file (on local harddisk). If the images are in a parent dir or a subdir to the parent dir, the images can not be found.

It seems that the plugin sets the current dir to http://local.example/ which is very peculiar - first of all the protocol should not be http:// but file:/// - that results javascript that takes action according to the protocol are fooled.

[rg_software]

if the content file is not in the same folder or a subfolder to the .htm file (on local harddisk)

Yes, true, and related to your next point.

which is very peculiar - first of all the protocol should not be http:// but file:///

In Edge, file:/// protocol is severely restricted in terms of security: many things do not work with it, and the recommended way to proceed is to emulate a web server by binding a specific folder to a fake web address (you can do it with WebView2), hence http://local.example.

Thus, I need to choose something as a root. Maybe I should bind local.example to the disk root, then relative links to parent folders would work.

[petermad]

local.example to the disk root, then relative links to parent folders would work.

Actually the links to the media in my pages are full links, but they are generated according to the protocol and the location of the .htm file

and the recommended way to proceed is to emulate a web server by binding a specific folder to a fake web address

That explains how the plugin can show popup windows with local content, which usually requires that the (cromium) browser is started with the parameters --allow-file-access-from-files --disable-popup-blocking --edge-kiosk-type=public-browsing

[Sir_SiLvA]

Windows 10 Version 22H2 (Build 19045.2130) (64-Bit)
Edge Version 107.0.1418.35 (Offizielles Build) (64-Bit)
Total Commander Version 10.52 (32-Bit)
HTMLView works fine while EdgeViewer.wlx crashes -> https://imgur.com/a/NZtDuSK

How to patch EdgeViewer.wlx64 to have both wlx-files in the same folder:

Code: Select all

EdgeViewer.wlx64 (v1.0 / size 991744 b)
Address:       Old byte        New byte   
E49B8           65              36
E49B9           72              34
Difference: WebView2Loader.dll  -> WebView2Load64.dll 

[AntonyD]

How to patch EdgeViewer.wlx64 to have both wlx-files in the same folder:

Are you sure?
[img]https://i.ibb.co/hFWKLLW/2022-11-06-135006.png[/img]
Here I am exactly on the first mentioned position: offset 0xE4908. And I see byte 57 not your 65.
Maybe you can upload to somewhere ALREADEY pre-patched file?

P.S. I think I found your patch - offset 0xE49B8H
[img]https://i.ibb.co/26gqjck/2022-11-06-135510.png[/img]