The only three types that can hit the PreservedWrapper() assertion
currently, and which this patch avoids, are DOMSVGPathSegList,
DOMSVGPointList, and DOMSVGStringList.
This is because these are the only types that are implemented as proxies
(due to having e.g. indexed getters on them, and thus have the offending
DOMProxyHandler::GetExpandoObject() call in their bindings) and which we
store in tearoff tables.
Differential Revision: https://phabricator.services.mozilla.com/D70314
--HG--
extra : moz-landing-system : lando
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
Callers should pass in UTF-8, since that's what the JS engine ends up with in the end anyway.
The various URL changes are because NS_NewURI converts incoming nsAString to
UTF-8 anyway. So we might as well do that up-front and then use the UTF-8
string for both the NS_NewURI call and the error-reporting if it fails.
Differential Revision: https://phabricator.services.mozilla.com/D65543
--HG--
extra : moz-landing-system : lando
WebRender expects drop shadow dx/dy to be in user space, which is a floating point value.
Before this, a dx/dy such as (0.2, 0.2) was truncated to (0, 0) resulting in no offset of the shadow.
Differential Revision: https://phabricator.services.mozilla.com/D63442
--HG--
extra : moz-landing-system : lando
WebRender expects drop shadow dx/dy to be in user space, which is a floating point value.
Before this, a dx/dy such as (0.2, 0.2) was truncated to (0, 0) resulting in no offset of the shadow.
Differential Revision: https://phabricator.services.mozilla.com/D63442
--HG--
extra : moz-landing-system : lando
The optimization here was trying to avoid reconstructing in some cases when we
started animating a transform. Unfortunately it wasn't handling the transform
animations properly, which means that once it decided that _adding_ the
transform value needed a reconstruction, it was deciding that _changing_ it also
needed.
Which means that we reconstructed the frames once per animation frame, which is
pretty sad.
While fixing the optimization, also use a more comprehensive change hint, the
one that we use for transform property changes as well.
Differential Revision: https://phabricator.services.mozilla.com/D63803
--HG--
extra : moz-landing-system : lando
If we reconstruct frames due to some other reason, we will never get to the
DidSetComputedStyle bit that would clear it for us on change.
This is all in all very unfortunate, since I think the fact that we reconstruct
frames so aggressively is a bug anyway (this comes from this bit in
SVGAnimatedTransformList):
https://searchfox.org/mozilla-central/rev/a37fc61f172b432e7ae0b6b4c4a12cac2a787a0f/dom/svg/SVGAnimatedTransformList.h#108
I think we are supposed to reconstruct only once at most, but I may be crazy :^)
Will look at that in a separate bug though, this is the most minimal change that
addresses the regression.
An alternative (equally low-risk) would be to clear cached paths also in the
case where there's no old computed style in nsSVGGeometryFrame...
Differential Revision: https://phabricator.services.mozilla.com/D63802
--HG--
extra : moz-landing-system : lando
We don't need to transfer all properties after adopt. Collecting all the nodes
with properties during adopt was needed because there used to be clone and adopt
user-data callbacks, see https://bugzilla.mozilla.org/show_bug.cgi?id=347524.
This ensures that NodeInfoChanged and similar callbacks can tweak node
properties, which is needed for bug 1542784.
Also simplify surrounding code. As far as I can tell we should always have
different documents if we get a NodeInfoManager object.
Differential Revision: https://phabricator.services.mozilla.com/D62439
--HG--
extra : moz-landing-system : lando
nsPresContext.h is only used for unit conversion, which can be done by Units.h
in a similar fashion.
PresShell.h was needed for some capturing-content stuff which can be moved out
of line.
Differential Revision: https://phabricator.services.mozilla.com/D62170
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
Now mfbt/Move.h is empty except for that excellent comment about move
semantics... Should we put it somewhere else and delete the header as a
follow-up? Or just delete the header and carry on?
Differential Revision: https://phabricator.services.mozilla.com/D60297
--HG--
extra : moz-landing-system : lando
It turns into a DOMException named 'TypeError' in the bindings, not into an actual TypeError.
Differential Revision: https://phabricator.services.mozilla.com/D60215
--HG--
extra : moz-landing-system : lando
It removes a script blocker. Therefore, although it depends on the caller
whether it causes running script or not. However, we should mark it as
`MOZ_CAN_RUN_SCRIPT` for safer code.
It's called only by the destructor of `nsAutoCauseReflowNotifier`. Therefore,
this patch also marks its constructor as `MOZ_CAN_RUN_SCRIPT` for making
each creator method marked as `MOZ_CAN_RUN_SCRIPT` or
`MOZ_CAN_RUN_SCRIPT_BOUNDARY`.
Most of the creators is mutation listener methods. However, `PresShell`
does nothing after destroying `nsAutoCauseReflowNotifier`. Therefore,
this patch does not change the callers in MutationObserver.cpp to use
`RefPtr<PresShell>` at calling them because changing it may cause performance
regression.
Perhaps, we should create another methods of `WillCauseReflow()` and
`DidCauseReflow()` to avoid unnecessary `MOZ_CAN_RUN_SCRIPT` marking.
However, I'm not sure whether most callers may run script or not because
of outside of my knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D55805
--HG--
extra : moz-landing-system : lando
So that it takes one pointer instead of two, and doesn't make nsStylePosition's
size blow up.
This is not as ugly as I was fearing, thankfully, though it requires a bit of
boilerplate. I think it's acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D58702
--HG--
extra : moz-landing-system : lando
This is needed to support min() / max() / clamp(), etc, as those need to be a
tree of values and thus need heap storage.
This unfortunately grows LengthPercentage to be two pointers, which is bad as
it blows up the size of nsStylePosition enough to trigger the size assertions.
This patch comments out the assertion for now, the follow-up patches will
uncomment them.
Differential Revision: https://phabricator.services.mozilla.com/D58700
--HG--
extra : moz-landing-system : lando
Now that we have UTF8String in the WebIDL, we can remove quite a few of the
conversions. Do that, and lift the remaining string conversions up as needed.
Also deindent Servo_ComputeColor while touching it.
Most of the remaining copies are because either bug 1606994, or because they're
WebIDL attributes that we still need to serialize back as UTF-16 (bug 1606995).
Differential Revision: https://phabricator.services.mozilla.com/D58687
--HG--
extra : moz-landing-system : lando
Using JSON.stringify in dom/tests/mochitest/chrome/test_clonewrapper.xhtml might not be the best solution, because
the testObject contains ImageData objects.
Differential Revision: https://phabricator.services.mozilla.com/D58645
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando