Bug 233791 - AX: Attempting to play local media files as part of a speech study causes Safari to hang.
Summary: AX: Attempting to play local media files as part of a speech study causes Saf...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: chris fleizach
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-12-02 16:30 PST by chris fleizach
Modified: 2021-12-03 09:45 PST (History)
10 users (show)

See Also:


Attachments
patch (1.79 KB, patch)
2021-12-02 16:33 PST, chris fleizach
no flags Details | Formatted Diff | Diff
patch (1.79 KB, patch)
2021-12-02 21:36 PST, chris fleizach
andresg_22: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.