User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140402030201 Steps to reproduce: Attempted to change Proxy settings using Tab Based Preferences after activating Tab Based Preferences in V28. Also tried using Firefox Nightly V31.0a1 2014-04-02. Same Full details are provided here. https://support.mozilla.org/en-US/questions/992884#answer-552125 Actual results: The changes to proxy settings would not stick either in V28 or the current Nightly listed above. The results were identical using V28 and the current Nightly. My detailed testing outlined in the link above explains this. Expected results: Changes should have stuck as they do when using the Options dialog to make the changes.

I can reproduce this. Don't know why it's happening just yet.

This seems to be because in the 'real' preferences implementation, this is opened as a 'subdialog', which MDN notes means its preference states get saved correctly when the 'main' dialog closes. I bet that isn't happening correctly because the in-content prefs call openDialog instead of openSubdialog.

You may be on to something there Gjis as from what I read elsewhere online changes made with the new tab based Preferences should be saved as soon as they are made as there is no explicit save procedure to put the change into effect as there is with the options dialog where you must click ok to close out of a dialog window. I can change other settings using the tab based preferences. For example I went into the General settings using tab based Preferences and changed the Download option and the Warn Me When Closing Multiple Tabs option and they stuck. Interestingly, when trying to change the proxy settings using tab based Preferences, it pops up a dialog box to make the proxy changes in and then ok them to close the dialog window, just as with the Options based Preferences dialog. I don't know if this is relevant or not but given the way changes used to be made and how they are made using tab based Preferences I thought it may be worth mentioning. Also, I did not test any other settings changes using the tab based Preferences other than the two mentioned above but it could be useful to test those where the change can be made right in the Preferences tab without any pop up dialog boxes requiring input and see if they stick.

Sorry Gijs, I misspelled your name in my previous post. Apologies. :)

AFAIK, it is necessary to set browser.preferences.instantApply = true

Jared, how does this play with the instantApply pref stuff in bug 1037225, and will that automatically fix this, or do we need to track this separately? In any case, it seems like we should ensure this is fixed before we ship in-content prefs... :-\

Gijs, when I use Advanced > Connection... to change the proxy settings they get saved for me. I can open the preferences, go to the dialog, type something in, hit OK, close the preferences tab, reopen preferences, go to the dialog, and the typed value from the previous preference instance is shown in the dialog. Am I missing some steps here? Is it only reproducible on some platforms (even though comment #0 says "Windows").

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #8) > Gijs, when I use Advanced > Connection... to change the proxy settings they > get saved for me. I can open the preferences, go to the dialog, type > something in, hit OK, close the preferences tab, reopen preferences, go to > the dialog, and the typed value from the previous preference instance is > shown in the dialog. > > Am I missing some steps here? Is it only reproducible on some platforms > (even though comment #0 says "Windows"). I don't know! I haven't re-tested since April... Maybe it's fixed already because of the sub-dialog work? Peter, can you retry on a recent build?

Camelia, can you test to see if this bug is still happening on the latest Nightly?

The issue is no longer reproducing with latest Nightly 37.0a1 (buildID: 20150106030201). It seems to be resolved. I've tested on Windows 7 64bit, Ubuntu 13.10 32bit and Mac OSX 10.9.5.

Thanks!

Fixed by Bug 1042300.

(In reply to Alice0775 White from comment #13) > Fixed by Bug 1042300. I don't understand. Did you mean a different bug? This bug explicitly says it's about in-content prefs, and all I did in bug 1042300 was disable in-content prefs...

(In reply to Gijs Kruitbosch from comment #14) > (In reply to Alice0775 White from comment #13) > > Fixed by Bug 1042300. > > I don't understand. Did you mean a different bug? This bug explicitly says > it's about in-content prefs, and all I did in bug 1042300 was disable > in-content prefs... I think in-content prefs is depend of Bug 1042300. Bug 1042300 turned on browser.preferences.instantApply in nightly(not release). and false in Beta and Release windows buid. If enable in-content prefs in the future, browser.preferences.instantApply should also be turn on .

(In reply to Alice0775 White from comment #15) > (In reply to Gijs Kruitbosch from comment #14) > > (In reply to Alice0775 White from comment #13) > > > Fixed by Bug 1042300. > > > > I don't understand. Did you mean a different bug? This bug explicitly says > > it's about in-content prefs, and all I did in bug 1042300 was disable > > in-content prefs... > > I think in-content prefs is depend of Bug 1042300. > Bug 1042300 turned on browser.preferences.instantApply in nightly(not > release). > and false in Beta and Release windows buid. This was subsequently changed by http://hg.mozilla.org/mozilla-central/rev/1ed7cff1a04a#l1.13 > If enable in-content prefs in the future, browser.preferences.instantApply > should also be turn on . Bug 1037225 is tracking potentially keeping instantApply=false for Windows but only if we can make sure that the subdialogs that depend on it continue working.