WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
REOPENED
161441
Should have a way for clients to specify which page loads should use content extensions
https://bugs.webkit.org/show_bug.cgi?id=161441
Summary
Should have a way for clients to specify which page loads should use content ...
Brian Weinstein
Reported
2016-08-31 10:35:26 PDT
Should have a way for clients to specify which page loads should use content extensions.
Attachments
[PATCH] Fix
(15.60 KB, patch)
2016-08-31 10:55 PDT
,
Brian Weinstein
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2016-08-31 10:36:39 PDT
<
rdar://problem/28098075
>
Brian Weinstein
Comment 2
2016-08-31 10:55:53 PDT
Created
attachment 287519
[details]
[PATCH] Fix
Alex Christensen
Comment 3
2016-08-31 13:28:24 PDT
Comment on
attachment 287519
[details]
[PATCH] Fix Do we really want this to be synchronous and in the InjectedBundle? That means that each InjectedBundle would need to have enough information to immediately decide if we want to use content extensions for this URL, or it would need to send synchronous IPC. We designed content extensions to not need either of these performance reducing things.
Brian Weinstein
Comment 4
2016-08-31 13:36:06 PDT
(In reply to
comment #3
)
> Comment on
attachment 287519
[details]
> [PATCH] Fix > > Do we really want this to be synchronous and in the InjectedBundle? That > means that each InjectedBundle would need to have enough information to > immediately decide if we want to use content extensions for this URL, or it > would need to send synchronous IPC. We designed content extensions to not > need either of these performance reducing things.
In this case, the client is pushing the information to each injected bundle when it is updated, so the injected bundle always has the correct state of the world w.r.t. sites that shouldn’t use content blockers. Another option is to push all of the information about which pages to disable content blockers on to WebKit/WebCore, but I’m not sure if that’s necessarily cleaner than what we are doing here.
Alex Christensen
Comment 5
2016-08-31 14:46:25 PDT
I'm concerned about pushing long lists of URLs to each new WebProcess every time we make a new tab.
Brian Weinstein
Comment 6
2016-08-31 14:57:07 PDT
(In reply to
comment #5
)
> I'm concerned about pushing long lists of URLs to each new WebProcess every > time we make a new tab.
I agree with this concern in theory, but in practice: - It wouldn't necessarily need a list of URLs, it could use high level domains - I don't know how many domains users would store in practice. Is there some code I can look at for how we would share one copy of this data across all web processes?
Sam Weinig
Comment 7
2016-08-31 23:23:29 PDT
Perhaps this could be determined at decidePolicyForNavigationAction decision time in the UIProcess. It might be generally useful to be able to override functionality at that time, so adding a mechanism for it could be useful.
Brian Weinstein
Comment 8
2016-08-31 23:27:12 PDT
(In reply to
comment #7
)
> Perhaps this could be determined at decidePolicyForNavigationAction decision > time in the UIProcess. It might be generally useful to be able to override > functionality at that time, so adding a mechanism for it could be useful.
That is an interesting idea! WKPageSetUserContentExtensionsEnabled seems to exist, but doesn't appear to be implemented.
Brian Weinstein
Comment 9
2016-08-31 23:31:34 PDT
(In reply to
comment #8
)
> (In reply to
comment #7
) > > Perhaps this could be determined at decidePolicyForNavigationAction decision > > time in the UIProcess. It might be generally useful to be able to override > > functionality at that time, so adding a mechanism for it could be useful. > > That is an interesting idea! WKPageSetUserContentExtensionsEnabled seems to > exist, but doesn't appear to be implemented.
But that might not be the way we would want to implement disabling content blockers for that load anyways, just something I noticed when clicking around.
Brian Weinstein
Comment 10
2016-08-31 23:39:37 PDT
Another concern is whether or not the main resource load will have already started by the time the UI Process handles the decidePolicyForNavigationAction call.
Alex Christensen
Comment 11
2016-09-01 10:56:25 PDT
decidePolicyForNavigationAction is initiated from didReceiveResponse in the NetworkProcess, which means it's too late; the main resource request has already been sent with content blockers applied
Sam Weinig
Comment 12
2016-09-02 13:46:06 PDT
(In reply to
comment #11
)
> decidePolicyForNavigationAction is initiated from didReceiveResponse in the > NetworkProcess, which means it's too late; the main resource request has > already been sent with content blockers applied
We do the initial decidePolicyForNavigationAction before talking to the NetworkProcess.
WebKit Commit Bot
Comment 13
2016-09-03 13:00:24 PDT
Comment on
attachment 287519
[details]
[PATCH] Fix Clearing flags on attachment: 287519 Committed
r205407
: <
http://trac.webkit.org/changeset/205407
>
WebKit Commit Bot
Comment 14
2016-09-03 13:00:28 PDT
All reviewed patches have been landed. Closing bug.
Sam Weinig
Comment 15
2016-09-05 20:20:38 PDT
I don't this this is the correct direction for this feature. Please roll this out so we can continue our discussion of ways to get this functionality without additional bundle SPI.
Ryan Haddad
Comment 16
2016-09-06 09:57:13 PDT
Reverted
r205407
for reason: Not the correct way to implement this functionality Committed
r205487
: <
http://trac.webkit.org/changeset/205487
>
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