This patch fixes two things:
1) A potential threading issue in setting and reading the PrincipalHandle for
MediaPipelineReceiveVideo.
2) Plumbs the PrincipalHandle down to the receiving MediaPipelines right from
the start. It hasn't been necessary in the past as initially the principal
handed to a track's constructor is trusted, but it's good form and will help
clarify the situation for the next patch which switches the initial
principal from always-private to mostly-non-private. In most cases this
principal does no longer get updated after the track's been created, so it
helps to have a PrincipalHandle that matches the track's principal.
Differential Revision: https://phabricator.services.mozilla.com/D48946
--HG--
extra : moz-landing-system : lando
Update the comments, name, and fields to show it is agnostic of isize/bsize.
Differential Revision: https://phabricator.services.mozilla.com/D51739
--HG--
extra : moz-landing-system : lando
This code was assuming that the only non-opaque parts of compositor rendering would be the
parts of the window that had vibrancy. But now that the default window background is transparent,
we can have non-vibrant parts where we render into transparency. Dialog windows such as sheet
windows are an example of this.
So instead of using the non-vibrant region of the window as its opaque region, we now use
the region that is covered by opaque Gecko layers. This region is a lot more conservative:
For example, the main browser chrome is now entirely transparent, because the chrome's opaque
parts share a layer with its transparent parts.
As a result, this change slightly affects the CALayer partitioning in the main browser window:
The entire browser chrome is now transparent, not just the tab bar.
The web content area is still opaque.
I think this will be fine. The thing I'm most concerned about is that scrolling inside web
content might cause invalidations of pixels from the chrome, because then we'd recomposite
the CALayers that cover the vibrant tab bar. This doesn't seem to happen most of the time
though, from what I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D51466
--HG--
extra : moz-landing-system : lando
This is needed because under the new vibrancy model, vibrant -moz-appearance
values only work on elements that have nothing rendered behind them. The elements
with the vibrant appearance become truly transparent.
Differential Revision: https://phabricator.services.mozilla.com/D51465
--HG--
extra : moz-landing-system : lando
Now that there is no Gecko-contributed background color in the window any more,
there's nothing that needs to be cleared away. This simplifies things.
Differential Revision: https://phabricator.services.mozilla.com/D51464
--HG--
extra : moz-landing-system : lando
With -moz-appearance: dialog now always being transparent, setting up our own
vibrant views for sheet windows is no longer necessary. We now let the regular
sheet window background show through, and that background is already vibrant.
Differential Revision: https://phabricator.services.mozilla.com/D51462
--HG--
extra : moz-landing-system : lando
The window background will be contributed by the widget itself, which renders
them underneath Gecko's rendering.
As a result, -moz-appearance: dialog is now equivalent to the combination
-moz-appearance: none; background-color: transparent.
This change does not turn the widget itself transparent because nsCocoaWindow
does not allow top level windows to become transparent (ever since bug 1162649).
If we ever add support for top level widgets with transparent backgrounds again,
we will probably want to treat -moz-appearance: dialog differently from
-moz-appearance: none; background-color: transparent, but for now this is fine.
This change means that Gecko's rendering will go into transparent buffers. This
may result in some loss of subpixel AA in various cases.
In the main browser window, there are CSS backgound colors that cover all the
non-vibrant areas of the window, so in that window we still render mostly onto
opaque pixels.
Differential Revision: https://phabricator.services.mozilla.com/D51461
--HG--
extra : moz-landing-system : lando
This is preferable over a hardcoded color because it lets Gecko choose where the
window background should come from. We would like the background to be handled
by the OS widget, and prevent Gecko from painting a CSS background color.
Differential Revision: https://phabricator.services.mozilla.com/D51460
--HG--
extra : moz-landing-system : lando
For regular elements, whenever -moz-appearance is used, the CSS background is
ignored. Root elements were behaving specially, and the background color also
needed to be adjusted.
For example, for Windows 7, we have the following CSS rule;
```
:root {
background-color: transparent;
-moz-appearance: -moz-win-borderless-glass;
}
```
This change makes the root element more consistent with other elements, so the
extra `background-color: transparent` declaration is no longer necessary.
This change does not let content documents opt out of forced opaqueness:
Root content documents still get an opaque background color from an existing
check further down in this method.
Differential Revision: https://phabricator.services.mozilla.com/D51459
--HG--
extra : moz-landing-system : lando
On macOS, the OS window always comes with an opaque background for top level
windows. This is the case even if Gecko determines the root element of the
window to be transparent: Ever since bug 1162649, nsChildView/nsCocoaWindow
ignore calls to SetTransparencyMode for top level windows and always stay opaque.
Returning true from nsChildView::WidgetPaintsBackground() lets us indicate that
we do not need an opaque backstop color to be added at the bottom of the display
list. This backstop color would interfere with vibrant -moz-appearance rendering
under the new vibrancy model.
WidgetPaintsBackground() is only called in one place, in ComputeBackstopColor():
```
nscolor PresShell::ComputeBackstopColor(nsView* aDisplayRoot) {
nsIWidget* widget = aDisplayRoot->GetWidget();
if (widget && (widget->GetTransparencyMode() != eTransparencyOpaque ||
widget->WidgetPaintsBackground())) {
// Within a transparent widget, so the backstop color must be
// totally transparent.
return NS_RGBA(0, 0, 0, 0);
}
// Within an opaque widget (or no widget at all), so the backstop
// color must be totally opaque. The user's default background
// as reported by the prescontext is guaranteed to be opaque.
return GetDefaultBackgroundColorToDraw();
}
```
On Windows 7, the widget returns eTransparencyBorderlessGlass from
GetTransparencyMode(), which also avoids the backstop color.
Differential Revision: https://phabricator.services.mozilla.com/D51458
--HG--
extra : moz-landing-system : lando
Drawing vibrancy fill colors was necessary in the past because we were erasing
the fill color that was drawn by the system, through our override of the
drawRect method of our NSVisualEffectView subclass.
However, starting with changeset be263e3d8bdfc0b6c072ffad2736999b9652d036
(from bug 1491445), we no longer override drawRect. Moreover, since the switch
to Core Animation, there is no way to clear the system's vibrancy fill drawing.
So we don't need to draw the vibrancy fill color any more. In fact, we should
stop drawing it, because now we're double-drawing it.
The fill color is very translucent so the double-drawing is not visually obvious.
Differential Revision: https://phabricator.services.mozilla.com/D51456
--HG--
extra : moz-landing-system : lando
Revert bug 1570581 by removing the AppleEvent entitlement from our hardened runtime configuration for both production and development.
Now that native messaging helpers are started 'disclaimed' with a new attribution chain, the entitlement is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D48029
--HG--
extra : moz-landing-system : lando
On macOS, launch native messaging helper apps with a new "Transparency, Consent, and Control" (TCC) attribution chain using the undocumented disclaim posix_spawn attribute.
Differential Revision: https://phabricator.services.mozilla.com/D48028
--HG--
extra : moz-landing-system : lando
Accept assertions to avoid intermittent test failures due to assertion count mismatches.
Differential Revision: https://phabricator.services.mozilla.com/D50660
--HG--
extra : moz-landing-system : lando
Changes:
- use regular strings instead of byte strings when matching
- encode files in UTF-8 prior to hashing
Depends on D51414
Differential Revision: https://phabricator.services.mozilla.com/D51728
--HG--
extra : moz-landing-system : lando
Changes:
- change `urlparse` import to `urllib.parse` to make switch over to python3
Depends on D51414
Differential Revision: https://phabricator.services.mozilla.com/D51648
--HG--
extra : moz-landing-system : lando
document.getAnonymousElementByAttribute is dead code now, and even when it wasn't this would
have returned null ever since <toolbarbutton> stopped using XBL.
Differential Revision: https://phabricator.services.mozilla.com/D51727
--HG--
extra : moz-landing-system : lando
Changes:
- update sections of `generate_sources_mozbuild.py` and `cmakeparser.py` to be python3 compatible
- change import of `urlparse` to be python3 compatible
Depends on D51414
Differential Revision: https://phabricator.services.mozilla.com/D51692
--HG--
extra : moz-landing-system : lando
This distinguishes better between the overloaded aspect of the PerFrameKey and the
actual mixed value.
Depends on D37803
Differential Revision: https://phabricator.services.mozilla.com/D37804
--HG--
extra : moz-landing-system : lando
This static method is assumed to have the same signature as the type's constructor,
and so we must have an implementation of ComputePerFrameKey for each constructor
a display item provides that is called by MakeDisplayItem. Notably this excludes
the MakeClone constructor for a lot of items.
There is a default varargs implementation on nsDisplayItem which everyone
inherits by default, so types which previously didn't overload this method
still don't need to.
Providing an implementation of ComputePerFrameKey on some display item type
shadows the varargs implementation, so one doesn't need to worry about overloading
one constructor but forgetting about another -- if you do, the compiler will only
see the overload and complain that the signature doesn't match.
One slightly annoying result of this is that display items which previously
inherited an overloaded implementation from a superclass now must provide
their own manual implementations. Although as far as I could tell, all of
those cases had a trivial implementation of key=0 (the super class supported
custom keys but the subclasses didn't make use of it).
In those cases I just hardcoded key=0, but it's possible that it would be
better to call into the superclass' implementation to be more robust to changes.
Differential Revision: https://phabricator.services.mozilla.com/D37803
--HG--
extra : moz-landing-system : lando
Replace the existing regex-based hack for recognizing reftest reference files
with a reliable method based on the reftest manifest.
Differential Revision: https://phabricator.services.mozilla.com/D51172
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsWebShellWindow is the only class that extends nsXULWindow and only
nsWebShellWindows are ever instantiated.
Differential Revision: https://phabricator.services.mozilla.com/D51155
--HG--
extra : moz-landing-system : lando
The help view copies strings from the main menubar. When we moved the original DTD string
to ftl, there were performance implications for using it in browser.xhtml, so it was
only added once needed. The help view copies attributes from the items in the main menubar's
help menu, and so didn't copy the label for this item, resulting in the broken
behaviour.
To fix this, it's enough to have the string in the markup. As we've moved the other strings
into menubar.ftl, I'm taking the opportunity to move this string there, too, next to its
sibling string to report deceptive sites.
Differential Revision: https://phabricator.services.mozilla.com/D51850
--HG--
extra : moz-landing-system : lando
Add test annotations to the ReftestManifest and TestResolver. For example, a
test description from the TestResolver might now contain 'skip-if': 'skiaContent';
similar to the content provided for manifestparser tests; this will allow
'mach test-info report' to filter tests based on reftest manifest test
annotations.
Also add the referenced-test field which identifies the test file associated
with test entries for reference files; this will allow test-verify to
run the correct reftest when only the reference file has been modified.
Differential Revision: https://phabricator.services.mozilla.com/D51113
--HG--
extra : moz-landing-system : lando
Andreas Pehrson
Brindusan Cristian
Ricky Stewart
alaskanemily
Dragana Damjanovic
Markus Stange
Haik Aftandilian
Geoff Brown
Erica Wright
Narcis Beleuzu
Edwin Takahashi
Nihanth Subramanya
Julian Descottes
Brian Grinstead
Jon Coppeard
Miko Mynttinen
Alexis Beingessner
Brendan Dahl
Gijs Kruitbosch
Gabriele Svelto
Junior Hsu
Cosmin Sabou
Simon Giesecke