Bug 187502 - Content blocker fails to block on internal page load
Summary: Content blocker fails to block on internal page load
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Local Build
Hardware: Mac macOS 10.13
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-07-09 19:24 PDT by Jeff Johnson
Modified: 2018-07-25 15:40 PDT (History)
3 users (show)

See Also:


Attachments
content blocking rules (188 bytes, application/json)
2018-07-09 19:24 PDT, Jeff Johnson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Johnson 2018-07-09 19:24:54 PDT
Created attachment 344656 [details]
content blocking rules

If you load a page from the address bar, then the content blocking rules apply, but if a page redirects, it can bypass the content blocking rules. This happens in Safari, as well as in the MiniBrowser sample project.

Steps to reproduce:
1. Build WebKit
2. Run MiniBrowser
3. Open "Debug" menu
4. Select "Show Extensions Manager"
5. Click the + button
6. Select the attachment "test.json"
7. In the address bar, load https://developer.apple.com/search/
8. Enter "NSArray" in the search field, and press return
9. Press the reload button

The content blocking rules specify that "https://developer.apple.com/search/?q=NSArray" should be blocked. In step 8, the page redirects to "https://developer.apple.com/search/?q=NSArray", but the content blocking rules do not block it. In step 9, however, the content blocking rules do apply, and you see "Content blocker prevented frame displaying https://developer.apple.com/search/?q=NSArray from loading a resource from https://developer.apple.com/search/?q=NSArray" in the JavaScript console.
Comment 1 Radar WebKit Bug Importer 2018-07-10 17:13:31 PDT
<rdar://problem/42048265>
Comment 2 Chris Dumez 2018-07-25 13:46:30 PDT
Is this a regression?
Comment 3 Chris Dumez 2018-07-25 14:03:14 PDT
Not a real navigation (or redirect), the page changes the URL via:
0x15f300d50 - Document::setURL(https://developer.apple.com/search/?q=NSMutableArray)
1   0x10aa3daa1 WebCore::Document::setURL(WebCore::URL const&)
2   0x10aa58607 WebCore::Document::updateURLForPushOrReplaceState(WebCore::URL const&)
3   0x10aeb7c55 WebCore::History::stateObjectAdded(WTF::RefPtr<WebCore::SerializedScriptValue, WTF::DumbPtrTraits<WebCore::SerializedScriptValue> >&&, WTF::String const&, WTF::String const&, WebCore::History::StateObjectType)
4   0x10a2864c3 WebCore::jsHistoryPrototypeFunctionPushState(JSC::ExecState*)

No navigation happens, all Ajax.

Not convinced this is a bug also we should confirm with Alex.
Comment 4 Alex Christensen 2018-07-25 14:08:56 PDT
This web page is loading https://developer.apple.com/search/search_data.php?q=NSArray&results=500 which does not match your rule
Comment 5 Jeff Johnson 2018-07-25 15:38:28 PDT
I see. Wow, I didn't realize until now that HTML5 allows you to arbitrarily manipulate the browser address bar in a misleading way. Can I file a bug against that? ;-)
Comment 6 Chris Dumez 2018-07-25 15:40:57 PDT
(In reply to opendarwin from comment #5)
> I see. Wow, I didn't realize until now that HTML5 allows you to arbitrarily
> manipulate the browser address bar in a misleading way. Can I file a bug
> against that? ;-)

Sure, against the HTML spec though :)