This patch causes Firefox processes created via LaunchChild to start via the
launcher process.
While this extra hop through the launcher process takes longer than if we were
to simply make LaunchChild use the same code as the launcher process itself,
I do not want to simply export LauncherProcessMain from firefox.exe, as that
would be too easy to hook into and mess with.
Another option would be to host a second copy of the launcher code inside
xul.dll, but that's less than ideal.
Anyway, until we get that figured out, I don't think it's too big a deal to
have this extra hop in place. I don't think anybody has been clamoring for
faster restarts from the updater or the profile manager.
Depends on D4496
Differential Revision: https://phabricator.services.mozilla.com/D4497
--HG--
extra : moz-landing-system : lando
Add a GeckoSession property too specify if media should be suspended when the session is inactive.
Differential Revision: https://phabricator.services.mozilla.com/D4472
--HG--
extra : moz-landing-system : lando
In many places, nsTArray::IndexOf is followed by accessing that element
(hopefully with `Elements() + index`, which skips unnecessary bounds checks.)
But this pattern introduces operations that could be avoided:
- IndexOf converts the address of the found element into an index,
- The caller must test for a special `NoIndex` value,
- On success, accesses convert that index back into the original address.
This patch introduces new 'ApplyIf...' functions that combine all these
operations in a more efficient ensemble: If the sought element is found, it is
passed by reference to a given callable object (usually a lambda); if not
found, another callable is invoked.
Depending on what they need, the first callable may take one of these parameter
lists: (), (size_t), (maybe-const elem_type&), (size_t, maybe-const elem_type&).
On top of removing the pointer->index->pointer operations in most cases,
invoking callables directly from ApplyIf is safer, as the array is guaranteed to
be untouched at this time.
Also, being templates taking function objects, in most cases the compiler should
be able to inline and optimize the search and its callables' code.
This patch gives example uses in nsTArray::Contains, and in
FrameProperties::GetInternal, SetInternal.
And FrameProperties::Has now calls Contains, which is more efficient because
the former code would compute an index (or NoIndex), and then convert that index
to a bool; whereas the new code directly produces a bool from within the search
algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D2758
--HG--
extra : moz-landing-system : lando
Notes:
* NS_Atomize never returns null, so this patch removes a null check on its
return value.
* There's no need for the |atom| local variable and for our swap() call on it.
It's equivalent and simpler for us to just directly assign mWatchID, rather
than to use this disposable local variable.
Differential Revision: https://phabricator.services.mozilla.com/D4394
--HG--
extra : moz-landing-system : lando
This makes the about:privatebrowsing display "Content Blocking" instead
of "Tracking Protection" and makes the toggle flip the TP setting for PB
mode as well as the CB pref if it's turned off.
Differential Revision: https://phabricator.services.mozilla.com/D4395
--HG--
extra : moz-landing-system : lando
When building with the NDK clang, which is the easiest way of building locally,
NDK r17 doesn't work for ARM builds because of a broken clang, and while the
NDK r18-beta fixes that problem, for some people it causes a different set of
issues.
Since NDK r15c doesn't have the ndk-version.h headers, switch to a different
way of bridging the differences that allows people to continue building with
r15c locally.
Differential Revision: https://phabricator.services.mozilla.com/D4471
--HG--
extra : moz-landing-system : lando
As of this patch, any lint issue at the "warning" level will *only* be displayed
if --warnings is passed in. This gives us some flexibility to track issues that
are "recommended to fix" but that aren't required (aka don't cause a backout).
I think it would be ideal if the reviewbot ran with warnings enabled, and CI
ran without warnings. This way these issues will be surfaced to developers
(and hopefully get fixed prior to landing), but developers will always be able
to ignore them if the situation warrants it.
Since the last change converted everything to use errors, this patch should
be a no-op for now. However as we move forward (and potentially decide that
certain types of lint issues should result in a backout), this feature will
start seeing more and more use.
Depends on D3820
Differential Revision: https://phabricator.services.mozilla.com/D3821
--HG--
extra : moz-landing-system : lando
Soon, warnings will be suppressed by default and won't causes a failure.
Therefore to prevent loss of coverage, we need to make sure that any
lint warning that causes a failure today, needs to be converted to an
error so it keeps failing tomorrow.
Depends on D3819
Differential Revision: https://phabricator.services.mozilla.com/D3820
--HG--
extra : moz-landing-system : lando
When any scrollbar color is specified, or scrollbar-width is thin, we
switch to use the fallback rendering.
The change to xulscrollbars.css is for ensuring that the scrollbar is
displayed for scrollbar-width: thin when there is no scrollbar color
specified. It wouldn't affect cases where -moz-appearance takes effect.
This also changes the fallback width of the scrollbars. Since the two
widths was picked rather randomly, I think it should be fine to change
it if a value looks better than the old one, especially on Linux which
is the main usecase for this fallback rendering.
Differential Revision: https://phabricator.services.mozilla.com/D3952
--HG--
extra : moz-landing-system : lando
Opening a new tab with a hardcoded link with the system utility openWebLinkI
was erroring when passing in getSystemPrincipal. Updating code to pass in a
createNullPrincipal.
Differential Revision: https://phabricator.services.mozilla.com/D4262
--HG--
extra : moz-landing-system : lando
This flag and function name are used for both basic shapes and path function,
so rename it. For now, we treat path() and other basic-shapes as the
different object (i.e. StyleSVGPath and StyleBasicShape), so I rename
these functions and mask flag.
Differential Revision: https://phabricator.services.mozilla.com/D3636
Create clip-path for the path function and reuse some APIs in
nsCSSClipPathInstance, so we don't have to update the code flow.
Differential Revision: https://phabricator.services.mozilla.com/D3635
For now, |clip-path: path()| is chrome-only, and not for shape-outside,
so we only implement the parser for clip-path. Besides, I didn't put
path() in BasicShape because path() doesn't use the reference box to
resolve the percentage or keywords (i.e. SVG path only accept floating
point or integer number as the css pixel value). Therefore, I add it into
ShapeSource, instead of BasicShape.
Differential Revision: https://phabricator.services.mozilla.com/D3633
SVGPathData will be used by clip-path and offset-path (and/or more on the
properties which support <basic-shape>). Therefore, let's move
SVGPathData out of motion.rs.
Differential Revision: https://phabricator.services.mozilla.com/D3631
As initially implemented, nsITLSServerSocket by default enabled the use of the
TLS session cache provided by NSS. However, no consumers of nsITLSServerSocket
actually used it. Because it was an option, though, PSM had to jump through some
hoops to a) make it work in the first place and b) not have NSS panic on
shutdown. Furthermore, it meant increased memory usage for every user of Firefox
(and again, nothing actually used the feature, so this was for naught).
In bug 1479918, we discovered that if PSM shut down before Necko, NSS could
attempt to acquire a lock on the session cache that had been deleted, causing a
shutdown hang. We probably should make it less easy to make this mistake in NSS,
but in the meantime bug 1479918 needs uplifting and this workaround is the
safest, most straight-forward way to achieve this.
Differential Revision: https://phabricator.services.mozilla.com/D3919
--HG--
extra : moz-landing-system : lando
MozBeforeInitialXULLayout doesn't fire in HTML docs. Even if we change it to
start firing for all top-level docs, it ends up firing _before_ the inline script
runs inside of browser.xul. For now, run that logic in DOMContentLoaded to
at least get a more functional browser window.
Differential Revision: https://phabricator.services.mozilla.com/D4138
--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
I made the variable name up, since I didn't see another similar thing.
Let me know if I should change it.
Differential Revision: https://phabricator.services.mozilla.com/D4239
--HG--
extra : moz-landing-system : lando
