HTML failing to render on Windows 10 #96

AveryTheAvian · 2019-11-25T19:09:12Z

Prelude

I'm quite new to Rust so it's very likely I've missed something simple! If that's the case I'll apologise now in advance! Any suggestions on how I can provide more information, or further diagnose the issue please do let me know.

System Information: Windows 10 Pro 10.0.18362

The Issue

The issue I'm having is that my example-project application won't render any HTML (it just shows an empty application window) when I execute: cargo run. Interestingly enough though it works perfectly if I run the example_project.exe in the /target/debug directory.

As a side note, if I try to interact with the application window created by cargo run (for example by minimising it) I will get the following fault in my console:

error: process didn't exit successfully: `target\debug\example_project.exe` (exit code: 0xc000041d)

This is probably just a red-herring due to the application being in some unintended state, but for the sake of completeness the application error I get in the Event Viewer is as follows:

Faulting application name: wwahost.exe, version: 10.0.18362.1, time stamp: 0xd44a1ada
Faulting module name: wwahost.exe, version: 10.0.18362.1, time stamp: 0xd44a1ada
Exception code: 0xc0000409
Fault offset: 0x0000000000089f9d
Faulting process id: 0x7034
Faulting application start time: 0x01d5a3c28cde3547
Faulting application path: C:\Windows\System32\wwahost.exe
Faulting module path: C:\Windows\System32\wwahost.exe
Report Id: 7c263c14-97b5-483c-9848-4591a0fa6f63
Faulting package full name: Microsoft.Win32WebViewHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
Faulting package-relative application ID: DPI.Unaware

Full Context

Using a slightly modified elm-counter.rs file as an example I have the following main.rs file:

use web_view::*;

fn main() {
    let file_content = include_str!("index.html");
    println!("Hello World \n\n {}", file_content);
	
    web_view::builder()
        .title("Example Project")
        .content(Content::Html(file_content))
        .size(320, 480)
        .resizable(false)
        .debug(true)
        .user_data(())
        .invoke_handler(|_webview, _arg| Ok(()))
        .run()
        .unwrap();
}

And an index.html file in the same (src) directory:

<html><body><h1>Test</h1></body></html>

The only dependency I have defined in my Cargo.toml file is web-view, but I don't think anything else is required:

[dependencies]
web-view = { version = "0.5.4", features = ["edge"] }

Thank you for your time!

The text was updated successfully, but these errors were encountered:

nothingismagick · 2019-11-25T20:06:29Z

It sounds like something that happens to us at Tauri during the dev process on windows. This following snippet is from the actix example (run it from an administrator console)

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.Win32WebViewHost_cw5n1h2txyewy"

https://github.com/Boscop/web-view/tree/master/examples#actix

AveryTheAvian · 2019-11-25T20:53:30Z

Cheers for the quick response!
Running that command brings back the OK. response, but rebuilding and running the source gives me the same result.

AveryTheAvian · 2019-11-26T22:48:52Z

Out of curiosity I also tried the same source files on Linux (specifically Ubuntu 19.04). Trying to build the project now results in a panic as below:

Compiling webview-sys v0.3.3
error: failed to run custom build command for `webview-sys v0.3.3`
Caused by:
process didn't exit successfully: `/home/michael/rust-apps/example-project/target/debug/build/webview-sys-9020ddaf41e4df7d/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Command { command: "\"pkg-config\" \"--libs\" \"--cflags\" \"webkit2gtk-4.0\" \"webkit2gtk-4.0 >= 2.8\"", cause: Os { code: 2, kind: NotFound, message: "No such file or directory" } }', src/libcore/result.rs:1165:5

If it helps, running the build command with the Backtrace environment variable set provides the following:

stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:76
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:60
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1030
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:64
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:196
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:473
  11: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:380
  12: rust_begin_unwind
             at src/libstd/panicking.rs:307
  13: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  14: core::result::unwrap_failed
             at src/libcore/result.rs:1165
  15: core::result::Result<T,E>::unwrap
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libcore/result.rs:933
  16: build_script_build::main
             at ./build.rs:41
  17: std::rt::lang_start::{{closure}}
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
  18: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:49
  19: std::panicking::try::do_call
             at src/libstd/panicking.rs:292
  20: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  21: std::panicking::try
             at src/libstd/panicking.rs:271
  22: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  23: std::rt::lang_start_internal
             at src/libstd/rt.rs:48
  24: std::rt::lang_start
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
  25: main
  26: __libc_start_main
  27: _start

richardhozak · 2019-11-26T23:00:10Z

Hi, that issue you have on Linux is actually different from the one in Windows, you need to have webkit2gtk library installed on your Linux system so build.rs from webview-sys can find it through pkg-config.

richardhozak · 2019-11-26T23:02:31Z

Also, could you try running your example without the edge feature if you get the same error?

AveryTheAvian · 2019-11-27T20:35:12Z

Ah! Cheers @Zxey for that comment RE: Linux. That's fixed that issue and it's fully working as I expect!

I also updated the cargo.toml file to remove the Edge feature and that's also now functioning on Windows.

Can I please ask what (dependency/dependencies) the Edge feature requires in order to work? I have Edge available on my machine - but I'm assuming it's a specific version it's looking for? Does it need the Preview Chromium based versions?

