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
I should do this after bug 612190 lands, to avoid merge conflicts.
The relevant part of bug 612190 is now landed (see bug 612190 comment 26).
Created attachment 504924 [details] [diff] [review]
Created attachment 505559 [details] [diff] [review]
pre-patch: clean up reftest pref handling
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
Created attachment 505560 [details] [diff] [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.
Created attachment 506495 [details] [diff] [review]
honor the force_srgb pref even when it's a default pref
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
Also noted on Fx4 for developers.
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