Closed
Bug 608030
Opened 14 years ago
Closed 14 years ago
Disable MozAfterPaint for content by default
Categories
(Core :: Layout, defect, P3)
Core
Layout
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)
4.95 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
13.41 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
1.91 KB,
patch
|
jrmuizel
:
review+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Updated•14 years ago
|
Component: Style System (CSS) → Layout
QA Contact: style-system → layout
Assignee | ||
Updated•14 years ago
|
blocking2.0: --- → betaN+
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → dbaron
Assignee | ||
Comment 1•14 years ago
|
||
I should do this after bug 612190 lands, to avoid merge conflicts.
Assignee | ||
Updated•14 years ago
|
Whiteboard: [wait for bug 612190 to land before working on]
Assignee | ||
Updated•14 years ago
|
Whiteboard: [wait for bug 612190 to land before working on] → [wait for bug 612190 to land before working on][softblocker]
Assignee | ||
Updated•14 years ago
|
Priority: -- → P3
Assignee | ||
Comment 2•14 years ago
|
||
The relevant part of bug 612190 is now landed (see bug 612190 comment 26).
Assignee | ||
Comment 3•14 years ago
|
||
Attachment #504924 -
Flags: review?(roc)
Attachment #504924 -
Flags: review?(roc) → review+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [wait for bug 612190 to land before working on][softblocker] → [needs landing][softblocker]
Assignee | ||
Comment 4•14 years ago
|
||
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)
Assignee | ||
Comment 5•14 years ago
|
||
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)
Assignee | ||
Updated•14 years ago
|
Attachment #504924 -
Attachment is obsolete: true
Attachment #505559 -
Flags: review?(roc) → review+
Attachment #505560 -
Flags: review?(roc) → review+
Assignee | ||
Comment 6•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/ffebdc3ddb62
http://hg.mozilla.org/mozilla-central/rev/3248feddc867
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b10
Assignee | ||
Comment 7•14 years ago
|
||
Backed out:
http://hg.mozilla.org/mozilla-central/rev/f5cf80c6dae4
http://hg.mozilla.org/mozilla-central/rev/80266029824b
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 8•14 years ago
|
||
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)
Updated•14 years ago
|
Attachment #506495 -
Flags: review?(jmuizelaar) → review+
Assignee | ||
Updated•14 years ago
|
Keywords: dev-doc-needed
Assignee | ||
Comment 9•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/dfc9b86cea80
http://hg.mozilla.org/mozilla-central/rev/9c1bea8d506b
http://hg.mozilla.org/mozilla-central/rev/742bc2628690
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing][softblocker] → [softblocker]
Comment 10•14 years ago
|
||
Documented:
https://developer.mozilla.org/en/Gecko-Specific_DOM_Events#MozAfterPaint
https://developer.mozilla.org/en/Preferences/Mozilla_preferences_for_uber-geeks
Also noted on Fx4 for developers.
Keywords: dev-doc-needed → dev-doc-complete
Comment 11•14 years ago
|
||
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?
Comment 12•14 years ago
|
||
(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.
Comment 13•14 years ago
|
||
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]
Updated•14 years ago
|
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.
Description
•