[Juce 8] Webview Controller close API is called

General JUCE discussion
1

Hey, so against my better judgement, I wanted to try out having the processor own the WebBrowserComponent (and relays etc), so that if a host decides to destroy the editor when the gui is closed, the webview doesn’t need to do a full reload on reopening (know this isn’t ideal at all, but thought it was worth a try if it makes the gui feel a little less janky).
Assuming a wrapper struct holding the WebBrowserComponent and the relays owned by the processor, I have something along the lines of

PluginEditor::PluginEditor(/*etc*/) { 
    auto& browser = m_processor.getBrowser(); // returns the wrapper..
    addAndMakeVisible(&browser.browser); // .browser is the WebBrowserComponent
}

PluginEditor::~PluginEditor() { 
    auto& browser = m_processor.getBrowser();
    removeChildComponent(&browser.browser);
}

void PluginEditor::resized() { 
    auto& browser = m_processor.getBrowser();
    browser.browser.setBounds(getLocalBounds());
}

This works fine for the first open, but on closing and reopening the gui, a blank page canvas is displayed (Webview state all looks good to me - isShowingBlank is false, etc etc).
On attaching a debugger, the only thing jumping out at me is that this gets repeatedly printed:

WebView is unable to complete this operation because it is no longer valid. Controller close API is called. You shouldn’t call this API after WebView is closed.

I’ve trawled through the code a little, and the only place I could see it explicitly closing the controller is here.
Wondering if there’s something obvious I’m missing, if there’s something fundamentally wrong with my approach, or whether it’s a bug. I did find and necro this issue from last year, but the OP didn’t mention whether they’d managed to fix it or not.
Let me know if you need any further info or anything!

(edit - this is Windows 10, happens with clang-cl and msvc, and the version currently on main)

1 Like
2

I’m receiving the same repeated error message: WebView is unable to complete this operation because it is no longer valid..

3

Hi, my workaround/hack involves working with the AudioEditor object’s getNativeHandle() HWND and manipulating it using various Windows API calls.
Here are the main steps:

  • Create the WebView component and attach it to the editor after the getNativeHandle() HWND is not nullptr (My editor use juce::Timer to check for this).

  • You need an owner for the WebView component; in my case, my processor owns it.

  • Detach the WebView component from the editor before the editor’s HWND is destroyed (I handle the HCBT_DESTROYWND event).

  • When the plugin’s UI is reopened, i.e. editor is recreated, and its HWND is created again, you can reattach (instead of recreating) the WebView component.

1 Like