RESOLVED FIXED 181331
VoiceOver does not work when the WebContent process is using NSRunLoop.
https://bugs.webkit.org/show_bug.cgi?id=181331
Summary VoiceOver does not work when the WebContent process is using NSRunLoop.
Per Arne Vollan
Reported 2018-01-05 10:40:53 PST
When NSRunLoop is used in the WebContent process, accessibility must be initialized for VoiceOver to work.
Attachments
Patch (3.35 KB, patch)
2018-01-05 10:47 PST, Per Arne Vollan
no flags
Patch (3.44 KB, patch)
2018-01-05 12:13 PST, Per Arne Vollan
no flags
Patch (5.04 KB, patch)
2018-01-08 11:54 PST, Per Arne Vollan
no flags
Patch (6.09 KB, patch)
2018-01-10 08:42 PST, Per Arne Vollan
no flags
Patch (7.33 KB, patch)
2018-01-10 10:09 PST, Per Arne Vollan
no flags
Archive of layout-test-results from ews116 for mac-sierra (3.00 MB, application/zip)
2018-01-10 11:42 PST, EWS Watchlist
no flags
Archive of layout-test-results from ews107 for mac-sierra-wk2 (2.78 MB, application/zip)
2018-01-10 13:42 PST, EWS Watchlist
no flags
Patch (5.91 KB, patch)
2018-01-11 12:53 PST, Per Arne Vollan
bfulgham: review+
Per Arne Vollan
Comment 1 2018-01-05 10:47:04 PST
Brent Fulgham
Comment 2 2018-01-05 11:27:59 PST
Comment on attachment 330558 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=330558&action=review This looks good, but I'm sad we have to instantiate an NSApp instance. We should see if the accessibility team can live without that change (but that's not relevant to this patch). > Source/WebKit/Configurations/WebContentService.xcconfig:56 > +RUNLOOP_TYPE[sdk=macosx10.11*] = _NSApplicationMain; Oh, nice! > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:302 > + NSApp = [NSApplication alloc]; We need to see if allocating an NSApplication causes us to attach to stuff we don't want. So the accessibility code needs an NSApp instantiated to work? Or is this just something that they could potentially fix on their side?
Per Arne Vollan
Comment 3 2018-01-05 11:38:33 PST
(In reply to Brent Fulgham from comment #2) > Comment on attachment 330558 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=330558&action=review > > This looks good, but I'm sad we have to instantiate an NSApp instance. We > should see if the accessibility team can live without that change (but > that's not relevant to this patch). > > > Source/WebKit/Configurations/WebContentService.xcconfig:56 > > +RUNLOOP_TYPE[sdk=macosx10.11*] = _NSApplicationMain; > > Oh, nice! > > > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:302 > > + NSApp = [NSApplication alloc]; > > We need to see if allocating an NSApplication causes us to attach to stuff > we don't want. So the accessibility code needs an NSApp instantiated to > work? Or is this just something that they could potentially fix on their > side? Currently, allocating an NSApplication object is needed for VoiceOver to work, but I believe this could be fixed on their side. Thanks for reviewing!
Brent Fulgham
Comment 4 2018-01-05 11:39:43 PST
Comment on attachment 330558 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=330558&action=review >>> Source/WebKit/Configurations/WebContentService.xcconfig:56 >>> +RUNLOOP_TYPE[sdk=macosx10.11*] = _NSApplicationMain; >> >> Oh, nice! > > Currently, allocating an NSApplication object is needed for VoiceOver to work, but I believe this could be fixed on their side. > > Thanks for reviewing! Can you file a Radar about that and add it as a comment to the place where we make the NSApp allocation?
Per Arne Vollan
Comment 5 2018-01-05 11:42:30 PST
(In reply to Brent Fulgham from comment #4) > Comment on attachment 330558 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=330558&action=review > > >>> Source/WebKit/Configurations/WebContentService.xcconfig:56 > >>> +RUNLOOP_TYPE[sdk=macosx10.11*] = _NSApplicationMain; > >> > >> Oh, nice! > > > > Currently, allocating an NSApplication object is needed for VoiceOver to work, but I believe this could be fixed on their side. > > > > Thanks for reviewing! > > Can you file a Radar about that and add it as a comment to the place where > we make the NSApp allocation? Yes, will do :)
Per Arne Vollan
Comment 6 2018-01-05 12:13:48 PST
Per Arne Vollan
Comment 7 2018-01-08 11:54:46 PST
Anders Carlsson
Comment 8 2018-01-08 16:50:19 PST
Comment on attachment 330717 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=330717&action=review > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:304 > + NSApp = [NSApplication alloc]; > + [NSApplication _accessibilityInitialize]; Calling +alloc without -init is bad.
Per Arne Vollan
Comment 9 2018-01-09 10:46:04 PST
(In reply to Anders Carlsson from comment #8) > Comment on attachment 330717 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=330717&action=review > > > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:304 > > + NSApp = [NSApplication alloc]; > > + [NSApplication _accessibilityInitialize]; > > Calling +alloc without -init is bad. That makes sense. However, we are trying to avoid all initialization of NSApplication, since it should not be needed in the WebContent process. This allocation will be unnecessary when NSApp is no longer needed for VoiceOver to work. Thanks for reviewing!
Per Arne Vollan
Comment 10 2018-01-10 08:42:19 PST
Brent Fulgham
Comment 11 2018-01-10 09:04:31 PST
Comment on attachment 330914 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=330914&action=review > Source/WebCore/ChangeLog:4 > + https://bugs.webkit.org/show_bug.cgi?id=181331 Please put the <rdar> here. > Source/WebCore/platform/mac/ThemeMac.mm:71 > + // Creating a NSWindow will crash if the NSApplication event loop is not running. Creating AN (not Creating A) > Source/WebKit/ChangeLog:4 > + https://bugs.webkit.org/show_bug.cgi?id=181331 <radar> > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:92 > ++ (void)_accessibilityInitialize; We should do this in a header file (Source/WebCore/pal/spi/cocoa/NSApplicationSPI.h), then include that header file here. > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:304 > + NSApp = [NSApplication alloc]; While Anders is correct, I prefer that we not initialize NSApp, since we are trying to get rid of it, and it does bad things (sandbox-wise) when it starts up.
Brent Fulgham
Comment 12 2018-01-10 09:04:59 PST
This patch looks good, but r- until the SPI is moved to our "spi" folder.
Per Arne Vollan
Comment 13 2018-01-10 09:22:01 PST
(In reply to Brent Fulgham from comment #12) > This patch looks good, but r- until the SPI is moved to our "spi" folder. Thanks for reviewing! I will update the patch.
Radar WebKit Bug Importer
Comment 14 2018-01-10 09:36:49 PST
Per Arne Vollan
Comment 15 2018-01-10 10:09:51 PST
Brent Fulgham
Comment 16 2018-01-10 11:09:40 PST
Comment on attachment 330926 [details] Patch Excellent! r=me.
EWS Watchlist
Comment 17 2018-01-10 11:42:16 PST
Comment on attachment 330926 [details] Patch Attachment 330926 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/6023079 New failing tests: http/tests/misc/slow-loading-animated-image.html
EWS Watchlist
Comment 18 2018-01-10 11:42:17 PST
Created attachment 330937 [details] Archive of layout-test-results from ews116 for mac-sierra The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews116 Port: mac-sierra Platform: Mac OS X 10.12.6
EWS Watchlist
Comment 19 2018-01-10 13:42:06 PST
Comment on attachment 330926 [details] Patch Attachment 330926 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/6024538 New failing tests: http/tests/workers/service/postmessage-after-sw-process-crash.https.html
EWS Watchlist
Comment 20 2018-01-10 13:42:08 PST
Created attachment 330956 [details] Archive of layout-test-results from ews107 for mac-sierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews107 Port: mac-sierra-wk2 Platform: Mac OS X 10.12.6
Per Arne Vollan
Comment 21 2018-01-11 12:53:41 PST
Brent Fulgham
Comment 22 2018-01-11 13:09:48 PST
Comment on attachment 331100 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=331100&action=review Assuming the statement about [NSApplication sharedApplication] I made is true, r=me. > Source/WebCore/PAL/ChangeLog:5 > + rdar://problem/36408004 <rdar://problem/3640004> (I.e., angle brackets around the radar URL please!) > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:177 > + [NSApplication sharedApplication]; So I believe that this call causes an alloc and init of NSApplication to occur. Is that correct?
Per Arne Vollan
Comment 23 2018-01-11 13:17:23 PST
(In reply to Brent Fulgham from comment #22) > Comment on attachment 331100 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=331100&action=review > > Assuming the statement about [NSApplication sharedApplication] I made is > true, r=me. > > > Source/WebCore/PAL/ChangeLog:5 > > + rdar://problem/36408004 > > <rdar://problem/3640004> > > (I.e., angle brackets around the radar URL please!) > > > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:177 > > + [NSApplication sharedApplication]; > > So I believe that this call causes an alloc and init of NSApplication to > occur. Is that correct? Yes, that is correct. Thanks for reviewing!
Alexey Proskuryakov
Comment 24 2018-01-11 13:26:17 PST
rdar://problem/36408004 (because comment 22 had a typo, targeting the wrong radar number)
Per Arne Vollan
Comment 25 2018-01-11 14:22:09 PST
Note You need to log in before you can comment on or make changes to this bug.