User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20140904030202 Steps to reproduce: I set privacy.sanitize.sanitizeOnShutdown to true and looked it via CCK2. The other settings i looked are greyed out. This setting is in the UI still changeable.

Same behavior for the drag drop's there. The settings are blocked, but the dragDrops are still working in the UI. network.cookie.cookieBehavior - 3 network.cookie.lifetimePolicy - 2

While we would take a fix for this, we won't hold up shipping the in-content preferences until this is fixed.

Mike/Lars, can either of you help us triage this appropriately by providing screenshots/screencasts comparing the non-incontent prefs and the in-content ones? You can easily switch between them using the browser.preferences.inContent pref in about:config .

Here's a simple add-on that adds lock/unlock to about:config to make it easy to test this stuff. I'll still be producing the information that is needed.

Here's a movie showing the problem: https://www.dropbox.com/s/5h8vtm8yr1yd9p8/shutdownproblem.mov?dl=0

This bug is not a regression in the in-content preferences, as Mike's video shows. The video shows, and I confirmed with Mike's add-on, that the preference is only visibly disabled when the preferences value is changed.

Comment on attachment 8578489 [details] [diff] [review] Patch v1.2 Review of attachment 8578489 [details] [diff] [review]: ----------------------------------------------------------------- f+ pending test changes to ensure this either only runs with icp or works with non-icp pref panes. ::: browser/components/preferences/in-content/tests/browser_sanitizeOnShutdown_prefLocked.js @@ +1,2 @@ > +/* Any copyright is dedicated to the Public Domain. > +* http://creativecommons.org/publicdomain/zero/1.0/ */ You don't need this license header for test code, as we discussed in a previous bug. :-) @@ +6,5 @@ > +function runPaneTest(fn) { > + open_preferences((win) => { > + let doc = win.document; > + win.gotoPref("panePrivacy"); > + fn(win, doc); Nit: s/fn/callbackFn/ @@ +17,5 @@ > + menulist.focus(); > + EventUtils.sendKey("UP"); > +} > + > +function test() { If you make this an add_task'd thing, and make runPaneTest a generator that returns the window... @@ +30,5 @@ > + > + let checkbox = doc.getElementById("alwaysClear"); > + is(checkbox.disabled, false, "Always Clear checkbox should be enabled when preference is not locked."); > + > + gBrowser.removeCurrentTab(); This won't work with windowed prefs. Either enforce that this runs with in-content prefs, or (preferable) make it work with windowed preferences. :-) @@ +36,5 @@ > + Services.prefs.lockPref("privacy.sanitize.sanitizeOnShutdown"); > + runPaneTest(testPrefStateWhenLocked); > +} > + > +function testPrefStateWhenLocked(win, doc) { Then these two functions could be refactored into a single function that just takes an extra boolean, and then make the task call the function twice with separate params (and calling lockPref after the first call). That seems like it'd be clearer then the continuation-style function calling anyway (to my mind, that is, which I accept is a subjective judgment...).

Comment on attachment 8578769 [details] [diff] [review] Patch v2 Review of attachment 8578769 [details] [diff] [review]: ----------------------------------------------------------------- So... you've fixed it in non-incontent as well, but the test only tests in-content? I guess we can just do that for now...

Comment on attachment 8578769 [details] [diff] [review] Patch v2 Approval Request Comment [Feature/regressing bug #]: new feature, in-content prefs (icp) [User impact if declined]: icp behavior differences between firefox 38 and firefox 39 [Describe test coverage new/current, TreeHerder]: landed on mozilla-central for a week [Risks and why]: none expected. [String/UUID change made/needed]: none.

Verified fixed using latest Aurora 39.0a2 (buildID: 20150427004010) and Firefox 38 Beta 8 (buildID: 20150427090451).