Version 0.4 cannot be compiled, and version 0.3 has input focus issues

[t1000ln]

Version 0.4 cannot be compiled, and version 0.3 has input focus issues

[MoAlyousef]

Can you try running cargo update and building again?

[t1000ln]

Can you try running cargo update and building again?

Thank you for your guidance. The compilation error issue in version 0.4 has been resolved after the cargo update. This also taught me new skills.
However, the issue of the main window being unable to input still exists, please provide further guidance. Thank you for providing this powerful component.

[MoAlyousef]

On which platform are you noticing the issue?
(guessing it's linux with gnome)

[t1000ln]

Thank you for your reply!

The issue of being unable to input content in the main window occurs in Windows 10 systems.

I tried the same code on Linux, and the page appeared blank, but the main window was able to input text.

In the Windows 10 system, if a web page is displayed in a separate new window, the main window can input characters normally. But this does not meet my interface design requirements.

use fltk::{app, prelude::*, window};
use fltk::group::Flex;
use fltk::input::Input;
use fltk_webview::{FromFltkWindow, Webview};

fn main() {
    let app = app::App::default();
    let mut win = window::Window::default()
        .with_size(800, 600)
        .with_label("Webview");
    let mut flex = Flex::default_fill().column();
    flex.set_margins(150, 5, 100, 5);
    let input = Input::default().with_label("main window input:");
    let mut wv_win = window::Window::default_fill();
    wv_win.end();
    flex.end();
    flex.fixed(&input, 30);
    flex.recalc();

    win.end();
    win.make_resizable(true);
    win.show();

    // let mut wv_win = window::Window::default().with_size(800, 600).center_screen();
    // wv_win.end();
    // wv_win.show();
    let wv = Webview::create(true, &mut wv_win);
    wv.navigate("https://www.google.com/");

    app.run().unwrap();
}

Screenshots of issues on Linux systems:

Screenshots of issues on Windows 10:

Another issue is that when I test multiple calls to the navigate() method on Windows to open a link, the memory will continue to grow. Unless the hide() method is executed before each call to the navigate() method to free up memory, this worries me about memory leaks.
The following is the code that partially addresses this issue in my project.

pub fn open_wv_win(&mut self, url: String, ui: &mut UserInterface) {
        self.window.show();
        self.flex.recalc();

        let wv = Webview::create(false, &mut self.window);
        wv.navigate(url.as_str());

        ui.win_main.show();
        ui.win_main.make_current();
    }

pub fn hide(&mut self) {
        self.window.hide();
    }

Can you give me some advice on how to open and close new links multiple times? Thank you very much!

[MoAlyousef]

I checked on windows with the markdown example and it used to run correctly. I can now see the focus issue.
It seems similar to the one described here:
webview/webview#1053

more from window's WebView2:
MicrosoftEdge/WebView2Feedback#862
MicrosoftEdge/WebView2Feedback#3769
Others as well:
https://github.com/search?q=repo%3AMicrosoftEdge%2FWebView2Feedback+focus&type=issues

Regarding the navigate function, this is the definition:

    /// Navigate to a url
    pub fn navigate(&self, url: &str) {
        let url = CString::new(url).unwrap();
        unsafe {
            webview_navigate(*self.inner, url.as_ptr() as _);
        }
    }

CString is an RAII type, so it handles its own memory, the url is passed as_ptr() not into_raw(), so no leaks there.
If there's a leak it would be from the C library or whatever it calls.

I'll try to search for a fix in the coming days.

[MoAlyousef]

I've pushed a new update. Can you update to fltk-webview 0.4.1 and try on windows.

[t1000ln]

Thank you for your prompt response! I have tested it on a Windows system after updating to v0.4.1, and the issue with input focus has been fixed. The issue of repeatedly calling the navigate() method continuously increasing memory usage (increasing by about 20MB each time) has also been resolved.