Original patch by Tyler Maklebust <tmaklebust@gmail.com> and Jared Beach <beachjar@msu.edu>
MozReview-Commit-ID: 7FW6PHIrXF4
--HG--
extra : rebase_source : e8132fc8af91657ca80f18a841101bc1070c8b15
Reading application.ini involves using nsCOMPtr<nsIFile>, and that can
only happen through the XPCOM glue, which we eventually want to get rid
of.
So, while keeping the command line argument/environment variable
handling in nsBrowserApp, we move the actually parsing of the file to
XRE_main, where things can be handled without the XPCOM glue.
--HG--
extra : rebase_source : 487960a671476d4edae4f568c37efa6563ef4dff
This just wraps all the XRE method calls to go through the Bootstrap API
instead of relying on the XPCOM glue methods.
--HG--
extra : rebase_source : eccbe18b9b21ca1ab6c403515ffd60f0a9174d9c
Instead of having nsBrowserApp.cpp set a flag in XREAppData to indicate
whether the DLL blocklist properly initialized, just have XRE code ask
the blocklist itself.
--HG--
extra : rebase_source : e872853481acce68b325909e476d009aec878701
This hasn't been used since the removal of the Metro code in bug
1039866, close to two years ago.
--HG--
extra : rebase_source : 58ec1ce63e4231c8006cafd3424675f14ddbf9f1
It turns out nsAppRunner.cpp sets it to the exact same thing when it's
not already set, so we might as well use that.
--HG--
extra : rebase_source : cb8955e75c13a02494f3e163089c53696a661aa9
Back in bug 632404, when the function was added, preloading was
conditional. But after some A/B testing, the conclusion in bug 771745
was that we would just do preloading unconditionally.
Which means in practice, we don't need to have a function to enable it
manually anymore, since we're always enabling it.
--HG--
extra : rebase_source : c76307c13c057e87e1fe4564b82113fbfa20d382
There are 3 issues this tackles:
- we were keeping a reference to the notification we added (this.notice),
which kept windows alive.
- we had the CleanupManager keep a reference to our close method, which kept
a reference to us, which kept a reference to the window.
- the fact that we use timeouts to call this.close() in 2 places meant
this.close would get called multiple times, which meant we errored out on
later occasions, because various things had been nulled out. This tidies up
the timeouts when cleanup is called to avoid re-entrancy/errors/leaks.
MozReview-Commit-ID: EYvK7bQEh3X
--HG--
extra : rebase_source : 8646b7fe965b7110a69a728b54e5c149c750f9c3
The devtools theme is no longer relevant when dealing with compact themes, since it doesn't
affect the theme colors. But we still need it for styling other things related to devtools
in browser.xul, like the splitter between the toolbox and page and gcli.
MozReview-Commit-ID: 2CXDuwQY19x
This commit does the following:
* Install two lightweight themes instead of one
* Introduce a build config to install the themes instead of relying on channel: INSTALL_COMPACT_THEMES
* Change browser-compacttheme to use the new themes instead of the old one
* Remove inferBrightness since the lwt colors are part of the compact theme definision, as opposed
to the devedition theme which could be light or
* Update CSS to use :-moz-lwtheme-darktext and :-moz-lwtheme-brighttext instead of [devtoolstheme]
MozReview-Commit-ID: 4gKU68drlE2
--HG--
rename : browser/base/content/defaultthemes/devedition.header.png => browser/base/content/defaultthemes/compact.header.png
We won't need this anymore, since there will be a separate light and dark theme
definition, so we can update the theme definition to allow the brightness to be
inferred automatically by the lightweight theming system.
MozReview-Commit-ID: 3GuZ3Qezc1F
