Determine cause for window's activation

So is there any way to prevent a Windows Webkit html viewer from bringing its window to the front when using LoadPage? I’m trying to work around it by grabbing the current frontmost window and bringing it back to the front after using LoadPage but it’s obviously not a good solution.

There have been reports of this before - see for example:

<https://xojo.com/issue/58757>
<https://xojo.com/issue/56107>
etc.

Yes, both of those cases do have “webkit” and “focus” in there, but they are different issues and they’ve already been fixed.

I guess I’ll just submit a case and do the long waiting game:
<https://xojo.com/issue/63479>

Hide the window insted of closing it ?

Sorry not sure what you’re saying. I don’t want any windows to close/hide/lose focus. Just want to reload an HTML viewer in a non-focused window without it coming to the front.

So now you’ve got me wondering. Why are you refreshing an invisible HTML Viewer?

Window 1 is in the background but visible with an HTMLViewer that gets periodically updated.

The user is doing something in Window 2.

When the HTMLViewer refreshes it brings Window 1 to the foreground and steals focus from Window 2. Only on Windows and only when WebKit is the renderer.

I meant more of why. It’s difficult to justify the need for a whole HTMLViewer if it’s not even visible. I’m wondering if we can get you on the path of URLConnection.

I don’t know where you’re getting the idea that it’s not visible. The HTMLViewer is visible. It displays a page to the user. It’s in the app’s main window, that is almost always open, and visible.

If the user is doing something in a secondary window and the main window refreshes its HTMLViewer, it brings the main window to focus when it should not.

Gotcha! Just tryin’ to see if we can work around issues and keep development moving :slight_smile:

Thanks and no problem. Right now I’m leaning towards just preventing any updates to the background windows on Windows but that’s not a great solution.

I can reproduce the issue in your project, but if I switch to LoadPage it goes away.

What if you use a URLConnection to grab the content of the page, then use LoadPage to load it?

In the original project it was LoadPage and in my app it’s also load page. Does it for both for me. I added a second project to the case that reproduces the issue.

Load page might require a different URL or file each refresh for it to trigger.

Just checking that you’ve tried this using the IE11 rendering engine? Modern IE11 is pretty good, but you have to set the registry keys and do some other magic to enable it in the plain HTMLViewer. See sample code in HTMLViewer (deprecated) — Xojo documentation

I’m watching this also, and have spoken to @William_Yu about it.

1 Like

This case is now marked as fixed and awaiting verification.

4 Likes

Whoa, that was impressively fast!

1 Like

This is a pretty big issue if you use HTMLViewers, which is becoming more and more the norm. I can’t imagine the havoc it might cause if you were using modals, let alone the fact that a background app stealing focus while working in an entirely different app is just awful.

Glad to see this one get fixed quickly. And thanks to @William_Yu for making it happen!

2 Likes