Closed Bug 608030 Opened 14 years ago Closed 14 years ago

Disable MozAfterPaint for content by default

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla2.0b10
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: mozilla, Assigned: dbaron)

Details

(Keywords: dev-doc-complete, Whiteboard: [softblocker][fx4-fixed-bugday][sg:low])

Attachments

(3 files, 1 obsolete file)

In bug 557579 comment 6, I pointed out that doing anything conditionally on the visitedness of a link has the potential to leak private history state. Currently the behavior of MozAfterPaint is influenced by the visitedness of links, so this event can be used to detect sites the user has or hasn't been to before. In bug 557579 comment 9, dbaron suggests disabling MozAfterPaint for content by default, but have a pref that allows people who want to do performance testing with it to enable it. See also: bug 600025, bug 147777
Component: Style System (CSS) → Layout
QA Contact: style-system → layout
blocking2.0: --- → betaN+
Assignee: nobody → dbaron
I should do this after bug 612190 lands, to avoid merge conflicts.
Whiteboard: [wait for bug 612190 to land before working on]
Whiteboard: [wait for bug 612190 to land before working on] → [wait for bug 612190 to land before working on][softblocker]
The relevant part of bug 612190 is now landed (see bug 612190 comment 26).
Attached patch patch (obsolete) — Splinter Review
Attachment #504924 - Flags: review?(roc)
Whiteboard: [wait for bug 612190 to land before working on][softblocker] → [needs landing][softblocker]
As part of fixing tests for the main patch, I realized I needed to add setting of a new pref to reftest and mochitest. But before I did that, I decided to clean up the reftest prefs code a bit, so that: * it doesn't risk changing the profile, even if interrupted * prefs that are needed for reftests to work are in the harness, not the optional runreftest.py
Attachment #505559 - Flags: review?(roc)
Attached patch patchSplinter Review
With some additional test changes so that we pass tests. It seemed easier to just flip the pref by default for our tests than to make the individual tests flip it.
Attachment #505560 - Flags: review?(roc)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b10
This fixes some highly unusual use of the pref API. I simplified the reftest pref-setting code by making it set the prefs as default prefs (which avoids having to unset them), but the code reading the force_srgb pref was explicitly checking that the pref was a user-set and not a default pref. It shouldn't do that. The pref API exposes "unset" by throwing from GetBoolPref (etc.), so the NS_SUCCEEEDED(rv) check on the result of GetBoolPref is sufficient here. This code originated in http://hg.mozilla.org/mozilla-central/rev/4b2977a03aba
Attachment #506495 - Flags: review?(jmuizelaar)
Attachment #506495 - Flags: review?(jmuizelaar) → review+
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing][softblocker] → [softblocker]
From what I gather, this bug is about not sending MozAfterPaint for (to) content, but the docs just say it's not sent (at all, as I take it). Does MozAfterPaint still work for trusted listeners, or no?
(In reply to comment #11) > From what I gather, this bug is about not sending MozAfterPaint for (to) > content, but the docs just say it's not sent (at all, as I take it). > > Does MozAfterPaint still work for trusted listeners, or no? You're right; I've clarified that. Nice catch, thank you.
Verified with Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
Whiteboard: [softblocker] → [softblocker][fx4-fixed-bugday]
Whiteboard: [softblocker][fx4-fixed-bugday] → [softblocker][fx4-fixed-bugday][sg:low]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: