Bug 70033 pertains to simple prefs which allow themselves to be disabled by the nsWidgetStateManager object. This leaves out other elements which do special handling and need additional modifications in order to recognise and disable xul elements which should be locked. e.g. proxy settings.

Marking NEW.

This patch handles two areas in the quest for locking the front end ui: javascript - where there was code to enable/disable an element based on logic, I modified to also take into account the Locked state of the element. Buttons (and one menubar) - this was handled in two ways. Some buttons have a very strong relationship to another element. Such as the homepage url and the use page, and choose file buttons. In such cases, the button is observing the disabled state of the related element. In other cases, there is no such relationship, and I added the numerous pref attributes needed to allow buttons to be handled by the widget state manager/pref window. An easy way to see which buttons now are pref locked, is to grep for the string disable_button in the xul files. On an unrelated note, I'm going to file another bug to remove 4 files which are no longer being used in the xpfe hierarchy. They have apparently moved to the extensions hierarchy.

Nevermind the removal of files comment. I pulled a new tree and those files have been removed, it just wasn't reflected in my old tree.

Hi, anyone interested in reviewing these changes? Thanks

Adding keywords

eClient issue, assigning QA to luke adding sarah to Cc.

Style nits: + if( emailCollection.checked &amp;&amp; !emailCollection.disabled ){ yeck. can you place a CDATA section (<![CDATA[ .. ]]>) inside the <script> node so that these ampersands won't look so hideous? ;) onState() +{ + if ( parent.hPrefWindow.getPrefIsLocked(gNewTypeButton.getAttribute("prefstring")) ) + gNewTypeButton.disabled = true; + if ( parent.hPrefWindow.getPrefIsLocked(gEditButton.getAttribute("prefstring")) ) + gEditButton.disabled = true; + if ( parent.hPrefWindow.getPrefIsLocked(gRemoveButton.getAttribute("prefstring")) ) + gRemoveButton.disabled = true; or, gNewTypeButton.disabled = parent.hPrefWindow.getPrefIsLocked(gNewTypeButton.getAttribute("prefstring"); etc. Finally if (foo) { bar } else if (bar) { foo } looks better without the parens for single line bar and foo. ;) apart from that, sr=ben

Few more nits: - document.getElementById("addDomainButton").setAttribute ("disabled","true"); + addDomainButton.setAttribute("disabled","true"); You should use .disabled here (and in the areas around that), since you do elsewhere. - <button class="dialog" label="&viewTutorial.label;" accesskey="&viewTutorial.accesskey;" oncommand="viewTutorial();"/> + <button class="dialog" label="&viewCookies.label;" accesskey="&viewCookies.accesskey;" oncommand="viewCookies();" + id="viewCookieButton" pref="true" preftype="bool" Can you make sure the first attribute on the second line is aligned with the first attribute on the first line? Thanks. Otherwise, r=blake

checked in. marking fixed

changing qa contact to myself.

Verified fix on commercial 2001053004 win32, 2001053008 linux, and 2001053005 mac.