HTMLEditor::GetCellIndexes() is an XPCOM method and used a lot internally.
So, we need alternative way to retrieve indexes of a cell without virtual
calls. In a lot of places, receiving indexes with 2 int32_t variables causes
the code messy and that causes making it harder to understand which are
index for same cell and where they come from. So, making both of them stored
one variable makes the callers simpler. Therefore, this patch creates
CellIndexes stack class to get and store the result simply. Then, this makes
all callers of GetCellIndexes() use this new class and makes GetCellIndexes()
also use this new class.
FYI: This patch does NOT put ErrorResult instances in small block scope as far as
possible. The reason is, I see its destructor in profile sometimes. I don't think
that we should use nsresult& instead of ErrorResult& only for this performance
reason, but I think that creating each instance in loops does not make sense.
Differential Revision: https://phabricator.services.mozilla.com/D3849
--HG--
extra : moz-landing-system : lando
This matches other implementations and the spec for fallback content like:
<canvas><div>abc
(calling div.innerText).
We're treating the <div> as 'rendered' because it's not in a display: none
subtree, but that's not ok, since it is in fact not rendered.
This was added in bug 1226293, and Boris suggested this change, but roc opposed
because it'd be hard to spec properly in comment 15. Looks like the HTML spec
ended up merging roc's innerText spec, and now it's spec'd in terms of 'being
rendered'.
I think IsOrHasAncestorWithDisplayNone just doesn't work in any reasonable way
for stuff out of the flat tree. Thus I think this change is the right thing.
The canvas test fails because of bug 1485076.
Differential Revision: https://phabricator.services.mozilla.com/D3887
--HG--
extra : moz-landing-system : lando
Nobody uses nsITableEditor.getNextRow(). Therefore, this patch removes this
XPCOM API.
Differential Revision: https://phabricator.services.mozilla.com/D3949
--HG--
extra : moz-landing-system : lando
nsITableEditor::GetNextRow() is an XPCOM method. Therefore, we should have
a non-virtual method for internal use of it.
This changes the definition in nsITableEditor. First, it allows only <tr>
element as what HTMLEditor::GetNextRow() has actually done. Then, changes
the return type to Element since it always returns an element node.
Differential Revision: https://phabricator.services.mozilla.com/D3948
--HG--
extra : moz-landing-system : lando
There are 2 bugs:
One is a simple mistake. kTest is each item of the tests, kTests is array of
all tests. When it needs to refer kTest.isAbsolutePosition, it referred
kTests.isAbsolutePosiiton. Therefore, the test always failed to enable
editing UI for absolute positioned element.
The other is, this test requires to disable inline-table-editing UI (which is
add or remove rows and columns). Note that even if the UI is disabled,
resizers is available for <table> elements.
Differential Revision: https://phabricator.services.mozilla.com/D3954
--HG--
extra : moz-landing-system : lando
Bug 1411879 introduced kPMDataFormatXMLCompress. However, this parameter caused
the saving print settings problem.
Before investigating this reason, this patch will revert this parameter.
Differential Revision: https://phabricator.services.mozilla.com/D3943
--HG--
extra : moz-landing-system : lando
In wpt, now we support "offset-path: none | path()", so parsing none or
path function should be correct. Animations which animate "from none"
or "to none" will pass because we could serialize "none", even if we
don't support animations on offset-path.
Depends on D2968
Differential Revision: https://phabricator.services.mozilla.com/D2969
--HG--
rename : testing/web-platform/tests/css/motion/offset-path-string.html => testing/web-platform/tests/css/motion/offset-path-string-001.html
rename : testing/web-platform/tests/css/motion/offset-path-string.html => testing/web-platform/tests/css/motion/offset-path-string-002.html
extra : moz-landing-system : lando
We implement the layout part of offset-path. Now we don't have
offset-distance, so use the default value, 0%, for it.
Note: rename mCombinedTransform as mIndividualTransform, which only
stores the combined individual transforms. We apply the individual
transforms, motion path transform, and specified transform in
ReadTransforms. (We have to follow the order, so we don't combine the
specified transform in FinishStyle.)
Depends on D2967
Differential Revision: https://phabricator.services.mozilla.com/D2968
--HG--
extra : moz-landing-system : lando
Implement one variant of BuildPath to accept nsTArray<StylePathCommand>,
which is used by <offset-path> (and clip-path in the future).
Depends on D3922
Differential Revision: https://phabricator.services.mozilla.com/D2967
--HG--
extra : moz-landing-system : lando
There are a lot of duplicates, so we use macro to refine them.
Depends on D2963
Differential Revision: https://phabricator.services.mozilla.com/D2966
--HG--
extra : moz-landing-system : lando
Define OffsetPath & SVGPathData on the servo-side, and StyleMotion &
StyleSVGPath on the gecko-side. We parse the SVG Path string into a
vector of PathCommand. To build the gfx::Path, we will convert it into
gfx::Path later in a different patch.
The basic flow is:
- Parse SVG Path String into SVGPathData (in Rust).
- Use cbindgen to make sure the layout of PathCommand and StylePathCommand, and then set the Box[PathCommand] into nsTArray<StylePathCommand>.
- Try to convert nsTArray<StylePathCommand> into gfx::Path. (This part will be implemented in a different patch.)
Finally, we use the gfx::Path to create a motion path transform.
The layout implementation is in the later patch.
Depends on D2962
Differential Revision: https://phabricator.services.mozilla.com/D2963
--HG--
extra : moz-landing-system : lando
Define the preference. I will enable it only for debug usage and test
coverage in a different patch.
Differential Revision: https://phabricator.services.mozilla.com/D2962
--HG--
extra : moz-landing-system : lando
I'm removing this no-longer-used feature because it promotes a behavior
(using the default 0 minimum) that means we never see reports of
unexpected passes when the bugs are fixed, and thus aren't protected
from the bugs regressing again.
Differential Revision: https://phabricator.services.mozilla.com/D3566
--HG--
extra : moz-landing-system : lando
nsITableEditor::GetFirstRow() is an XPCOM method, so, for internal use,
we should create non-virtual method, that is GetFirstTableRowElement().
This patch makes it never return NS_SUCCESS_EDITOR_ELEMENT_NOT_FOUND since
nobody refers it and it's detectable. If the method returns nullptr without
error, it's the case of NS_SUCCESS_EDITOR_ELEMENT_NOT_FOUND.
Additionally, this patch changes the return type of GetFirstRow() from
Node to Element since it always return an Element node if not null.
Differential Revision: https://phabricator.services.mozilla.com/D3780
--HG--
extra : moz-landing-system : lando
For some reason, clang 6 crashes with a stack overflow on PGO + LTO on
Linux 64 bits. Clang 7 doesn't, but has other problems.
After some bisecting, I found the following:
- r322684 is the first revision that is broken on the release_60 branch.
- that revision is a cherry pick of r322313 from trunk, which is
similarly broken.
- trunk was fixed by r322325, which, funnily enough, predates when
r322313 was cherry-picked.
While the change from r322325 is relatively large, mixing multiple
different changes in a single commit, there also haven't been
significant changes to the same file on trunk since (one macro name
change, one documentation change, and a change related to debug info),
which would tend to indicate the change is not going to break anything,
or at least not more than upgrading to clang 7 would.
The exact part that fixes the issue could probably be found in this
large commit, but I didn't feel like digging into it further considering
the above.
In order to support operator==() for tagged enum, we have to bump the version to
0.6.2.
Differential Revision: https://phabricator.services.mozilla.com/D3932
--HG--
extra : moz-landing-system : lando
This test appears to occasionally fail. The suspected cause is a combination of:
* timer clamping (due to vsync) resulting in the current timeline time after
resuming playback and the "ready time" being equal
* difference in floating-point precision used in calculating the two measures --
one calculation done in JS and one done using the UA's internal representation
of times.
Therefore this patch adds the standard tolerance for comparing time values to
this comparison.
Differential Revision: https://phabricator.services.mozilla.com/D3857
--HG--
extra : moz-landing-system : lando
Fix running robocop tests on debug builds.
This patch fixes multidex issues when running robocop on debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D3422
--HG--
extra : moz-landing-system : lando
This updates the Nightly DMG background to high resolution as given
by shorlander.
The image is passed through zopflipng as done in bug 1234008,
with metadata added back using exiftool as described in bug 1454610 comment 13.
Change is verified locally by re-packaging artifact build and inspecting
the resulting DMG.
Differential Revision: https://phabricator.services.mozilla.com/D3564
--HG--
extra : moz-landing-system : lando
Usually people don't mean to schedule code coverage tasks on try. But e.g |mach
try fuzzy -q "'mochitest"|, will cause them to be scheduled as a side effect.
This results in wasted resources and superfluous data in ActiveData.
This patch makes it so you need to explicitly pass --full to select ccov tasks
(even though they're technically part of the target task graph).
Differential Revision: https://phabricator.services.mozilla.com/D3917
--HG--
extra : moz-landing-system : lando
move wasm-misc and unity3d benchmarks to tier2; run wasm-misc in different preferences
Differential Revision: https://phabricator.services.mozilla.com/D3903
--HG--
extra : moz-landing-system : lando
