Bug 187502

Summary: Content blocker fails to block on internal page load
Product: WebKit Reporter: Jeff Johnson <opendarwin>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: achristensen, cdumez, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Local Build   
Hardware: Mac   
OS: macOS 10.13   
Attachments:
Description Flags
content blocking rules none

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 :)