Summary: | Suppress JavaScript prompts early on in certain cases | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Anders Carlsson <andersca> | ||||||
Component: | New Bugs | Assignee: | Anders Carlsson <andersca> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | achristensen, cdumez, commit-queue, dbates, japhet | ||||||
Priority: | P2 | ||||||||
Version: | WebKit Nightly Build | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=165032 | ||||||||
Attachments: |
|
Description
Anders Carlsson
2016-09-19 16:17:40 PDT
Created attachment 289271 [details]
Patch
Comment on attachment 289271 [details]
Patch
What about WK1?
Are we sure that window.open() on a timer can't interrupt a navigation in a non-window.open document?
Need some export action:
"WebCore::FrameLoaderStateMachine::isDisplayingInitialEmptyDocument() const", referenced from:
WebKit::shouldSuppressJavaScriptDialogs(WebCore::Frame&) in WebChromeClient.o
r=me
Created attachment 289278 [details]
Patch
Comment on attachment 289278 [details]
Patch
r=me
Comment on attachment 289278 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=289278&action=review > Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:382 > +static bool shouldSuppressJavaScriptDialogs(Frame& frame) Why are we doing this in WebKit2 and not on DOMWindow in WebCore? Note that we already have page->arePromptsAllowed() for similar purposes. (In reply to comment #5) > Comment on attachment 289278 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=289278&action=review > > > Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:382 > > +static bool shouldSuppressJavaScriptDialogs(Frame& frame) > > Why are we doing this in WebKit2 and not on DOMWindow in WebCore? Note that > we already have page->arePromptsAllowed() for similar purposes. It's a targeted fix for a WK2 specific problem. Comment on attachment 289278 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=289278&action=review >> Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:382 >> +static bool shouldSuppressJavaScriptDialogs(Frame& frame) > > Why are we doing this in WebKit2 and not on DOMWindow in WebCore? Note that we already have page->arePromptsAllowed() for similar purposes. See ForbidPromptsScope in FrameLoader. (In reply to comment #7) > Comment on attachment 289278 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=289278&action=review > > >> Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:382 > >> +static bool shouldSuppressJavaScriptDialogs(Frame& frame) > > > > Why are we doing this in WebKit2 and not on DOMWindow in WebCore? Note that we already have page->arePromptsAllowed() for similar purposes. > > See ForbidPromptsScope in FrameLoader. Using ForbidPromptsScope in this case isn't possible (it certainly won't make things easier). (In reply to comment #8) > (In reply to comment #7) > > Comment on attachment 289278 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=289278&action=review > > > > >> Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:382 > > >> +static bool shouldSuppressJavaScriptDialogs(Frame& frame) > > > > > > Why are we doing this in WebKit2 and not on DOMWindow in WebCore? Note that we already have page->arePromptsAllowed() for similar purposes. > > > > See ForbidPromptsScope in FrameLoader. > > Using ForbidPromptsScope in this case isn't possible (it certainly won't > make things easier). Ok, just making sure this was intentional. Committed r206132: <http://trac.webkit.org/changeset/206132> Should this still be r? |