Update the general page of about:preferences, as well as the Connection Settings panel, to show
when an extension is controlling proxy settings, and allow a user to disable the extension to
regain control.
MozReview-Commit-ID: HKYPkg78IOK
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
This moves all the functions that manage/change the UI because of extensions being in
control of certain preferences to a separate file, so it can be included in SubDialogs.
MozReview-Commit-ID: 7OkEn478Pus
This adjusts both the new Tracking Protection UI and the old Tracking Protection UI on
about:preferences to indicate when an extension is controlling Tracking Protection. It
will disable the controls on about:preferences if an extension is in control, and provide
a button to disable the extension.
MozReview-Commit-ID: G04jWrS6Pr9
Computing the subcategory based off of just the hash doesn't work when switchToTabHavingURI is used to open the preferences.
MozReview-Commit-ID: 5rYkiLkDgfT
Due to bug 1357841 we cannot put the help button as low as the spec desired (14px from the bottom). However the patch will reduce the bottom offset when the height of the window is low so as not to waste space.
Ian Ferguson <xfergusi@gmail.com> contributed substantially to this patch.
MozReview-Commit-ID: 4Dxa30RmSBZ
Code written by Manotej Meka <manotejmeka@gmail.com> and Ian Ferguson <fergu272@msu.edu>
This is the initial landing of the search feature, and is preffed off behind
browser.preferences.search.
MozReview-Commit-ID: 7iaeRsIIV3Y
Code written by Manotej Meka <manotejmeka@gmail.com> and Ian Ferguson <fergu272@msu.edu>
This is the initial landing of the search feature, and is preffed off behind
browser.preferences.search.
MozReview-Commit-ID: 7iaeRsIIV3Y
The FX_PREFERENCES_CATEGORY_OPENED probe must be extended to version 59 to support the fallback "forked" preference implementation (in-content-old).
The switchToAdvancedSubPane within utilityOverlay's openPreferences must also remain until the fallback has been removed (bug 1349689).
Patch co-authored by Zack Herrick <herrickz@msu.edu> and Ziyan Long <lzylong@gmail.com>.
MozReview-Commit-ID: 1sx0Wj15yM7
The FX_PREFERENCES_CATEGORY_OPENED probe must be extended to version 59 to support the fallback "forked" preference implementation (in-content-old).
The switchToAdvancedSubPane within utilityOverlay's openPreferences must also remain until the fallback has been removed (bug 1349689).
Patch co-authored by Zack Herrick <herrickz@msu.edu> and Ziyan Long <lzylong@gmail.com>.
MozReview-Commit-ID: 1sx0Wj15yM7
In bug 1044586 we changed nsDocument::GetEventTargetParent such that events for
a document were not sent to its parent window if the inner window for the
document wasn't the current inner window. Unfortunately it seems this means
event listeners on the window sometimes miss user input events (mousedown etc.)
when user input takes place before the first paint of a new document that's
loading. In order to fix this, this patch backs out the changes from bug 1044586.
This reintroduces the issue we had before with the preference window, where
reloading the preferences quickly meant that its listeners (attached to the
window) got confused by DOMContentLoaded events from a previously loaded
document. Instead of the broad fix to nsDocument::GetEventTargetParent, this
patch simply changes the event listeners from the preferences code to be
attached to the document instead of the window, thus ensuring they only get
notified for events relating to their own document.
MozReview-Commit-ID: 9DImyNst9fS