RESOLVED INVALID 187502
Content blocker fails to block on internal page load 
https://bugs.webkit.org/show_bug.cgi?id=187502
Summary Content blocker fails to block on internal page load
Jeff Johnson
Reported 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.
Attachments
content blocking rules (188 bytes, application/json)
2018-07-09 19:24 PDT, Jeff Johnson 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2018-07-10 17:13:31 PDT
<rdar://problem/42048265>
Chris Dumez
Comment 2 2018-07-25 13:46:30 PDT
Is this a regression?
Chris Dumez
Comment 3 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.
Alex Christensen
Comment 4 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
Jeff Johnson
Comment 5 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? ;-)
Chris Dumez
Comment 6 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 :)
Note You need to log in before you can comment on or make changes to this bug.