cs -> 0d96b6b04bfb8a29ba7040144db80cc47f64b09d
es-AR -> 01299d3f3403fe192552ec997322a0c9dc00bfca
ia -> b8ce45c9cc30ffd2839f6f566c3322fda1579fc7
is -> 5c4b61165e1dbb5bb5c053bc88056520abc985d4
kk -> a11c5e344b725fb501870f9ca6e04be5c77ed3d4
vi -> 0e75c226763d2548044afe1d0f7b2b3158b7c56d
EnsureTarget() is called in many places in the code without checking the result, so
in error cases, like processing path builder commands, it can lead to EnsureTarget()
generating an error to the log on every single invocation, with some users noticing
thousands upon thousands of errors being generated.
One notice of this error should be sufficient, given that this is a shutdown error.
Differential Revision: https://phabricator.services.mozilla.com/D197440
They are triggered via cron, so an empty run-on-projects should be the
appropriate config.
As they are not idempotent (they will pick the last from upstream on
each run), they also shouldn't be cached.
Differential Revision: https://phabricator.services.mozilla.com/D197303
The system environment under which the snaps are built doesn't always
match the tree that is built. When the versions of system python
packages doesn't match what is in the tree (like when upgrading
zstandard in the docker image, and building an older tree that wants
an older version), we get in a troublesome situation.
So just rely on the mach virtualenv.
Differential Revision: https://phabricator.services.mozilla.com/D197407
This comes from the windows version of toolbarbutton.css from before
bug 1861020, which had:
```
toolbarbutton:where([disabled="true"]) {
color: GrayText;
text-shadow: none;
}
@media not (prefers-contrast) {
:root[lwtheme-image] toolbarbutton {
text-shadow: none;
}
}
:root[lwtheme-image] toolbarbutton:not([disabled="true"]) {
text-shadow: inherit;
}
```
Which didn't make a lot of sense, but made the media-query block
basically useless.
It seems I noticed that:
:root[lwtheme-image] toolbarbutton:not([disabled="true"])
Was useless because of the disabled rule, but I didn't notice that that
would make the media block unexpectedly apply.
Differential Revision: https://phabricator.services.mozilla.com/D197418
It looks like this was an oversight in bug 1155059, that in one place an
already_AddRefed does not get converted to a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D197374
The macOS menupopup corner radius was recently changed from 4px to 8px, but that does not quite match the system, which measures at 6px.
Differential Revision: https://phabricator.services.mozilla.com/D197408
This includes the `Avoid setTimeout in waitOnElement` change. I'd like to land that
separately from ComplexDOM change so we separate out the effect of each change.
Differential Revision: https://phabricator.services.mozilla.com/D197381
This is intended for Searchfox, to analyse and display the bindings
between Java and C++ code.
When the @WrapForJNI annotation is set on a method marked as native,
the code generator creates 3 files, for instance for EventDispatcher:
* GeneratedJNIEventDispatcherWrappers.cpp
* GeneratedJNI/EventDispatcherWrappers.h
* GeneratedJNI/EventDispatcherNatives.h
The class that implements the member function bound from Java inherits
from EventDispatcher::Natives. That member function is defined in yet
another implementation file.
The mozsearch clang plugin only sees one single translation unit at a
time, so when it sees the definition of the actual bound method (and
when it emits the related data), it doesn't see the EventDispatcher
wrappers implementation anymore. At the moment it misses the name of
the wrapped Java class qualified class name.
This moves the name initialization from the wrappers impl file to the
header so that the mozsearch clang plugin can see the whole picture at
once when analysing the actual member functions' implementations.
The Java class members names were already initialized in the header so
this also makes things a bit more consistent in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D196795
While the assert is well-intentioned, it is mostly just causing more problems
than it solves. Due to the nature of shutdown, are in a partially shutdown state
where sCanvasRenderThread goes away, even though the CanvasRender thread still
exists and is processing the last events in the queue. Because of this, the assert
fails, even though we are actually on the correct thread. It seems reasonable here
to just remove the assert in FinishShutdown, since ActorDestroy already verifies
we are on the correct thread.
Depends on D197374
Differential Revision: https://phabricator.services.mozilla.com/D197375
This was a change for bug 1872087 that somehow got lost when I was rebasing. The idea
here is that DrawTargetWebgls use a single shared WebGL context, so it makes sense for
them to share recycle texture data, much like CanvasTranslator shares recycling of
texture data for D2D. This should increase the efficiency of use-cases that create and
destroy a lot of canvases every frame and would not normally benefit from recycling.
Depends on D197375
Differential Revision: https://phabricator.services.mozilla.com/D197376
Ideally, we wouldn't rely on tooltool, but until we can have private
fetches that can actually be used forever without having to be
retriggered for CoT or other reasons, tooltool is the best we have.
Differential Revision: https://phabricator.services.mozilla.com/D197305
-moz-user-focus: none didn't do anything useful for non-XUL until
bug 1868552. It seems nonetheless some sites specify it, which can cause
compat issues.
Let's hide this property from content, to avoid breaking those sites.
Differential Revision: https://phabricator.services.mozilla.com/D197253
This was a change for bug 1872087 that somehow got lost when I was rebasing. The idea
here is that DrawTargetWebgls use a single shared WebGL context, so it makes sense for
them to share recycle texture data, much like CanvasTranslator shares recycling of
texture data for D2D. This should increase the efficiency of use-cases that create and
destroy a lot of canvases every frame and would not normally benefit from recycling.
Depends on D197375
Differential Revision: https://phabricator.services.mozilla.com/D197376
While the assert is well-intentioned, it is mostly just causing more problems
than it solves. Due to the nature of shutdown, are in a partially shutdown state
where sCanvasRenderThread goes away, even though the CanvasRender thread still
exists and is processing the last events in the queue. Because of this, the assert
fails, even though we are actually on the correct thread. It seems reasonable here
to just remove the assert in FinishShutdown, since ActorDestroy already verifies
we are on the correct thread.
Depends on D197374
Differential Revision: https://phabricator.services.mozilla.com/D197375
Vinny Diehl
Mozilla Releng Treescript
Lee Salzman
Timothy Nikkel
Tooru Fujisawa
Kate Galich
Perry McManis
Kelly Cochrane
Mike Hommey
Emilio Cobos Álvarez
Chun-Min Chang
Cathie Chen
Noemi Erli
Sam Johnson
Jeff Muizelaar
James Teow
Stephanie Cunnane
Nicolas Guichard
Nicholas Rishel
Norisz Fay