My understanding is that without this feature, Web-View will fall back to using IE on Windows (which by default is IE7). I can work round this with the necessary registery key changes so that it doesn't use the emulation mode for content (therefore using IE11), but I'd rather rely on the Edge engine if at all possible!

richardhozak · 2019-11-28T08:45:23Z

Edge should not have any dependencies on Windows 10. This is probably a bug I need to look into more.

AveryTheAvian · 2019-11-28T20:31:34Z

Gotcha. Cheers for clariying!

If there's no objections I'll fork this repo and update the documentation to be a bit more comprehensive for newcomers such as myself. I'll see if I can raise a PR sometime this week.

richardhozak · 2019-11-28T21:57:43Z

Sure, go ahead! Thanks!

AveryTheAvian · 2019-12-12T15:18:37Z

So I've been playing around with this on my machine and I thought I'd share my progress.

When using the example code I shared above, and attaching Visual Studio to the process I can see that the crash occurs in webview_edge.cpp when this line is evaluated.

I can also see that the m_webview variable is being set to nullptr before the resize function is invoked:

private:
    void on_message(const char* msg)
    {
        this->invoke_cb(this, msg);
    }

    void resize()
    {
        RECT r;
        GetClientRect(m_window, &r);
        Rect bounds(r.left, r.top, r.right - r.left, r.bottom - r.top);
        m_webview.Bounds(bounds); // Exception and crash occurs on this line.
    }
    WebViewControlProcess m_process;
    WebViewControl m_webview = nullptr; // Suspected cause.
    std::string init_js = "";

    void* user_data = nullptr;
    webview_external_invoke_cb_t invoke_cb;
};

This is the immediate cause of the crash when you try to interact with the application window by minimising it etc as the previous address (say 0x000001da5c4f5d40 {0x000001da5c4f3d10, 0x000001da5c4c8090, 0x000001da5c4c59e0} is now null / 0x0000000000000000 when passed through as the value parameter below):

// Windows.Web.UI.Interop.h
template <typename D> void consume_Windows_Web_UI_Interop_IWebViewControlSite<D>::Bounds(Windows::Foundation::Rect const& value) const
{
    check_hresult(WINRT_SHIM(Windows::Web::UI::Interop::IWebViewControlSite)->put_Bounds(get_abi(value)));
}

This doesn't explain why the content fails to render in the first place (unless I'm missing something obvious), but it also might be interesting to note that I get the same behaviour with all versions of web-view that have the edge feature switch available - namely:

0.5.4 (current)
0.5.3
0.5.2
0.5.1 (first version with edge feature available)

I'm curious if anyone knows of a specific commit / tag etc that is known to work on Windows 10 as intended! Unfortunately my understanding of C++ / C is rather basic so I'm likely to be of little help for actually fixing this! My apologies!

blckngm · 2019-12-25T10:22:39Z

Are you running as Administrator? Edge webview does not work when run as Administrator.

CommunityToolkit/Microsoft.Toolkit.Win32#50

AveryTheAvian · 2019-12-25T13:21:29Z

@sopium That's a brilliant find - I didn't know the Edge webview had such a limitation! Running in standard mode renders the content as expected. I'll update the documentation with a reference to this as it doesn't seem to be a high priority fix in the Microsoft.Toolkit.Win32 repo. This issue can be considered resolved.

Thanks to @sopium the root cause of issue #96 has been identified. As such the `README.md` file has been updated to highlight the fact that the bug exists in the internal Edge WebView implementation (rather than this library's abstraction).

AveryTheAvian closed this as completed Dec 25, 2019

AveryTheAvian mentioned this issue Dec 25, 2019

Update documentation to clarify known issues #113

Merged

obany mentioned this issue Jul 14, 2020

Unable to start dev mode on windows tauri-apps/tauri#781

Closed

Adamkaram mentioned this issue Jan 9, 2021

white screen after build my app ? tauri-apps/tauri#1140

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

HTML failing to render on Windows 10 #96

HTML failing to render on Windows 10 #96

AveryTheAvian commented Nov 25, 2019

nothingismagick commented Nov 25, 2019

AveryTheAvian commented Nov 25, 2019

AveryTheAvian commented Nov 26, 2019

richardhozak commented Nov 26, 2019

richardhozak commented Nov 26, 2019

AveryTheAvian commented Nov 27, 2019

richardhozak commented Nov 28, 2019

AveryTheAvian commented Nov 28, 2019

richardhozak commented Nov 28, 2019

AveryTheAvian commented Dec 12, 2019

blckngm commented Dec 25, 2019

AveryTheAvian commented Dec 25, 2019

HTML failing to render on Windows 10 #96

HTML failing to render on Windows 10 #96

Comments

AveryTheAvian commented Nov 25, 2019

Prelude

The Issue

Full Context

nothingismagick commented Nov 25, 2019

AveryTheAvian commented Nov 25, 2019

AveryTheAvian commented Nov 26, 2019

richardhozak commented Nov 26, 2019

richardhozak commented Nov 26, 2019

AveryTheAvian commented Nov 27, 2019

richardhozak commented Nov 28, 2019

AveryTheAvian commented Nov 28, 2019

richardhozak commented Nov 28, 2019

AveryTheAvian commented Dec 12, 2019

blckngm commented Dec 25, 2019

AveryTheAvian commented Dec 25, 2019