I replaced the values with -moz-inline-box in the crashtests
rather than removing them. I think they are still valuable
after replacing the display value.
Differential Revision: https://phabricator.services.mozilla.com/D42551
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 941298157e7c82f420cf50ce057154ce9b85301c
extra : source : 189dc8a359815e059a4a217f788d183260bb2bfe
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
Changes:
- added comments for tests being disabled
- disabled two additional tests in order to green the run
Differential Revision: https://phabricator.services.mozilla.com/D28085
--HG--
extra : moz-landing-system : lando
Changes:
- most tests are skipped using `moz.build` configuration file.
- `MultiWriterQueue` had to be skipped with `define` clauses in the test file due to build bustages when its `moz.build` file was used.
Differential Revision: https://phabricator.services.mozilla.com/D27944
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
Several tests in marionette are failing in `Mn`, `MnH`, `MG` for windows10-aarch64.
This patch disables the tests that are failing.
Individual issues are recorded in:
- 1536278
- 1536369
Differential Revision: https://phabricator.services.mozilla.com/D23991
--HG--
extra : moz-landing-system : lando
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/layers/composite/ContainerLayerComposite.cpp:132:6 [-Wmissing-prototypes] no previous prototype for function 'TransformLayerGeometry'
gfx/layers/composite/LayerManagerComposite.cpp:1409:6 [-Wmissing-prototypes] no previous prototype for function 'ComputeVisibleRegionForChildren'
gfx/layers/composite/LayerManagerComposite.cpp:234:6 [-Wmissing-prototypes] no previous prototype for function 'ShouldProcessLayer'
gfx/layers/composite/TiledContentHost.cpp:156:6 [-Wmissing-prototypes] no previous prototype for function 'UseTileTexture'
gfx/layers/ipc/CompositorBridgeParent.cpp:1827:6 [-Wmissing-prototypes] no previous prototype for function 'EraseLayerState'
gfx/layers/ipc/CompositorBridgeParent.cpp:2140:6 [-Wmissing-prototypes] no previous prototype for function 'UpdateIndirectTree'
gfx/layers/opengl/OGLShaderProgram.cpp:28:6 [-Wmissing-prototypes] no previous prototype for function 'AddUniforms'
Differential Revision: https://phabricator.services.mozilla.com/D20265
--HG--
extra : source : f5653a8b1bc5a02cf899fe87cb3ebc9796b0b0b1
extra : histedit_source : 4f44f15098c42b4b1fa141de7b8593c128b58596
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/layers/Layers.cpp:58:7 [-Wmissing-prototypes] no previous prototype for function 'FILEOrDefault'
gfx/layers/ipc/CompositorThread.cpp:26:25 [-Wmissing-prototypes] no previous prototype for function 'GetCompositorThreadHolder'
MINIMUM_TILE_COPY_AREA()
Differential Revision: https://phabricator.services.mozilla.com/D20266
--HG--
extra : rebase_source : 5c80a140cbd661644e2076a8852a0cfe58539083
extra : source : 7f44c2bcebce0b4bd549d653e4eff8b4bad71e29
The Google weather search result widget has an SVG inside a transform,
inside a scrollframe. The patch in bug 1523776 broke the clipping in
that the SVG elements would not get clipped by the scrollframe. This
reftest exercises that scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18273
WhatsApp Web has emojis in divs with border-radius, inside a transform,
inside a scrollframe. The patch in bug 1523776 broke the clipping in
that scrolling the scrollframe would make the emoji visible outside the
scrollframe. This reftest replicates that scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18272
The Google weather search result widget has an SVG inside a transform,
inside a scrollframe. The patch in bug 1523776 broke the clipping in
that the SVG elements would not get clipped by the scrollframe. This
reftest exercises that scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18273
WhatsApp Web has emojis in divs with border-radius, inside a transform,
inside a scrollframe. The patch in bug 1523776 broke the clipping in
that scrolling the scrollframe would make the emoji visible outside the
scrollframe. This reftest replicates that scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18272
It turns out that setting the parent link on a clip chain is no longer
needed (and probably hasn't been since WR started applying a stacking
context's clip to the SC's contents). In fact it can produce incorrect
behaviour in some cases, because it doesn't match the semantics of
Gecko's clip chains. This removes the parent link on the Gecko side and
adds a test for this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D18101
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
In nsDisplayTransform::CreateWebRenderCommands we should be rounding the
translation from the reference frame if there is no other transformation
to better match non-WebRender which performs similar rounding in
ChooseScaleAndSetTransform.
Differential Revision: https://phabricator.services.mozilla.com/D14265
When scroll frames are created, and no explicit parent is provided,
the old code used to take the ClipID from the c/s stack. The stack
has been removed on WR side, and this parent assignment got lost.
This change takes the SpatialID from the top of the stack on Gecko
side to replicate the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D16732
--HG--
extra : moz-landing-system : lando
When scroll frames are created, and no explicit parent is provided,
the old code used to take the ClipID from the c/s stack. The stack
has been removed on WR side, and this parent assignment got lost.
This change takes the SpatialID from the top of the stack on Gecko
side to replicate the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D16732
--HG--
extra : moz-landing-system : lando
re-open of D16335, which got backed out due to Wrench test failing.
The test was failing because of different AA on a plane-splitting case, which isn't guaranteed anyway.
This revision updates the test.
Differential Revision: https://phabricator.services.mozilla.com/D16560
--HG--
extra : moz-landing-system : lando
