Bug 162243

Summary: Suppress JavaScript prompts early on in certain cases
Product: WebKit Reporter: Anders Carlsson <andersca>
Component: New BugsAssignee: 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 Flags
Patch
none
Patch none

Description Anders Carlsson 2016-09-19 16:17:40 PDT
Suppress JavaScript prompts early on in certain cases
Comment 1 Anders Carlsson 2016-09-19 16:18:37 PDT
Created attachment 289271 [details]
Patch
Comment 2 Geoffrey Garen 2016-09-19 16:26:58 PDT
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
Comment 3 Anders Carlsson 2016-09-19 16:29:19 PDT
Created attachment 289278 [details]
Patch
Comment 4 Geoffrey Garen 2016-09-19 16:36:38 PDT
Comment on attachment 289278 [details]
Patch

r=me
Comment 5 Chris Dumez 2016-09-19 16:36:53 PDT
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.
Comment 6 Anders Carlsson 2016-09-19 16:39:24 PDT
(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 7 Chris Dumez 2016-09-19 16:39:35 PDT
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.
Comment 8 Anders Carlsson 2016-09-19 16:41:51 PDT
(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).
Comment 9 Chris Dumez 2016-09-19 16:47:16 PDT
(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.
Comment 10 Anders Carlsson 2016-09-19 16:49:13 PDT
Committed r206132: <http://trac.webkit.org/changeset/206132>
Comment 11 Alex Christensen 2016-09-19 21:33:25 PDT
Should this still be r?