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
These `bgcolor`s are the background colors of the new icons added in bug
1388379. I was originally intending to remove the bgcolor attribute in this
bug, which is why I didn't change the colors in the previous bug.
I decided not to remove the bgcolor attribute to avoid churn: we'd have to
maintain multiple permitted schemas for the region.properties (one where
bgcolor is required and one where it is not), update the documentation to
clarify the changes before and after Firefox 57, communicate the new format to
several partners, etc. It seemed easier to continue to require bgcolor and, if
there is transparency in the icon, we use bgcolor, otherwise we don't. This is
already the way distributions work: some icons have transparency, some don't!
In practice, the updated bgcolors on the suggested sites doesn't make a
difference: there is no transparency in the new icons so these bgcolors are
never shown.
MozReview-Commit-ID: GovUjM7VKyG
--HG--
extra : rebase_source : 11b4a710c1d81e701568c7d83ab6155cf4bc1229
As the H264 SanityTest uses a 132x132 videos to determine if the hardware decoder is working, we always use the software decoder for smaller videos.
MozReview-Commit-ID: 8VbZTiJO9mA
--HG--
extra : rebase_source : da34be08b67716ebb84f249ead571cc171d8d2f7
AMD incorrectly decode videos with a resolution that is less than 128x128, as such with the test failing we disable hardware decoding on those machines, even though other resolutions work well.
So we use a 132x132 video instead.
MozReview-Commit-ID: 80mk11CNsil
--HG--
extra : rebase_source : 2dce7281c45a942918e86fcaae98530e6b24275f
