Bug 233791

Summary:

AX: Attempting to play local media files as part of a speech study causes Safari to hang.

Product:

WebKit

Reporter:

chris fleizach <cfleizach>

Component:

Accessibility

Assignee:

chris fleizach <cfleizach>

Status:

RESOLVED WONTFIX

Severity:

Normal

CC:

andresg_22, cdumez, eric.carlson, ews-watchlist, glenn, jer.noble, philipj, sergio, tyler_w, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

WebKit Nightly Build

Hardware:

All

OS:

All

Attachments:

Description	Flags
patch	none
patch	andresg_22: review+

Description chris fleizach 2021-12-02 16:30:49 PST

1. Enable VoiceOver.
2. Navigate using VoiceOver to the first audio file and press space bar when focused on the play button.

Actual Results: Safari does not play the audio and instead becomes unresponsive.

Expected Results: Playing the files should work as expected, even if they are local.

<rdar://problem/85990360>

Comment 1 Radar WebKit Bug Importer 2021-12-02 16:31:05 PST

<rdar://problem/85994691>

Comment 2 chris fleizach 2021-12-02 16:33:57 PST

Created attachment 445790 [details]
patch

Comment 3 Tyler Wilcock 2021-12-02 16:46:36 PST

Comment on attachment 445790 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=445790&action=review

> Source/WebKit/ChangeLog:9
> +        If we send a sync message after user interaction, we need to inform that the process will susped so that VoiceOver doesn't get stuck.

Typo. susped --> suspend

Comment 4 Eric Carlson 2021-12-02 17:29:56 PST

Comment on attachment 445790 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=445790&action=review

> Source/WebKit/ChangeLog:9
> +        If we send a sync message after user interaction, we need to inform that the process will susped so that VoiceOver doesn't get stuck.

s/susped/suspend/

Comment 5 chris fleizach 2021-12-02 21:36:07 PST

Created attachment 445806 [details]
patch

Comment 6 Andres Gonzalez 2021-12-03 07:23:58 PST

(In reply to chris fleizach from comment #5)
> Created attachment 445806 [details]
> patch

Couldn't we change sendSync(...) to SendSyncOption::InformPlatformProcessWillSuspend by default? So that it doesn't break again next time somebody adds another call.

Comment 7 chris fleizach 2021-12-03 07:28:35 PST

(In reply to Andres Gonzalez from comment #6)
> (In reply to chris fleizach from comment #5)
> > Created attachment 445806 [details]
> > patch
> 
> Couldn't we change sendSync(...) to
> SendSyncOption::InformPlatformProcessWillSuspend by default? So that it
> doesn't break again next time somebody adds another call.

I gather there are a lot of sync calls. When we inform it will suspend it causes VO to not be able to interact with the app until it’s done. Given the lag in posting and processing these changes I think it would break normal navigation. Our problem is with synchronous calls that wait on safari to do expensive work. Most of the send sync calls are fairly straightforward. This is my impression on why we can’t just do this always

Comment 8 chris fleizach 2021-12-03 09:45:01 PST

Looked into this more and something is not lining up. this patch would allow VO to navigate Safari again, but that won't help the WebContnt process being blocked.