Title: [251847] trunk/Source/WebKit
- Revision
- 251847
- Author
- wenson_hs...@apple.com
- Date
- 2019-10-31 08:23:10 -0700 (Thu, 31 Oct 2019)
Log Message
Add telemetry to test a potential cause of crashes under -[WKContentView _interpretKeyEvent:isCharEvent:]
https://bugs.webkit.org/show_bug.cgi?id=203630
<rdar://problem/56769229>
Reviewed by Simon Fraser.
This iOS-specific crash occurs under `-_interpretKeyEvent:isCharEvent:`, when we first try to access WebEvent's
properties with `event.keyboardFlags`. This suggests that between storing the WebEvent in WebPageProxy's
m_keyEventQueue, and later receiving an InterpretKeyEvent sync IPC message in the UI process, something ends up
overreleasing (or otherwise writing over or corrupting) the WebEvent.
However, from code inspection, nothing appears to overrelease the WebEvent; an alternate possibility is that the
API is somehow being invoked from a background thread, which would explain why the WebEvent may sometimes get
destroyed too early.
To try and detect this scenario (and avoid keeping any strong references to WebEvent at all), add an
`os_log_fault` in case the API is being called on a background thread, and bail immediately.
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView handleKeyWebEvent:withCompletionHandler:]):
Modified Paths
Diff
Modified: trunk/Source/WebKit/ChangeLog (251846 => 251847)
--- trunk/Source/WebKit/ChangeLog 2019-10-31 15:16:42 UTC (rev 251846)
+++ trunk/Source/WebKit/ChangeLog 2019-10-31 15:23:10 UTC (rev 251847)
@@ -1,3 +1,26 @@
+2019-10-31 Wenson Hsieh <wenson_hs...@apple.com>
+
+ Add telemetry to test a potential cause of crashes under -[WKContentView _interpretKeyEvent:isCharEvent:]
+ https://bugs.webkit.org/show_bug.cgi?id=203630
+ <rdar://problem/56769229>
+
+ Reviewed by Simon Fraser.
+
+ This iOS-specific crash occurs under `-_interpretKeyEvent:isCharEvent:`, when we first try to access WebEvent's
+ properties with `event.keyboardFlags`. This suggests that between storing the WebEvent in WebPageProxy's
+ m_keyEventQueue, and later receiving an InterpretKeyEvent sync IPC message in the UI process, something ends up
+ overreleasing (or otherwise writing over or corrupting) the WebEvent.
+
+ However, from code inspection, nothing appears to overrelease the WebEvent; an alternate possibility is that the
+ API is somehow being invoked from a background thread, which would explain why the WebEvent may sometimes get
+ destroyed too early.
+
+ To try and detect this scenario (and avoid keeping any strong references to WebEvent at all), add an
+ `os_log_fault` in case the API is being called on a background thread, and bail immediately.
+
+ * UIProcess/ios/WKContentViewInteraction.mm:
+ (-[WKContentView handleKeyWebEvent:withCompletionHandler:]):
+
2019-10-31 Miguel Gomez <mago...@igalia.com>
[CoordGraphics] Avoid painting backing stores for zero-opacity layers
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (251846 => 251847)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-10-31 15:16:42 UTC (rev 251846)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-10-31 15:23:10 UTC (rev 251847)
@@ -4947,6 +4947,12 @@
- (void)handleKeyWebEvent:(::WebEvent *)theEvent withCompletionHandler:(void (^)(::WebEvent *theEvent, BOOL wasHandled))completionHandler
{
+ if (!isUIThread()) {
+ RELEASE_LOG_FAULT(KeyHandling, "%s was invoked on a background thread.", __PRETTY_FUNCTION__);
+ completionHandler(theEvent, NO);
+ return;
+ }
+
[self _handleDOMPasteRequestWithResult:WebCore::DOMPasteAccessResponse::DeniedForGesture];
using HandledByInputMethod = WebKit::NativeWebKeyboardEvent::HandledByInputMethod;
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
