| Summary: | AX: Crash in WebKit::WebPageProxy::registerWebProcessAccessibilityToken | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | chris fleizach <cfleizach> | ||||
| Component: | Accessibility | Assignee: | chris fleizach <cfleizach> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | commit-queue, webkit-bug-importer | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
Created attachment 221815 [details]
patch
Comment on attachment 221815 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=221815&action=review > Source/WebKit2/UIProcess/mac/WebPageProxyMac.mm:390 > + if (!isValid()) > + return; Is it semantically correct to ignore this call, or should the data be queued and sent once the process is (re)started? (In reply to comment #2) > (From update of attachment 221815 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=221815&action=review > > > Source/WebKit2/UIProcess/mac/WebPageProxyMac.mm:390 > > + if (!isValid()) > > + return; > > Is it semantically correct to ignore this call, or should the data be queued and sent once the process is (re)started? Good question. I should play with this some more Comment on attachment 221815 [details] patch Clearing flags on attachment: 221815 Committed r164887: <http://trac.webkit.org/changeset/164887> All reviewed patches have been landed. Closing bug. |
37 com.apple.WebKit2: WebKit::WebPageProxy::registerWebProcessAccessibilityToken + 11 <== 37 com.apple.WebKit2: WebKit::WebPageProxy::didReceiveMessage + 7257 37 com.apple.WebKit2: CoreIPC::MessageReceiverMap::dispatchMessage + 125 37 com.apple.WebKit2: WebKit::ChildProcessProxy::dispatchMessage + 13 37 com.apple.WebKit2: WebKit::WebProcessProxy::didReceiveMessage + 24 37 com.apple.WebKit2: CoreIPC::Connection::dispatchMessage + 101 37 com.apple.WebKit2: CoreIPC::Connection::dispatchOneMessage + 106 28 com.apple.WebCore: WebCore::RunLoop::performWork + 270 | 28 com.apple.WebCore: WebCore::RunLoop::performWork + 34 | 28 com.apple.CoreFoundation: __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 | 28 com.apple.CoreFoundation: __CFRunLoopDoSources0 + 242 | 28 com.apple.CoreFoundation: __CFRunLoopRun + 831 | 28 com.apple.CoreFoundation: CFRunLoopRunSpecific + 309 | 28 com.apple.HIToolbox: RunCurrentEventLoopInMode + 226 | 28 com.apple.HIToolbox: ReceiveNextEventCommon + 479 | 28 com.apple.HIToolbox: _BlockUntilNextEventMatchingListInModeWithFilter + 65 | 28 com.apple.AppKit: _DPSNextEvent + 1434 | 28 com.apple.AppKit: -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 | 28 com.apple.AppKit: -[NSApplication run] + 553 | 28 com.apple.quicklook.ui.helper: main | 28 libdyld.dylib: start + 1 9 com.apple.WebCore: WebCore::RunLoop::performWork + 557 9 com.apple.WebCore: WebCore::RunLoop::performWork + 34 9 com.apple.CoreFoundation: __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 9 com.apple.CoreFoundation: __CFRunLoopDoSources0 + 242 9 com.apple.CoreFoundation: __CFRunLoopRun + 831 9 com.apple.CoreFoundation: CFRunLoopRunSpecific + 309 9 com.apple.HIToolbox: RunCurrentEventLoopInMode + 226 9 com.apple.HIToolbox: ReceiveNextEventCommon + 479 9 com.apple.HIToolbox: _BlockUntilNextEventMatchingListInModeWithFilter + 65 9 com.apple.AppKit: _DPSNextEvent + 1434 9 com.apple.AppKit: -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 9 com.apple.AppKit: -[NSApplication run] + 553 9 com.apple.quicklook.ui.helper: main 9 libdyld.dylib: start + 1 <rdar://problem/15723355> <rdar://probl;e