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

Issue 689049 link

Starred by 2 users
Status: Fixed
Owner:
█ bmcquade@chromium.org
Last visit > 30 days ago
Closed: Feb 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Avoid displaying subresource filtering prompt for preloads

Project Member Reported by bmcquade@chromium.org, Feb 6 2017 
DocumentSubresourceFilter::allowLoad currently reports a resource was filtered (via the first_disallowed_load_callback_) for all types of loads, including preloads. Since preloads do not affect the state of the document we should avoid reporting filtering for preloads.

This requires a change to the WebDocumentSubresourceFilter API, separating out whether a resource should be filtered (a method that returns a filtering policy) from reporting that an actual document resource was filtered (a method indicating that a document resource was filtered as a result of subresource filter policy).
Project Member

Comment 1 by bugdroid1@chromium.org, Feb 7 2017 

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

commit f3455dace4afe149e6bb4d68acb4d4a6f5e2134a
Author: bmcquade <bmcquade@chromium.org>
Date: Tue Feb 07 20:25:32 2017

Distinguish between subresource filtering and dryrun matching.

In order to report page load metrics for an experiment and control population,
we need to track page load metrics for affected pages both in cases where
filtering is active, and where filtering is in dry run mode.

To do this, we extend WebDocumentSubresourceFilter to report not only whether
filtering applied, but also whether it would have been appllied in cases where
we are in dry run mode.

While we're changing the WebDocumentSubresourceFilter API, we address the
related issue of not displaying the subresource filtering UI for filtered
preloads. This is accomplished by providing separate APIs to get the filtering
policy for a resource (a pure policy URL) vs an API to report that a resource
loaded by the document was filtered.

BUG= 689047 ,  689049 

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

[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/components/subresource_filter/content/common/document_subresource_filter.cc
[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/components/subresource_filter/content/common/document_subresource_filter.h
[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/components/subresource_filter/content/common/document_subresource_filter_unittest.cc
[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/components/subresource_filter/content/renderer/subresource_filter_agent_unittest.cc
[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/components/test_runner/mock_web_document_subresource_filter.cc
[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/components/test_runner/mock_web_document_subresource_filter.h
[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/third_party/WebKit/Source/core/loader/FrameFetchContextTest.cpp
[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/third_party/WebKit/Source/web/tests/WebDocumentSubresourceFilterTest.cpp
[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/third_party/WebKit/public/platform/WebDocumentSubresourceFilter.h
[modify] https://crrev.com/f3455dace4afe149e6bb4d68acb4d4a6f5e2134a/third_party/WebKit/public/platform/WebLoadingBehaviorFlag.h

Comment 2 by bmcquade@chromium.org, Feb 8 2017

Status: Fixed (was: Started)
►

Sign in to add a comment