Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
We have a better type to represent "a coord or nothing", and that's Maybe.
This code is shorter, and I think reads generally better / is less easy to
misuse.
I wrote this on top of bug 1547126 so there shouldn't be conflicts.
Differential Revision: https://phabricator.services.mozilla.com/D28921
--HG--
extra : moz-landing-system : lando
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
nsSVGUtils::PaintFrameWithEffects needs to pass its transform to
nsCSSClipPathInstance::ApplyBasicShapeOrPathClip so that the latter
can compute the correct box.
Differential Revision: https://phabricator.services.mozilla.com/D28655
--HG--
extra : moz-landing-system : lando
<clipPath> can itself have SVG transform, thus we need to override
nsIFrame::IsSVGTransformed() method so that layout code will be aware
of the SVG transform.
The remaining is similar to <mask>
Differential Revision: https://phabricator.services.mozilla.com/D28272
--HG--
extra : moz-landing-system : lando
We should not treat <iframe> as <object> for SVG, otherwise there will
be unexpected sizing and other webcompat problem (e.g. getScreenCTM).
It behaved correctly before, the change was introduced to solve a double
zooming problem (bug 843480) for <iframe>. Actually the zooming problem
can be solved by avoiding zooming when the window frame is an <iframe>.
Differential Revision: https://phabricator.services.mozilla.com/D28313
--HG--
extra : moz-landing-system : lando
We remove initial x/y offset for nsSVGUtils::GetTransformMatrixInUserSpace
so that it can be used in not-nondisplay context. Previously it was only
used in nondisplay context, where x/y offset is always 0.
Then we use this utility to get the transform matrix to judge whether we need
special care for non-scaling-stroke. The old matrix doesn't account for CSS
transform.
Differential Revision: https://phabricator.services.mozilla.com/D28193
--HG--
extra : moz-landing-system : lando
SVGElement::PrependLocalTransformsTo doesn't take CSS transform into
account, we should use nsIFrame::GetTransformMatrix instead.
Differential Revision: https://phabricator.services.mozilla.com/D27659
--HG--
extra : moz-landing-system : lando
Also move to first cache-line (64-bytes) of nsDisplayItem to improve D-cache hit
when accessing mFrame, mItemFlags, etc.
Differential Revision: https://phabricator.services.mozilla.com/D26134
--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
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--HG--
extra : moz-landing-system : lando
Also move to first cache-line (64-bytes) of nsDisplayItem to improve D-cache hit
when accessing mFrame, mItemFlags, etc.
Differential Revision: https://phabricator.services.mozilla.com/D26134
--HG--
extra : moz-landing-system : lando
We already get the user space metrics, mFontSizeScaleFactor is irrelevant
and the scaling should not be applied in the first place.
Otherwise we will get very wrong bounding box when <text> has SVG transform
or the font has extreme size.
Differential Revision: https://phabricator.services.mozilla.com/D27443
--HG--
extra : moz-landing-system : lando
So, this patch makes all caller of it safe including its arguments unless
they come from other methods.
Differential Revision: https://phabricator.services.mozilla.com/D27225
--HG--
extra : moz-landing-system : lando
nsSVGUtils::GetUserToCanvasTM becomes dead code and no longer useful,
since it doesn't take CSS transform into account. Let's remove it.
Differential Revision: https://phabricator.services.mozilla.com/D26514
--HG--
extra : moz-landing-system : lando
We should use nsLayoutUtils::GetTransformToAncestor instead of
nsSVGUtils::GetUserToCanvasTM to get the transform matrix. Because the former
will also take CSS transform into account while the latter won't.
Differential Revision: https://phabricator.services.mozilla.com/D26441
--HG--
extra : moz-landing-system : lando
We should use nsLayoutUtils::GetTransformToAncestor instead of
nsSVGUtils::GetUserToCanvasTM to get the transform matrix. Because the former
will also take CSS transform into account while the latter won't.
Differential Revision: https://phabricator.services.mozilla.com/D26441
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
I think I found another mistake in the SVG text code that could explain the regression: If the text is drawn with a stroke, shouldn't the stroke be included in the bounding box?
Differential Revision: https://phabricator.services.mozilla.com/D26074
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
If the maximal and minimal font-size in a SVGTextFrame have a huge difference,
previously we chose mFontSizeScaleFactor to satisfy the minimal one. That's
problematic, because the maximal one might be a reasonable size, while the minimal
one is extremely small. We should honor the maximal one if this is the case.
Differential Revision: https://phabricator.services.mozilla.com/D24494
--HG--
extra : moz-landing-system : lando
When <switch> happens to have an active child that is non-display, we should still reflow all its descendant SVGTextFrame for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D25699
--HG--
extra : moz-landing-system : lando
If the maximal and minimal font-size in a SVGTextFrame have a huge difference,
previously we chose mFontSizeScaleFactor to satisfy the minimal one. That's
problematic, because the maximal one might be a reasonable size, while the minimal
one is extremely small. We should honor the maximal one if this is the case.
Differential Revision: https://phabricator.services.mozilla.com/D24494
--HG--
extra : moz-landing-system : lando
