Requests view loses focus when Webview tab is selected and shown page asks for focus

[seidnerj]

Description

When iterating through the requests view (with the keyboard keys), if the Webview is selected and the page it is rendering asks for focus for one of its elements, the Webview gets focus and the requests view loses focus, which in turn means that the keyboard keys (e.g. up/down which are particularly relevant) no longer have any effect on the requests view and you cannot continue to iterate through the requests without refocusing on the requests view with the mouse pointer.

Steps to Reproduce

1. Configure a browser to use Proxyman
2. Browse to a page that has an element that requests focus (e.g. Amazon login page).
3. Select the Webview tab
4. Iterate through the various requests in the requests view using the up/down keys.
5. When arriving at the request corresponding to no. 2 mention above, the requests view loses focus and further presses on up/down are redirected to the Webview tab window.

Current Behavior

When iterating through the requests view (with the keyboard keys), if the Webview is selected and the page it is rendering asks for focus for one of its elements the requests view loses focus.

Expected Behavior

The requests view should retain focus.

Environment

• App version: Proxyman 4.12.0 (49300)
• macOS version: macOS Sonoma 14.0

[NghiaTranUIT]

Thanks. I'm not sure if I can fix it because the WKWebview will always steal the app focus if it's requested by Webview UI. It's intended behavior.

I did a quick research and there is no public variable to disable it.

[seidnerj]

I will research a method to fix this and will update the thread when I have more information. Thanks!

[seidnerj]

For my specific scenario, I ended up using the scripting capability to modify the body of the response and remove a class from the offending elements.

For a more general solution, this is a bit of a hack but you could do something like add an event listener / timer that checks what element is in focus at any given moment and saves that. Then, it checks if the current element is the Webview tab and the previous elements was not the Webview tab AND no user action was done to change the focus to the Webview tab (i.e. click on that tab), then return the focus to the previous element.

[NghiaTranUIT]

WKWebView allows me to inject a custom Javascript after the website is loaded. I guess I can use one of sample code to disable all input focus.

[seidnerj]

Actually, I think the code you linked to, would not help in the scenario we’re discussing because it will happen after page load, and so the elements would already have been focused and the focus would have moved to the Webview (unless defocusing the elements also defocuses the Webview, which I highly doubt).

We need to prevent the elements from getting focus in the first place.

If we could find a code snippet that subscribes to an event that fires once an element focuses and cancels the action then this might work.

Of course, this can potentially corrupt the rendering of the page so its a bit risky.

[seidnerj]

Take a look here:

https://www.appsloveworld.com/swift/100/7/catch-javascript-event-in-ios-wkwebview-with-swift?expand_article=1

I guess you could catch all javascript focus events, then delegate it to your native code which will return the focus to the previous element in Proxyman.