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.
This adds a browserSetting.imageAnimationBehavior API which accepts one of three
values: "normal", "none", "once". Behind the scenes it sets the image.animation_mode
preference to the same value.
MozReview-Commit-ID: GLT6oJgpF3
--HG--
extra : rebase_source : e1675bf4042e7e5fcee768231ffeccf19dc77c69
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#18109
- [X] There are tests for these changes. I enabled the peformance-timeline API WPTs but some of them are still failing because of implementation bugs or missing APIs (Resource Timing, for instance) the tests are dependent of. I'll file issues to fix them.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1e93749941d2e3569c7c907832658c57ffb18c72
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4344c6a1c60484c840cbd3be4112d0c3a710b523