For the serialization of specified values of calc(), we should keep the
units of absolute lengths, so use AbsoluteLength.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix [Bug 1396692](https://bugzilla.mozilla.org/show_bug.cgi?id=1396692).
- [X] These changes do not require tests because we have wpt tests for this already.
Source-Repo: https://github.com/servo/servo
Source-Revision: c8bc6ca4204ff521c35ba09bfdd6921e53801bc0
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : b7457e060f95f43ce85af9618c3daf64db32a259
Running individual random tests might still be useful for finding crashes or assertion failures, but there is no need to run the styloVsGecko visual comparison tests if the results are random.
MozReview-Commit-ID: Brz6zf25lCO
--HG--
extra : rebase_source : 74b453e952da2710f069afc6b8d8017a4ec021dd
extra : source : 95dc8a8a752d1a1ac05e026115aff319fc27e772
Skip tests that are expected to fail in both Stylo and Gecko modes. They would unexpectedly "pass" in styloVsGecko mode when comparing the two failures, which is not a useful result.
MozReview-Commit-ID: 3mOpjU225Q1
--HG--
extra : rebase_source : 22bb5d4e3c5138ef832995eaf5716824f4707ffe
extra : source : d40fb20c9a49d0797c0eeae613a04912b12a28f7
I don't want to call BitmapUtils.getBitmapFromDrawable() here for AdaptiveIconDrawable cause there might be performance impact if I create bitmap in main thread.
I'll use bug 1397174 to follow up this issue.
MozReview-Commit-ID: 64FE2MOk5g0
--HG--
extra : rebase_source : 041e0a5f9d7b4245650f5a229603818b11631b4e
This API is for use by mozJSComponentLoader to load JSMs into a
NonSyntacticVariablesObject with a shared global.
MozReview-Commit-ID: LtGdY4ULy45
--HG--
extra : rebase_source : 8d71718b567d7a00c4bfc4514ed342b9ab56c7b0
Currently, IMEStateManager::OnChangeFocusInternal() tries to sync the state
whether menu keyboard listener is installed between itself and active remote
process -- When menu keyboard listener is installed, it posts a message to
_only_ active remote process. When menu keyboard listener is uninstalled,
it posts a message to _only_ active remote process. So, it's not guaranteed
that active remote process at installing and uninstalling may be different.
If it's different, IMEStateManager in the old remote process believes that
menu keyboard listener is still installed. This is what the cause of IME
unavailable in a remote process.
Current approach must be wrong. IMEStateManager should manage menu keyboard
listener state only in the process which the listener is installed in. Then,
when menu keyboard listener is uninstalled, IMEStateManager needs to restore
the latest input context in the remote process without asking the remote
process.
Therefore, this patch does:
* stops IMEStateManager::OnChangeFocusInternal() posting message when menu
keyboard listener is installed and uninstalled.
* removes the message sender and receiver from PBrowser.
* cache the latest input context of active remote process in
IMEStateManager::SetInputContextForChildProcess().
* make IMEStateManager::SetInputContextForChildProcess() not set input context
when menu keyboard listener is installed in the process.
* tries to restore latest input context in the remote process in
IMEStateManager::OnChangeFocusInternal(). If there is no cached input
context, it does nothing and waits next SetInputContextForChildProcess() call.
* clears the cache when IMEStateManager::OnChangeFocusInternal() changes
active remote process to different one or nullptr.
So, this must improve performance at activating and inactivating memubar and
opening and closing popup menu in the main process.
MozReview-Commit-ID: EelKSPlaXdw
--HG--
extra : rebase_source : db7334b3c0d3ce87868450ee3179692027975bd6
We currently vary the cache name for run-task tasks whenever run-task
changes. This allows us to not worry about backwards or forwards
compatibility of caches in run-task tasks.
This strategy doesn't work for out-of-tree Docker images because
the content of run-task cannot be determined at Taskgraph time:
the content of run-task was determined when that Docker image was
built and there is no way to get that content efficiently during
Taskgraph.
So, for out-of-tree Docker images we now vary the cache name by
the Docker image value, which includes its name and a tag or
hash. This means that out-of-tree run-task tasks will get separate
caches for each distinct Docker image.
This isn't ideal. Ideally we would share caches if run-task doesn't
vary between Docker images. But without any way of proving that
at Taskgraph time, we take the safe road and force cache separation.
MozReview-Commit-ID: FMiQBqfvjqW
--HG--
extra : rebase_source : b2763625a3a69e0cf11b6d648a6fcca379234f02
The image_builder Docker image doesn't set a "command" in its task
definition. The image instead relies on a RUN in its Dockerfile to
control the started command. This command is a shell script which
eventually runs run-task.
This all means that image_builder tasks are executing run-task but
the cache sanitization implemented in bug 1391476 isn't getting
applied to those tasks. This means run-task could barf due to
constraint violations due to improperly configured caches.
The fix for this is to teach the generic task transform that
image_builder tasks use run-task. The effect of this is that
some environment variables get set and the cache name changes
depending on the contents of run-task.
MozReview-Commit-ID: IFqsDxD0eDh
--HG--
extra : rebase_source : 280983eae7d6a44dfd70f0da8ce325e90e9555c4
I'm not sure exactly how this works, but test_smilTextZoom.xhtml passes so this
appears to be taken care of.
MozReview-Commit-ID: C04XjX2rtZw
--HG--
extra : rebase_source : 19c08a1267f8764f83e9e7b31731bb82e52df9e6
This shows how the coordinates were actually calculated. and will make it easier should the video size needs to ever be changed again.
MozReview-Commit-ID: KkQNqz00Aw0
--HG--
extra : rebase_source : fb1074a28f2045c3889acc43fbe9c01dadc34a70
We now check that the canvas is properly scaled by checking if the color immediately on the right of the canvas is correct.
If the rendering failed, we do not bother testing the H264 video decoder.
MozReview-Commit-ID: IwBwKnceLBg
--HG--
extra : rebase_source : bf0b881a23c2225dcebb13d79d5034c89a0a31e1
This ensure that the window still has the intended size if it had been resized due to different DPI setup.
MozReview-Commit-ID: 9oeXbTKQqhe
--HG--
extra : rebase_source : cfe3a9d5faa4a4dadd766cf1d3751b61bde929f1
When CompositorBridgeChild::Destroy is called from ShutDown, it will
only call AfterDestroy if it has not been previously destroyed, and if
ActorDestroy has not been called by the IPDL code. AfterDestroy is
always necessary to allow ShutDown to return because it is what clears
the static reference used as a event loop spinning condition in
ShutDown. Now, AfterDestroy is safe to call multiple times, and even
if ActorDestroy was already called, we will try it from Destroy before
returning early.
Boris Chiou
Chris Peterson
Xidorn Quan
Nevin Chen
Karl Tomlinson
Ted Campbell
Jared Wein
Masayuki Nakano
Glenn Watson
ahillier
Daosheng Mu
Drew Willcoxon
Mark Hammond
Julian Descottes
Gregory Szorc
Wes Kocher
Christian Holler
Brian Birtles
Anthony Ramine
Andrew Swan
Matt Howell
Ed Lee
Sebastian Hengst
Jean-Yves Avenard
ffxbld
Bas Schouten
Ehsan Akhgari
Joel Maher
Geoff Brown
Ryan VanderMeulen
Andrew Osmond