Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
- Implemented stored "install source of the extensions" for telemetry events.
- Added test assertions related to the expected install and addon installTelemetryInfo.
- Added installTelemetryInfo to addon installed from "drag-and-drop" file urls on Firefox Desktop.
Differential Revision: https://phabricator.services.mozilla.com/D4445
--HG--
extra : moz-landing-system : lando
Other (internal API) changes besides extension API changes:
- This also introduces support for opening a window with multiple tabs
in a non-default container tab.
- This also adds LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL to the
gBrowser.loadTabs call, unless allowInheritPrincipal is set. Currently
there are no callers that set this flag, but in case it's desired,
I added an opt-in via window.arguments[10] in browser.xul/js.
For single-argument URLs, the flag is an opt-out, since there are
multiple callers that rely on principal inheritance (bug 1475201).
Depends on D4928
Differential Revision: https://phabricator.services.mozilla.com/D4929
--HG--
extra : rebase_source : 23f496cd8a42d49f732e0ba4bae7cb0cc8aa5818
The container tab indicator should also be set on the tab, not just on
the browser. Otherwise it is possible for the indicator to be missing
when a new window is opened.
And previously, if the URL was an "about:blank" URL, the tab in the new
window would use the default container because of the early return in
_handleURIToLoad. This is fixed by accounting for window.arguments[6]
when initializing the default (about:blank) tab in the tabbrowser.
Unit tests for these code path will be added in bug 1393570.
Differential Revision: https://phabricator.services.mozilla.com/D4920
--HG--
extra : moz-landing-system : lando
The pagehide handler has been as dead as a doornail for a while now,
but the side-effect of forcing the creation of an about:blank document
in non-remote windows was implicitly relied upon by some tests.
This removes the dead code and fixes up some tests.
Differential Revision: https://phabricator.services.mozilla.com/D4962
--HG--
extra : moz-landing-system : lando
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
This stops us from showing a pending space when an icon is added after loading is
complete causing us to shift the title when both pending and previous icon are
shown.
Differential Revision: https://phabricator.services.mozilla.com/D4694
--HG--
extra : moz-landing-system : lando
This restores the previous behavior where we set the selection only when setting a new different value
Differential Revision: https://phabricator.services.mozilla.com/D4528
--HG--
extra : moz-landing-system : lando
The fix in bug 1418793 accidentally removed the onCloseWindow call, which
meant we were setting `.enabled` on taskbar window objects whose windows
were already dead, which was causing crashes.
I've reverted the removal, and also added some nullchecking, because the
C++ component shouldn't make it this easy for consumers to cause crashes.
Differential Revision: https://phabricator.services.mozilla.com/D4559
--HG--
extra : moz-landing-system : lando
This adds a simple empty box that is displayed when we're still loading an icon
but are no longer showing the throbber. Ideally I'd like to keep showing the
throbber and maintain the busy state but that seems more risky for now.
Differential Revision: https://phabricator.services.mozilla.com/D2364
--HG--
extra : moz-landing-system : lando
This is an extension of the work in Bug 1473160 to make clear in what environments
various gBrowserInit functions are run. Since we currently use these in an `if` block
in browser.js for "navigator:browser" window types, and browser.xul is the only
navigator:browser window that loads browser.js, this moves the event listeners directly
into browser.xul so it's extra clear that they don't run in non-browser top level windows on OSX.
Also move a few on-event handlers from the <window> tag into this block so they
all happen in one place.
Differential Revision: https://phabricator.services.mozilla.com/D4137
--HG--
extra : moz-landing-system : lando
Initialize WindowsPreviewPerTab later, and make its favicon update code more efficient.
Differential Revision: https://phabricator.services.mozilla.com/D2679
--HG--
extra : moz-landing-system : lando
Creating non-shared scopes for frame scripts is fairly expensive. After these
changes it's even more expensive. However, many frame scripts have no use for
the shared scopes at all. Run-once scripts which execute in closures, for
instance, make no use of them. And after bug 1472491, neither do most of our
default frame scripts.
MozReview-Commit-ID: 9PK7bYdQ0yh
--HG--
extra : rebase_source : db2516d2f00a75e233e1957649f2b62a9299b7cd
This commit switches the identity popup to use "Content Blocking" as a top-level section
instead of Tracking Protection, which is now demoted to a category of Content Blocking.
To keep this change halfway reviewable, I avoided renaming variables, classNames, ids, etc.
that use the term trackingProtection if they were otherwise unaffected by this patch. There
will be other patches that can do this in the future
Differential Revision: https://phabricator.services.mozilla.com/D2775
--HG--
rename : browser/base/content/browser-trackingprotection.js => browser/base/content/browser-contentblocking.js
extra : rebase_source : 0dd57d6142c971617e9f47d32ce76a4a028d98eb
This allows the JS to work in HTML documents, where whitespace is preserved. In XUL
documents, whitespace is ignored when parsing so text nodes are generally not returned.
The following changes were made, with manual cleanups as necessary (i.e. when firstChild actually
refers to a text node, or when firstChild is used in a loop to empty out an element):
firstChild->firstElementChild
lastChild->lastElementChild
nextSibling->nextElementSibling
previousSibling->previousElementSibling
childNodes->children
MozReview-Commit-ID: 95NQ8syBhYw
--HG--
extra : rebase_source : 186d805f7a2a56694dda9032aceac2dfe5424753
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : 9c400bed3c9d29a186fc987c9bd0ffceb37bfd94
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
--HG--
extra : rebase_source : c525350a1954740873e85b045cbb14a8b43aa89d
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : b15f75e39d04c8485b4eb63416fd1f1e4175fafe
Make URLBarSetURI more explicit about what it's looking for in `value`,
and ensure the tabbrowser's progress listeners reset the userTypeValue if it's
empty already and there's a same-site document change.
Differential Revision: https://phabricator.services.mozilla.com/D2181
--HG--
extra : moz-landing-system : lando
These are mac-only functions used to support the dock and application menu for
non browser windows (anything that includes macWindow.inc.xul). Make this more
straightforward by splitting the code out into a new script file that gets loaded
directly by macWindow.inc.xul rather than unconditionally adding the functions
and only calling them when needed.
MozReview-Commit-ID: 8y3rij5vqyh
--HG--
extra : rebase_source : 4e9aae343a41ed497e7da1e2c7acab3d42fea8a2
Also changes the tooltip on the home button to be independent of the URLs
it opens, per dolske.
Some tests explicitly set browser.startup.homepage, but only through
SpecialPowers.putPrefEnv. That's a good compromise, given the extra
functionality there.
MozReview-Commit-ID: FPLxzi3jQAP
--HG--
extra : rebase_source : c2b014f2fb1c78ce04859344bd1803ef48d5d68d
The menuitem used to be only included in the markup for the non-browser window
case. This changes it to include it as a hidden <menuitem> for the browser window
case, and then unhide it for the non-browser window case.
MozReview-Commit-ID: 8tY3GiTFmqe
--HG--
extra : rebase_source : 4628aa160fefcb5eacad0e6b174be7216071bda1
The key used to be removed from the markup. This changes it to include
the <key> but instead disable it through the related command, which fits
the pattern used with other commands.
MozReview-Commit-ID: LPuwULDt22W
--HG--
extra : rebase_source : f463e41602b6c34c4cfcc2254d78647724117318
Summary:
This moves the load of favicons into the content process. We use the same logic
for finding favicons (based on waiting until none have shown up for a short
time) but then load the favicon and convert it to a data uri which we then
dispatch to the parent process. Along the way this fixes asssociating the load
with the tab for WebExtension and devtools, fixes CSP usage for the load, fixes
expiry detection of the favicon and stops us from loading the same resource
twice.
This change also merges the prefs browser.chrome.site_icons and
browser.chrome.favicons leaving just the former controlling favicon loading. It
adds the pref browser.chrome.guess_favicon to allow disabling guessing where
a favicon might be located for a site (at <hostname>/favicon.ico). This is
mainly to allow disabling this in tests where those additional yet automatic
requests are uninteresting for the test.
There are multiple clean-ups that can follow this but this is a first step along
that path.
MozReview-Commit-ID: E0Cs59UnxaF
Reviewers: mak
Tags: #secure-revision
Bug #: 1453751
Differential Revision: https://phabricator.services.mozilla.com/D1672
Differential Revision: https://phabricator.services.mozilla.com/D1673
Differential Revision: https://phabricator.services.mozilla.com/D1674
Differential Revision: https://phabricator.services.mozilla.com/D1850
Differential Revision: https://phabricator.services.mozilla.com/D1869
--HG--
rename : browser/base/content/test/general/browser_bug408415.js => browser/base/content/test/favicons/browser_bug408415.js
rename : browser/base/content/test/general/browser_bug550565.js => browser/base/content/test/favicons/browser_bug550565.js
rename : browser/base/content/test/general/browser_favicon_change.js => browser/base/content/test/favicons/browser_favicon_change.js
rename : browser/base/content/test/general/browser_favicon_change_not_in_document.js => browser/base/content/test/favicons/browser_favicon_change_not_in_document.js
rename : browser/base/content/test/general/browser_subframe_favicons_not_used.js => browser/base/content/test/favicons/browser_subframe_favicons_not_used.js
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon1.ico
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon2.ico
rename : browser/base/content/test/general/file_bug970276_popup1.html => browser/base/content/test/favicons/file_bug970276_popup1.html
rename : browser/base/content/test/general/file_bug970276_popup2.html => browser/base/content/test/favicons/file_bug970276_popup2.html
rename : browser/base/content/test/general/file_favicon_change.html => browser/base/content/test/favicons/file_favicon_change.html
rename : browser/base/content/test/general/file_favicon_change_not_in_document.html => browser/base/content/test/favicons/file_favicon_change_not_in_document.html
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_generic_favicon.ico
rename : browser/base/content/test/general/file_with_favicon.html => browser/base/content/test/favicons/file_with_favicon.html
extra : rebase_source : 6372b2681a59d267f966e9fa2ca9a54e3ff0cea0
extra : intermediate-source : b11aa832c41ac5beef9065f804d11fb7c9887990
extra : source : 638eb8a41245f6d9932861afda21edd5e0b2618a
Summary:
This moves the load of favicons into the content process. We use the same logic
for finding favicons (based on waiting until none have shown up for a short
time) but then load the favicon and convert it to a data uri which we then
dispatch to the parent process. Along the way this fixes asssociating the load
with the tab for WebExtension and devtools, fixes CSP usage for the load, fixes
expiry detection of the favicon and stops us from loading the same resource
twice.
This change also merges the prefs browser.chrome.site_icons and
browser.chrome.favicons leaving just the former controlling favicon loading. It
adds the pref browser.chrome.guess_favicon to allow disabling guessing where
a favicon might be located for a site (at <hostname>/favicon.ico). This is
mainly to allow disabling this in tests where those additional yet automatic
requests are uninteresting for the test.
There are multiple clean-ups that can follow this but this is a first step along
that path.
MozReview-Commit-ID: E0Cs59UnxaF
Reviewers: mak
Tags: #secure-revision
Bug #: 1453751
Differential Revision: https://phabricator.services.mozilla.com/D1672
Differential Revision: https://phabricator.services.mozilla.com/D1673
Differential Revision: https://phabricator.services.mozilla.com/D1674
Differential Revision: https://phabricator.services.mozilla.com/D1850
--HG--
rename : browser/base/content/test/general/browser_bug408415.js => browser/base/content/test/favicons/browser_bug408415.js
rename : browser/base/content/test/general/browser_bug550565.js => browser/base/content/test/favicons/browser_bug550565.js
rename : browser/base/content/test/general/browser_favicon_change.js => browser/base/content/test/favicons/browser_favicon_change.js
rename : browser/base/content/test/general/browser_favicon_change_not_in_document.js => browser/base/content/test/favicons/browser_favicon_change_not_in_document.js
rename : browser/base/content/test/general/browser_subframe_favicons_not_used.js => browser/base/content/test/favicons/browser_subframe_favicons_not_used.js
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon1.ico
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon2.ico
rename : browser/base/content/test/general/file_bug970276_popup1.html => browser/base/content/test/favicons/file_bug970276_popup1.html
rename : browser/base/content/test/general/file_bug970276_popup2.html => browser/base/content/test/favicons/file_bug970276_popup2.html
rename : browser/base/content/test/general/file_favicon_change.html => browser/base/content/test/favicons/file_favicon_change.html
rename : browser/base/content/test/general/file_favicon_change_not_in_document.html => browser/base/content/test/favicons/file_favicon_change_not_in_document.html
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_generic_favicon.ico
rename : browser/base/content/test/general/file_with_favicon.html => browser/base/content/test/favicons/file_with_favicon.html
extra : rebase_source : 1e72949e4e1012025ccf87642cc239ea5f15217d
extra : source : 638eb8a41245f6d9932861afda21edd5e0b2618a
This notification fires when a browser window finishes running its idle tasks. Note
that it might never run if every window goes away before the idle tasks can run.
MozReview-Commit-ID: IEH98S29jhV
--HG--
extra : rebase_source : e15e496d5bd41a2ca2aaa170e3546491a9383ba5
This notification fires when a browser window finishes running its idle tasks. Note
that it might never run if every window goes away before the idle tasks can run.
MozReview-Commit-ID: IEH98S29jhV
--HG--
extra : rebase_source : c00e7053a3a18215a3549ea6fd7c7194dd4ca584
This removes the bookmark description UI, but leaves the backend in-place for a release or two, so that users have time to save anything they want (e.g. via backup).
The backend will be removed in bug 1402890.
MozReview-Commit-ID: La4AYFar7eK
--HG--
extra : rebase_source : 02bfe3cacdac331d09d5e62a1a70f48b68741670
This implements a new button in the identity popup that allows users to quickly
remove cookies and site data from the sites they're visiting.
This uses the SiteDataManager behind the scenes and is similar to the changes
we made for PageInfo already.
There's a major drawback to this approach in that SiteDataManager needs to
refresh its entire data set everytime we want information about a single site
or want to remove anything (it's not trivial to get rid of that limitation while
dealing with all the quirks of our storage APIs). I will work around this by
implementing a way for SiteDataManager to incrementally update itself in bug 1460768.
MozReview-Commit-ID: Iy7ia0KllFq
--HG--
extra : rebase_source : a36e0e7049c5892464d91ad42c3bf523dd5013f9
