WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
125308
AX: WK2: Safari extension installation hangs Safari and VoiceOver
https://bugs.webkit.org/show_bug.cgi?id=125308
Summary
AX: WK2: Safari extension installation hangs Safari and VoiceOver
chris fleizach
Reported
2013-12-05 10:42:02 PST
1-open safari and search for safari extension (any so far) 2-once downloaded, go to finder and open the ext file. * EXPECTED RESULTS: extension to install with the dialog in safari asking to confirm installation of the extension. * ACTUAL RESULTS: safari and voice over freeze. Difficult to get out
Attachments
patch
(4.00 KB, patch)
2013-12-05 10:43 PST
,
chris fleizach
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
chris fleizach
Comment 1
2013-12-05 10:42:11 PST
<
rdar://problem/15594097
>
chris fleizach
Comment 2
2013-12-05 10:43:32 PST
Created
attachment 218524
[details]
patch
Alexey Proskuryakov
Comment 3
2013-12-05 11:02:41 PST
This is super scary. With this patch, dispatchDecidePolicyForResponse will have entirely different behavior when accessibility is enabled.
Alexey Proskuryakov
Comment 4
2013-12-05 11:04:38 PST
If you can prove that it is safe to spin run loop here, I suggest making it unconditionally. Otherwise, we might need a deeper change to ho extensions are installed.
chris fleizach
Comment 5
2013-12-05 11:23:24 PST
(In reply to
comment #4
)
> If you can prove that it is safe to spin run loop here, I suggest making it unconditionally. > > Otherwise, we might need a deeper change to ho extensions are installed.
This seems not that much different from javascript alerts where we do unsigned syncSendFlags = (WebCore::AXObjectCache::accessibilityEnabled()) ? CoreIPC::SpinRunLoopWhileWaitingForReply : 0; WebProcess::shared().parentProcessConnection()->sendSync(Messages::WebPageProxy::RunJavaScriptAlert(webFrame->frameID(), alertText), Messages::WebPageProxy::RunJavaScriptAlert::Reply(), m_page->pageID(), CoreIPC::Connection::NoTimeout, syncSendFlags); That code has been in for 2 years, and we do have one case where it has proven to be unsafe (
https://bugs.webkit.org/show_bug.cgi?id=123828
) which I am very close to having a fix for.
Alexey Proskuryakov
Comment 6
2013-12-05 11:28:13 PST
Should we make it unconditional in that case? Anders and Brady are really the ones who should make the call on whether it's acceptable design to spin the run loop here.
chris fleizach
Comment 7
2013-12-05 11:30:45 PST
(In reply to
comment #6
)
> Should we make it unconditional in that case? >
Not sure. I think Anders and Darin helped me resolve the javascript case in the past, so (echoing you) they'll probably be able to speak to that more. Thanks
> Anders and Brady are really the ones who should make the call on whether it's acceptable design to spin the run loop here.
Anders Carlsson
Comment 8
2013-12-05 15:00:02 PST
Comment on
attachment 218524
[details]
patch I think this looks good.
WebKit Commit Bot
Comment 9
2013-12-05 15:30:18 PST
Comment on
attachment 218524
[details]
patch Clearing flags on attachment: 218524 Committed
r160197
: <
http://trac.webkit.org/changeset/160197
>
WebKit Commit Bot
Comment 10
2013-12-05 15:30:21 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug