Closed Bug 1632765 Opened 1 year ago Closed 1 year ago

Turn on the visited link mitigations.


(Core :: CSS Parsing and Computation, task, P3)




Tracking Status
firefox77 --- fixed


(Reporter: emilio, Assigned: emilio)




(2 files)

No description provided.

We couldn't turn these on before because of perf regressions, but after bug
1626586 perf looks pretty neutral.

Blocks: 884270
See Also: → 1398414
Type: defect → task
Priority: -- → P3
Pushed by
Turn on some more :visited privacy mitigations. r=mak

The pref flip in this bug causes an assertion to fail in

Our behavior in that crashtest is so messed up that I can't even begin
to describe it.

That test-case has three-pages, and a link inside a fixed-pos subtree,
which has a ::after pseudo-element.

Via the magic of nsCSSFrameConstructor::ReplicateFixedFrames, we end up
constructing multiple frames, one per page, for the fixed subtree.

We end up with a link with three different ::after pseudo-elements (one
on each page), of which the link only knows about the latest one.

This means that when restyling the link (which was already broken, it
just didn't happen before the prefs), we'd visit the pseudo-element in
some other place of the frame tree we can get a hand on.

Restyling these frames is generally not supported and will do ~nothing,
given the current setup. There's no way to get a hand from the DOM node
to all its replicated frames.

But that's not something I plan to fix for this bug, and this assertion
is blocking me.

Flags: needinfo?(emilio)
Pushed by
Bypass a restyling assertion in a replicated fixed-pos subtree. r=TYLin
Pushed by
Turn on some more :visited privacy mitigations. r=mak
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
Regressions: 1633732
See Also: → 1293420
You need to log in before you can comment on or make changes to this bug.