Bug 274818 – WKWebView randomly stops receiving mouse events

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: UI Events

[Jinyu Meng]

Created attachment 471534 [details]
Demo app to reproduce.

When the bug happens, the mouse will stop working on WKWebView completely. 
Click won't work. Right-click won't work. You can't open a context menu on it. The mouse cursor even won't show as "hand" on links.
It happens so randomly. It's hard to determine when it happens.
Scrolling and keyboard events still work.

Steps to reproduce:
0. Using the latest macOS/Xcode.
1. Create an empty app with WKWebView and two buttons to load URLs. The first URL can be anything you want, but it should be simple to save testing time. The second URL should be ChatGPT or Discord. This bug can also happen on other sites, but reproducing using these two is easier. (I don't know why.)
2. Click two buttons to let WKWebView navigate again and again.
3. Bug happens randomly. Then you can't click on the WKWebView anymore. Before you destroy this instance of WKWevView and create a new one, the problem won't be resolved.

It affects multiple third-party WebKit browsers, such as Orion and MenubarX. It happens so randomly, I'm so confused now.

I included a Demo app for you to test. There is also a video showing what it looks like when the bug happens. See how the mouse cursor changes when I move it onto the page.

[Alexey Proskuryakov]

Thank you for the report. It sounds like this would be difficult to reproduce. When you can make it happen, it may be a good idea to file a Feedback Assistant report with a sysdiagnose (please post its ID if you do).

[Simon Fraser (smfr)]

Could you tell us which macOS version you are testing on?

[Radar WebKit Bug Importer]

<rdar://problem/128962118>

[Jinyu Meng]

(In reply to Simon Fraser (smfr) from comment #2)
> Could you tell us which macOS version you are testing on?

I'm on the latest version 14.5 (23F79).

[Jinyu Meng]

Created attachment 471556 [details]
Memory samples while the bug happens

[Jinyu Meng]

(In reply to Alexey Proskuryakov from comment #1)
> Thank you for the report. It sounds like this would be difficult to
> reproduce. When you can make it happen, it may be a good idea to file a
> Feedback Assistant report with a sysdiagnose (please post its ID if you do).

I reported it with FB13814365. I also uploaded memory samples of related processes here on Bugzilla. Please check them out. Feel free to tell me if you need any additional information.

[Simon Fraser (smfr)]

To reproduce more easily, wiggle the mouse fast after clicking in the document loading by the left button.

[Simon Fraser (smfr)]

This was fixed by bug 273924.

[Jinyu Meng]

(In reply to Simon Fraser (smfr) from comment #8)
> This was fixed by bug 273924.

I tried to run this demo with the latest WebKit I built locally before submitting this bug. My local webkit is on 102aa1b, after the commit in that PR. Are you sure it's fixed?

[Jinyu Meng]

Did I do anything wrong while attempting to run my demo with locally built WebKit?

sudo Tools/Scripts/run-webkit-app /Users/megabits/Library/Developer/Xcode/DerivedData/TestWebKit-fcmryqzqjbceztbdxyapwumaazyk/Build/Products/Debug/TestWebKit.app --debug

[Jinyu Meng]

I reproduced it again with the latest main d5b3ed8.

[Jinyu Meng]

btw, Can you tell me how I can confirm the demo app is running with the WebKit I built?

[Wenson Hsieh]

(In reply to Jinyu Meng from comment #12)
> btw, Can you tell me how I can confirm the demo app is running with the
> WebKit I built?

One quick way to verify whether or not it's properly using your custom WebKit (as opposed to system WebKit) is to either use Activity Monitor and examine the "Open Files and Ports" section for TestWebKit, to check whether WebCore.framework, JavaScriptCore.framework, and WebKit.framework are coming from a `/Users/…` or from a system path.

Another way is to `sample TestWebKit` briefly while it's running, and check the list of linked dylibs at the bottom of the output. The path to each dylib is printed out, and you can check where WebCore/JSC/WK is pointing to.

[Jinyu Meng]

(In reply to Wenson Hsieh from comment #13)
> Another way is to `sample TestWebKit` briefly while it's running, and check
> the list of linked dylibs at the bottom of the output. The path to each
> dylib is printed out, and you can check where WebCore/JSC/WK is pointing to.

Thank you for telling me that. It seems the app is still using the system webkit. What did I do wrong? The run-webkit-app script didn't give me any error. Do I need to disable SIP to let it use my own WebKit?

[Alexey Proskuryakov]

You shouldn't need to disable SIP, unless your app uses hardened runtime. `sudo` seems wrong, but should be harmless AFAIK.

Is your local build a debug ore release one?

[Jinyu Meng]

(In reply to Alexey Proskuryakov from comment #15)
> You shouldn't need to disable SIP, unless your app uses hardened runtime.
> `sudo` seems wrong, but should be harmless AFAIK.
> 
> Is your local build a debug ore release one?

A new macOS project comes with hardened runtime by default. But I tested it after I removed that, and nothing changed.
I have both debug and release versions. And I tried both. None of them works.

[Jinyu Meng]

I just tried to insert the DYLD_FRAMEWORK_PATH variable manually in Xcode. And it seems to work! Does that mean there is a bug in that start script?

By the way, the issue I reported disappeared. I can confirm it's fixed!

[Alexey Proskuryakov]

> Does that mean there is a bug in that start script?

Actually, there might be indeed. When one is launching an app and not a CLI binary, it goes here (in webkitdirs.pm):

return system("open", "-W", "-a", $appPath, "--args", argumentsForRunAndDebugMacWebKitApp());

And with SIP enabled, `open` would lose DYLD environment variables. We probably need to do the same as in the code path below, passing archCommandLineArgumentsForRestrictedEnvironmentVariables(). It would also have to be renamed if used for `open` in addition to `arch`.

I don't have a proper OS to quickly test this, would you be willing to see if this makes it work as expected? Or perhaps even post a PR to fix this, if you want to.

[Jinyu Meng]

(In reply to Alexey Proskuryakov from comment #18)
> I don't have a proper OS to quickly test this, would you be willing to see
> if this makes it work as expected? Or perhaps even post a PR to fix this, if
> you want to.

I did what you said, and it worked! I will post a PR later!

[Jinyu Meng]

I posted a new bug report https://bugs.webkit.org/show_bug.cgi?id=275207 to track this.