Closed Bug 1608516 Opened 6 years ago Closed 5 years ago

Update AddBlockedNodeByClassifier on subframes for Fission

Categories

(Core :: Privacy: Anti-Tracking, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla77
Fission Milestone M6
Tracking Status
firefox77 --- fixed

People

(Reporter: nika, Assigned: timhuang)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

Tracking Protection appears to record that a frame element's load was blocked by the classifier from within that element. This is not compatible with Fission, as the frame element may not be present in the same process as the embedded nsDocShell. https://searchfox.org/mozilla-central/rev/d4d6f81e0ab479cde192453bae83d5e3edfb39d6/docshell/base/nsDocShell.cpp#6158-6192

ni Tim to get this on his radar.

Flags: needinfo?(tihuang)

I believe we can move the blockedNodesByClassifier and the blockedNodeByClassifierCount from content processes to the parent process. And move them from the document to the windowGlobalParent. These two values are chrome only and we are only using them in the test, so I think it is totally fine to move them.

Blocks: etp-fission
Flags: needinfo?(tihuang)
Priority: -- → P3

We can't move blockedNodesByClassifier to the parent, since it returns a NodeList. The nodes in that list live in the content process, it's meaningless to return a list of them in the parent process...

My counter proposal is to remove both of these properties and the code as well as the tests using them. Is there any reason why we want to keep them around? Removing them seems much simpler than making them work in Fission...

(In reply to :ehsan akhgari from comment #3)

We can't move blockedNodesByClassifier to the parent, since it returns a NodeList. The nodes in that list live in the content process, it's meaningless to return a list of them in the parent process...

Thanks for catching this. I didn't see this before. So, yes, moving them to the parent is not a possible solution.

My counter proposal is to remove both of these properties and the code as well as the tests using them. Is there any reason why we want to keep them around? Removing them seems much simpler than making them work in Fission...

Removing them is an effective solution here. But, see here, the test verifies the annotated nodes through blockedNodesByClassifier and I think a test like this is useful. So, maybe we can remove them here and add similar tests by using a Fission compatible approach in a different bug?

What do you thank, Ehsan?

Flags: needinfo?(ehsan)

(In reply to Tim Huang[:timhuang] from comment #4)

Removing them is an effective solution here. But, see here, the test verifies the annotated nodes through blockedNodesByClassifier and I think a test like this is useful. So, maybe we can remove them here and add similar tests by using a Fission compatible approach in a different bug?

What do you thank, Ehsan?

It seems to me that this test is just verifying that document.blockedNodesByClassifier is working as expected. The test is already checking that the correct nodes are being blocked (using the node.dataset.checked checks) and then verifying that document.blockedNodesByClassifier returns the same information.

So as far as I am concerned, we can just remove this part of that test. :-)

Flags: needinfo?(ehsan)

Thanks for clarifying. I will do this.

Assignee: nobody → tihuang

I believe we have an alternative for this instead of removing blockedNodesByClassifier. The blockedNodesByClassifier only record the nodes within the same document. And the code mentioned in comment 0 is an iframe to report the blocking to its parent document. The problem here is the parent document might be out-of-process. So, we can address this via sending an IPC to the process of the parent document to tell it to record the blocked node, which is the frame element and it is supposed to be in the parent doucment's process.

This patch adds IPCs that allow us to be able to report the blocked node
across the process boundary.

In this patch, we report the blocked node across the process
boundaries if the parent is in a different process. If the parent
document is in the same process as the reporting document, we
will directly add the blocked node in the parent document without
sending an IPC.

Depends on D71938

Pushed by tihuang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8c1be470cb2c Part 1: Add IPCs for allowing do AddBlockedNodeByClassifier() across process boundaries. r=baku https://hg.mozilla.org/integration/autoland/rev/2a8566d55ba6 Part 2: Make AddBlockedNodeByClassifier() in nsDocShell::EndPageLoad() Fission-compatible. r=baku https://hg.mozilla.org/integration/autoland/rev/f588a8808e45 Part 3: Add a pref to prevent sending unnecessary IPC if we are not in testing. r=baku
Flags: needinfo?(tihuang)
Pushed by tihuang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b5169541af78 Part 1: Add IPCs for allowing do AddBlockedNodeByClassifier() across process boundaries. r=baku https://hg.mozilla.org/integration/autoland/rev/41aab5ec35c6 Part 2: Make AddBlockedNodeByClassifier() in nsDocShell::EndPageLoad() Fission-compatible. r=baku https://hg.mozilla.org/integration/autoland/rev/25445df807ec Part 3: Add a pref to prevent sending unnecessary IPC if we are not in testing. r=baku
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: