New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 694904 link

Starred by 1 user
Status: Fixed
Owner:
kinuko@chromium.org
Closed: Feb 2017
Cc:
yhirano@chromium.org
japhet@chromium.org
█ tyoshino@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 695279



Sign in to add a comment

Remove WebFrame::dispatchWillSendRequest if possible

Project Member Reported by kinuko@chromium.org, Feb 22 2017 
Today we have AssociatedURLLoader interface for non-blink modules to fetch resources in a way that is associated with a frame, but content::ResourceFetcherImpl with PLATFORM_LOADING (which doesn't use AssociatedURLLoader but platform URLLoader, which doesn't go through Blink's loading stack) still call WebFrame::dispatchWillSendRequest (to eventually call WebFrameClient::willSendRequest).  It looks customers of platform loaders shouldn't rely on this or should migrate to AssociatedURLLoader.

Current customers are only two: NetErrorHelper and MojoContextState

Comment 1 by kinuko@chromium.org, Feb 22 2017

Cc: tyoshino@chromium.org japhet@chromium.org yhirano@chromium.org
Project Member

Comment 2 by bugdroid1@chromium.org, Feb 22 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/047e3c9956a25ff9ed0391f550f337842cb3e7d6

commit 047e3c9956a25ff9ed0391f550f337842cb3e7d6
Author: kinuko <kinuko@chromium.org>
Date: Wed Feb 22 10:01:16 2017

Remove dispatchWillSendRequest from WebFrame

Customers of AssociatedURLLoader do not need this because
AssociatedURLLoader internally dispatches it.

I think customers of Platform WebURLLoader should not need this
because if it needs to use it it should be using AssociatedURLLoader.
(Current customers are only two: NetErrorHelper and MojoContextState)

BUG= 694904 

Review-Url: https://codereview.chromium.org/2701333004
Cr-Commit-Position: refs/heads/master@{#451963}

[modify] https://crrev.com/047e3c9956a25ff9ed0391f550f337842cb3e7d6/content/renderer/fetchers/associated_resource_fetcher_impl.cc
[modify] https://crrev.com/047e3c9956a25ff9ed0391f550f337842cb3e7d6/content/renderer/fetchers/resource_fetcher_impl.cc
[modify] https://crrev.com/047e3c9956a25ff9ed0391f550f337842cb3e7d6/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
[modify] https://crrev.com/047e3c9956a25ff9ed0391f550f337842cb3e7d6/third_party/WebKit/Source/web/WebLocalFrameImpl.h
[modify] https://crrev.com/047e3c9956a25ff9ed0391f550f337842cb3e7d6/third_party/WebKit/Source/web/WebRemoteFrameImpl.cpp
[modify] https://crrev.com/047e3c9956a25ff9ed0391f550f337842cb3e7d6/third_party/WebKit/Source/web/WebRemoteFrameImpl.h
[modify] https://crrev.com/047e3c9956a25ff9ed0391f550f337842cb3e7d6/third_party/WebKit/public/web/WebFrame.h

Comment 3 by kinuko@chromium.org, Feb 23 2017 

Closing this until we find problems.  (Let's reopen then)

Comment 4 by kinuko@chromium.org, Feb 23 2017

Status: Fixed (was: Assigned)

Comment 5 by kinuko@chromium.org, Feb 23 2017

Blocking: 695279
►

Sign in to add a comment