Perf looks neutral: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=45a3765c14990ecf11f5b7fcebce5e94bb86248a&newProject=try&newRevision=d38ca9477dfa48b64a09fb6aefc9b3d8c532a467&framework=1

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

Backed out for perma failures.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=eMN-K_WrRTeHpuUopbGnZQ-0&resultStatus=testfailed%2Cbusted%2Cexception&revision=29e132824d37e72c247dd8523ea1896a54984407

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=299633335&repo=autoland&lineNumber=43448

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=299617674&repo=autoland&lineNumber=44109

Backout: https://hg.mozilla.org/integration/autoland/rev/0689b5112e6204df798f215ee4f394346fb978a9

The pref flip in this bug causes an assertion to fail in
layout/generic/crashtests/1137723-1.html.

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.

https://hg.mozilla.org/mozilla-central/rev/4a20db95098d
https://hg.mozilla.org/mozilla-central/rev/8d7864d6d8da