GetBaseDomainInternal shows up badly when opening and closing the menu in CNN, at least when tracking protection is enabled
Categories
(Core :: Privacy: Anti-Tracking, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox72 | --- | fixed |
People
(Reporter: smaug, Assigned: ehsan.akhgari, NeedInfo)
Details
Attachments
(1 file)
profile
https://perfht.ml/32ee65K
STR,
load https://www.cnn.com/
click on the 'hamburger' menu on top-right-ish of the page
Because of AntiTrackingCommon being on stack, this smells like possible
issue in that code.
Reporter | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
The profile in comment 0 is invalid. Does this profile match what you were seeing? https://perfht.ml/2oLms6j
If yes, then this is all from Document::EffectiveStoragePrincipal()
. Perhaps we should cache the effective storage principal instead of computing it every time that function is called?
Assignee | ||
Updated•5 years ago
|
Reporter | ||
Comment 2•5 years ago
•
|
||
How is the profile invalid? Your profile looks very similar to mine.
And yes, I was thinking caching too.
Assignee | ||
Comment 3•5 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #2)
How is the profile invalid? Your profile looks very similar to mine.
Huh... When I tried to load it the other day I got some kind of "profile cannot be found" error (don't remember the exact message any more, sorry). But the link works now. Must have been a transient issue.
And yes, I was thinking caching too.
Sounds good, taking.
Assignee | ||
Comment 4•5 years ago
|
||
Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/55743f55095c Cache the document's effective storage principal to avoid running excessive anti-tracking checks; r=baku
Comment 6•5 years ago
|
||
bugherder |
Assignee | ||
Comment 7•5 years ago
|
||
Profile after the change for comparison: https://perfht.ml/2o6wVsV
Description
•