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

HTML failing to render on Windows 10 #96

Closed
AveryTheAvian opened this issue Nov 25, 2019 · 12 comments
Closed

HTML failing to render on Windows 10 #96

AveryTheAvian opened this issue Nov 25, 2019 · 12 comments

Comments

@AveryTheAvian
Copy link
Contributor

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!

@nothingismagick
Copy link
Contributor

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

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

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.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-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
Copy link
Collaborator

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

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

@AveryTheAvian
Copy link
Contributor Author

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

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

@AveryTheAvian
Copy link
Contributor Author

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

Sure, go ahead! Thanks!

@AveryTheAvian
Copy link
Contributor Author

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

blckngm commented Dec 25, 2019

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

CommunityToolkit/Microsoft.Toolkit.Win32#50

@AveryTheAvian
Copy link
Contributor Author

@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.

richardhozak pushed a commit that referenced this issue Dec 25, 2019
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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants