Reorder the construction of Preference objects so network.proxy.autoconfig_url gets constructed before network.proxy.type, which will ensure that networkProxyAutoconfigURL is set to the value of network.proxy.autoconfig_url before network.proxy.type construction triggers the call to updateReloadButton.
MozReview-Commit-ID: BQL0RlvnCOo
We recently updated the cookie settings in about:preferences to live outside
of the history mode settings, but did not change the way that changes to history
mode (toggling the privatebrowsing.autostart pref) reflected in the cookies section.
This patch takes care of that by moving the cookie related pieces out of the code
that sets history settings and makes sure that the respective functions get called
in all appropriate cases.
I also moved some site data settings code to be closer to the cookies code.
MozReview-Commit-ID: 6ly079uDz4C
It seems `doCommand` runs through a different codepath than just clicking the checkbox,
and as a result the outcome of the command handler is different that way.
This aligns the automated test closer to what happens when you 'manually'
click the checkbox, and fixes the bug in the command handler.
MozReview-Commit-ID: ACxRUxB35px
When moving cookies to the site data section we forgot about some
searchkeywords which were left on the cookies exceptions dialog.
We also forgot to remove the status column label when removing the
status column.
Further, the search tooltip is not displayed correctly on the three
vertically aligned dialog buttons (it's always on the last button),
because we did not put each of them in its own hbox (which is just way
too easy to get wrong and needs a better mid term solution).
MozReview-Commit-ID: L6ZaocWsjYU
When adding more characters to the description in the site data section,
the display of the adjacent items breaks in two ways:
- The "Learn More" link is pushed to the next line while it should stay
on the same line as the description. I didn't really find a way to fix
this while using a XUL label, so I switched to an html:span which has
the correct layout. I don't see any drawbacks with using a span here.
- The description text could in certain edge cases get too close to the
"Clear Data" button. To fix that I added a new class which adds some padding.
This isn't a problem in other parts of preferences except the history
section (bug 1441138), where I also added this class.
MozReview-Commit-ID: FO5tEx19ZUm
Without any flex, the checkboxes in the Privacy section of about:preferences
refused to wrap their text and caused the page width to expand to accommodate
them, which made the search box and other elements move around while performing
searches as the page width changed.
Adding flex means the checkbox wraps text to the next line when the label is
longer than the width can accommodate.
MozReview-Commit-ID: HtJ3f3KrO3X
This changes the disk space notification to show the correct preferences path
and to use the correct openPreferences arguments.
MozReview-Commit-ID: BuKAUvDjp9T
After including cookies in the site data manager in bug 1421737, we would
like to move the cookies settings to the site data section to give them
more visibility and to unify site data and cookies.
Our UR has shown that our differentiation between site data and cookies
is not helpful to users and that they struggle with discovering the
cookie settings that are hidden in the "custom history" menu.
Since the cookie settings are quite powerful/potentially breaking,
we changed the top level preference from a checkbox to a radiogroup,
to be able to highlight the potential breakage associated with "deny".
This grouping is also recommended by the webstorage spec:
https://www.w3.org/TR/webstorage/#privacy
The cookies dialog is not removed yet, because it is still accessible from
Page Info, but bug 1348223 will likely remove it entirely.
MozReview-Commit-ID: Adisn70Ks2Q
In search.js, _updateSuggestionCheckboxes is already hooked up to update this checkbox
based on the preference value, including change handlers for when it changes. As a result,
having both the preference attribute and the 'manual' JS means that the actual checked and
disabled state races with which code sets the value first.
The search suggestion order preference already doesn't have a preference attribute and is
only ever updated via the JS. It seems sensible to do the same here.
MozReview-Commit-ID: Cm8evlembt7
