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
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
This is a regression from bug 1429593. The code that was added to enable/disable controls on the page
depending on whether an extension is in control was being run when the page opened, which overrode
the code which disables specific controls based on the current proxy setting. All that is needed is
to call that code (which is in gConnectionsDialog.proxyTypeChanged()) if an extension is not in control
after the new code that was added. This patch fixes that issue, and includes a test verifying that
the manual controls are not enabled when the screen first opens.
MozReview-Commit-ID: 7jpp1wewZ2k
