Any text enclosed between forward slashes is considered as a regex search. If the entered regex is invalid, a normal text search is performed.
Differential Revision: https://phabricator.services.mozilla.com/D26310
--HG--
extra : moz-landing-system : lando
(more a feedback request than review request at this stage)
Adding a new attribute to the panel was the easiest way I could find to make this work without too much plumbing
However I don't know how to check that the attribute comes from a chrome privileged script. I tried using PresContext()->IsChrome() but this is also false in our situation.
Would you prefer another approach? Otherwise what kind of test would you write for this kind of feature?
Differential Revision: https://phabricator.services.mozilla.com/D26211
--HG--
extra : moz-landing-system : lando
apilint 0.1.9 fixes a bug that was causing us to miss some annotation lints.
This commit fixes all of them before we can upgrade.
Depends On D26028
Differential Revision: https://phabricator.services.mozilla.com/D26029
--HG--
extra : moz-landing-system : lando
As we have successfully rolled out the feature via Normandy in 66, we should turn the feature on in >= 67 to not have to rely on Normandy going forward any more.
Differential Revision: https://phabricator.services.mozilla.com/D26713
--HG--
extra : moz-landing-system : lando
YouTube.com/tv uses YouTube specific extensions to MediaSource.isTypeSupported
in order to determine whether it serves 4K. It checks with bogus values, and if
we reject the bogus values, it assumes we're responding truthfully to the other
queries. So add support to reject the bogus values on YouTube.com.
With this patch, we can play 4K on YouTube.com/tv.
Differential Revision: https://phabricator.services.mozilla.com/D26655
--HG--
extra : moz-landing-system : lando
Bug 1500504 added a version check for the SDK, but it only does the
check if --with-macos-sdk is used. We should also check the version when
using the default SDK.
Note that this means we now set MACOS_SDK_DIR to be the default SDK even
if it wasn't set explicitly from --with-macos-sdk
Differential Revision: https://phabricator.services.mozilla.com/D17727
--HG--
extra : moz-landing-system : lando
This has some fun wins
- colored prompt
- multiline textarea
- default value for log points
Differential Revision: https://phabricator.services.mozilla.com/D26585
--HG--
extra : moz-landing-system : lando
Since it wasn't reliable, we remove the topWindowPrincipal in favor of WindowGlobalParent->DocumentPrincipal()
Differential Revision: https://phabricator.services.mozilla.com/D24897
--HG--
extra : moz-landing-system : lando
The principal we got from the child process was always a null principal, which was wrong.
This approach seems to give you the actual principal of the current document.
Differential Revision: https://phabricator.services.mozilla.com/D24895
--HG--
extra : moz-landing-system : lando
ClientTiledPaintedLayer::GetTransformToAncestorsParentLayer calculates
the transform from the layer to its display port ancestor's
parent. This transform is then applied to the calculated display
port.
However, if the display port ancestor participates in a preserve-3d
context then the scroll offset will not be included in the that
layer's transform, it will instead be on the root layer of the
preserve-3d context. This was causing the critical display port to
remain still as the contents of a perspective transform were scrolled,
resulting in content being permanently painted in low-precision as the
page was scrolled down.
Instead, if the display port ancestor participates in a 3d context, we
must find the root of that 3d context then calculate the transform to
*that* layer's parent.
Differential Revision: https://phabricator.services.mozilla.com/D26821
--HG--
extra : moz-landing-system : lando
Interestingly, the change makes one configure test have a different
result (localeconv ends up being found when it used not to be found),
but the result of that check is actually not used on Windows because we
set HAVE_LOCALECONV manually.
Differential Revision: https://phabricator.services.mozilla.com/D25902
--HG--
extra : moz-landing-system : lando
Because not all static components are using the static registration yet,
we can end up in situations where a same component is registered
multiple times, which can have some unexpected consequences.
Interestingly enough, this change revealed that we did have static
registration in place for components that were kept under the old system
after bug 1478124 and bug 1524687.
There are also possibly some non-obvious things that can happen while
migrating the remaining components, like what happened to me while I
worked on @mozilla.org/widget/components;1 (see bug 1542214 comment 0).
Differential Revision: https://phabricator.services.mozilla.com/D26698
--HG--
extra : moz-landing-system : lando
Bug 1478124 and bug 1524687 converted many things to static xpcom
component registration, but somehow left the corresponding C++
initialization.
Differential Revision: https://phabricator.services.mozilla.com/D26697
--HG--
extra : moz-landing-system : lando
Cmd-line params for the SharedPreferenceSerializer was
duplicated in ContentParent and
SocketProcessHost. Since we'll have a 3rd process (RDD)
using this same code, let's move the repsonsiblity for knowing how to add
these cmdline params into SharedPreferenceSerializer.
Depends on D26567
Differential Revision: https://phabricator.services.mozilla.com/D26568
--HG--
extra : moz-landing-system : lando
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
If there are a large number of untracked files in the working directory, hg
will attempt to print them all out with the default pager. This does not
interact very will with commands that are built atop this functionality. We
set HGPLAIN=1 so that the underlying hg will not attempt to use a pager.
Differential Revision: https://phabricator.services.mozilla.com/D26607
--HG--
extra : moz-landing-system : lando
