Bug 312552 – ParentalControls Filters may accidentally vend an iframe shield instead of a mainframe shield.

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

ParentalControls Filters may accidentally vend an iframe shield instead of a mainframe shield. 

We use the criteria that the current mainFrameURL is null to determine whether or not we have an iframe or a mainframe. This worked for the most part because testing was done with URLs that trigger process swaps because the scheme of the blocked page is different. In that situation, we start with a brand new mainFrameURL as the load has not been populated yet.

But in the case where the same process is re-used, we still have the residual mainFrameURL and so we vend the iframe shield instead.

The code currently assumes that mainFrameURL will always be null on a fresh navigation. This is wrong. Instead, the code is changed to (a) make it clear that the "mainFrameURL" we are populating is explicitly for transitive trust / iFrames by refactoring mainDocumentURL to transitiveTrustMainDocumentURL, (b) we only populate the transitiveTrustMainDocumentURL if we are an iframe and we use existing DocumentLoader/NetworkResourceLoader to determine this.

I tested that this code works for correctly vending both mainFrame and iFrame shields.

<rdar://problem/173774144>

Pull request: https://github.com/WebKit/WebKit/pull/62959

[EWS]

Committed 311515@main (e48835c9f88c): <https://commits.webkit.org/311515@main>

Reviewed commits have been landed. Closing PR #62959 and removing active labels.