We want to show an informative message about dedicated profiles per channel to
users of Nightly on a specific date. We currently only have the ability to do
this when the version changes. This adds the ability to show a page once on
startup on a specific date.
This will probably be backed out past that date.
Differential Revision: https://phabricator.services.mozilla.com/D16249
We want to show an informative message about dedicated profiles per channel to
users of Nightly on a specific date. We currently only have the ability to do
this when the version changes. This adds the ability to show a page once on
startup on a specific date.
This will probably be backed out past that date.
Differential Revision: https://phabricator.services.mozilla.com/D16249
Still waiting on a couple of details from product but I'd like to get the review
started now as we will want to land this a.s.a.p.
Differential Revision: https://phabricator.services.mozilla.com/D16249
If we QI nsIPropertyBag on an XPCWrappedNative wrapping an XPCWrappedJS, calling
the getProperty method might incorrectly end up calling .getProperty on the
XPCWrappedJS itself, because it also implements nsIPropertyBag.
This became a problem with same-compartment chrome globals because if we no longer
cross a compartment boundary, we don't create a new WrappedNative and can now end up
seeing the nsIPropertyBag if it got queried before nsIWritablePropertyBag.
Depends on D15076
Differential Revision: https://phabricator.services.mozilla.com/D15077
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
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
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
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
Manually-implemented QueryInterface functions don't benefit from the
MozQueryInterface optimizaions, and a lot of them are in hot code, and
implement a large number of interfaces.
MozReview-Commit-ID: 8OzglraowZt
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
Add a `--screenshot` argument that implies `--headless` and is used to take a screenshot of a page from the command line.
Default is a full page screenshot, but `--window-size=width[,height]` can change this.
A path for the screenshot can be supplied with `--screenshot=/path/to/file`.
MozReview-Commit-ID: 13tUjk2Yrsl
This patch enables sending the "update" ping with reason "success"
after the browser is restarted when an update is successfully applied.
MozReview-Commit-ID: 8LYxhTTrs7l
