We can end up in here from a style worker thread. But that's safe since
we only read data from the FontFaceSet, and the main thread is blocked
so writes can't happen underneath us.
Differential Revision: https://phabricator.services.mozilla.com/D44589
--HG--
extra : moz-landing-system : lando
To prevent these tests depending on Bug 1102175 to pass because they
specify "direction" or "writing-mode" on <body>, replace <body> with
<main>. This patch doesn't change the meaning of the tests.
Except for shape-outside-margin-box-border-radius-008.html, which is
modified manually, all the other files are modified by the follow Python
3 script.
```
import fileinput
import glob
open_tag_before = '<body class="container">'
open_tag_after = '<main class="container">'
end_tag_before = '</body>'
end_tag_after = '</main>'
match_files = 'layout/reftests/w3c-css/submitted/shapes1/*.html'
with fileinput.FileInput(glob.glob(match_files), inplace=True) as f:
found_open_tag = False
for line in f:
if not found_open_tag:
line_open_tag = line.replace(open_tag_before, open_tag_after)
if line_open_tag != line:
print(line_open_tag, end='')
found_open_tag = True
else:
print(line, end='')
else:
# Continue search for end tag
line_end_tag = line.replace(end_tag_before, end_tag_after)
if line_end_tag != line:
print(line_end_tag, end='')
found_open_tag = False
else:
print(line, end='')
```
Differential Revision: https://phabricator.services.mozilla.com/D44942
--HG--
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando
This will permit implementation of JSPrincipals::write().
Differential Revision: https://phabricator.services.mozilla.com/D44604
--HG--
rename : dom/worklet/WorkletPrincipal.cpp => dom/worklet/WorkletPrincipals.cpp
rename : dom/worklet/WorkletPrincipal.h => dom/worklet/WorkletPrincipals.h
extra : moz-landing-system : lando
Pruning these meant that `<span><br></span>` wasn't represented in the tree or rendered text at all.
This meant that lines were merged together in NVDA browse mode; e.g. in CI build logs on Gitlab.
The reason we started pruning these is that they were causing invalid line offsets to be returned for affected lines (bug 899433).
This patch also fixes this problem in HyperTextAccessible::FindOffset.
Differential Revision: https://phabricator.services.mozilla.com/D44815
--HG--
extra : moz-landing-system : lando
In the next part, the patch generated by a script removes "-moz" prefix
to all multi-column properties.
However, some of the tests already have standard multi-column properties
specified. To avoid duplicating CSS multi-column rules in these
files (after applying the next part), I manually remove the prefixed
rules beforehand as many as possible.
Differential Revision: https://phabricator.services.mozilla.com/D44869
--HG--
extra : moz-landing-system : lando
Flex containers resolve a main-axis size for each of their flex items, and they
impose this size on the flex items by stomping on the items'
ReflowInput::ComputedISize() or ComputedBSize() data. For cases when we're
stomping on the flex item's block-axis, then this can make us improperly treat
this size as definite (i.e. use it for percent resolution).
The flexbox spec does call out some cases where the item's size *is* supposed
to be considered definite[1], but if we're not in one of those cases, we need
to be careful to treat the size as indefinite even though it's been resolved.
This patch achieves this by:
- adding a flag to FlexItem, which gets set in cases where we know we need to
treat the size as indefinite.
- adding a flag to ReflowInput, which gets set whenever a ComputedBSize is
imposed (if the FlexItem had its flag set).
- adding some code to the ReflowInput percent-resolution codepath to test for
this flag and skip past percent-resolution if it's set.
This patch makes us pass all of the existing testcases in the web-platform-test
"percentage-heights-003.html". This patch also adds a few more subtests
there to exercise cases where the flex container and item have orthogonal
writing-modes.
(Note the XXXdholbert comments in the patch about items being "fully
inflexible" in some cases in order to be treated as having a definite size.
If I were to address that comment here, then we would start failing the
web-platform-test "percentage-heights-005.html", which all browsers currently
pass[2]. Therefore, I'm not adding that restriction at this point.)
[1] https://drafts.csswg.org/css-flexbox/#definite-sizes
[2] https://wpt.fyi/results/css/css-flexbox/percentage-heights-005.html
Differential Revision: https://phabricator.services.mozilla.com/D43705
--HG--
extra : moz-landing-system : lando
This is done by delaying the code within nsFrameLoader::CreateStaticClone until
after the document has been created. The nsFrameLoader is re-discovered using
the subframe BrowsingContext's mEmbedderElement.
Differential Revision: https://phabricator.services.mozilla.com/D44586
--HG--
extra : moz-landing-system : lando
This change was causing issues with images not displaying and iframes not
displaying correctly after multiple print preview calls.
Differential Revision: https://phabricator.services.mozilla.com/D44585
--HG--
extra : moz-landing-system : lando
This is so that SetUseCounter is as cheap as possible.
This is in preparation for hooking the CSS use counters to telemetry. We want
CSS use counters to be fast and be propagated at once to the parent page. This
will make sure to use the same setup as everywhere else.
Differential Revision: https://phabricator.services.mozilla.com/D44645
--HG--
extra : moz-landing-system : lando
Previous commit on this bug bumped up the test from a line-height of 1.5
to 1.8, but that's still not taller than the default widget height on Debian.
But 2.5 does seem to be sufficiently tall to produce a size difference.
Differential Revision: https://phabricator.services.mozilla.com/D44719
--HG--
rename : layout/reftests/forms/input/text/line-height-1.8.html => layout/reftests/forms/input/text/line-height-2.5.html
extra : moz-landing-system : lando
When we had it in the loop, we would continually reduce it, which held the
possibility of bumping it down an epoch due to double imprecision. Now
we only reduce it once, using all rAF callbacks get the same timestamp.
Differential Revision: https://phabricator.services.mozilla.com/D44526
--HG--
extra : moz-landing-system : lando
Most of things will likely be no real change because they ask for the exact frame they want immediately before.
Differential Revision: https://phabricator.services.mozilla.com/D44359
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
That gives the profiler a chance to attach to a newly created content
process. There's no API for waiting for the profiler to be ready in a
just-created process, unfortunately.
Differential Revision: https://phabricator.services.mozilla.com/D43898
--HG--
extra : moz-landing-system : lando
This patch was generated by running each of the scripts in the folder
layout/reftests/w3c-css/submitted/text-decor-3/support/
(This patch also includes a manual edit to reftest.list, to annotate some Win7
fuzziness that was caused by the new choice of font for a set of tests here.)
Differential Revision: https://phabricator.services.mozilla.com/D44258
--HG--
extra : moz-landing-system : lando
Also, adjust the scripts to leave behind a note in each generated HTML file, to
tell the reader that the file is auto-generated.
Differential Revision: https://phabricator.services.mozilla.com/D44257
--HG--
extra : moz-landing-system : lando
DONTBUILD because this is a comment-only change.
Per bug 1481951 comment 6, it seems our behavior was in fact correct even when
the comment was added, and this "// XXX" comment was just due to a
misunderstanding in what was going on in the testcase.
Differential Revision: https://phabricator.services.mozilla.com/D44229
--HG--
extra : moz-landing-system : lando
As noted this changes behavior, but it's unclear per
https://github.com/w3c/csswg-drafts/issues/2328 what behavior is correct, and
our behavior is inconsistent depending on whether there's any percentage
involved.
This matches other browsers so it's pretty low risk I'd say.
The test starts passing without changes to the test, but given the CSSWG issue I
made the test not rely on the optimization.
Differential Revision: https://phabricator.services.mozilla.com/D43754
--HG--
extra : moz-landing-system : lando
SVG Text stuff doesn't support abspos or anything like that, so it's not like it
is useful.
Differential Revision: https://phabricator.services.mozilla.com/D44136
--HG--
extra : moz-landing-system : lando
Most other overrides of nsIDOMEventListener::HandleEvent don't null check
aEvent at all. This method should never be called without an event.
Differential Revision: https://phabricator.services.mozilla.com/D38906
--HG--
extra : moz-landing-system : lando
For developing properties, we will handle them in an other bug.
Besides, I use an iframe for the test because we create a use counter in
the constructor of Document, which use the prefs to decide what kind of
properties we want to record. So, in the test, we have to reload iframe
to make sure we re-create the document, so does the use counter, to make
sure the prefs work properly.
The two prefs affect the css use counters:
1. layout.css.use-counters.enabled: Allocate use counters, and record
non-custom properties.
2. layout.css.use-counters-unimplemented.enabled: Record all unimplmented
properties into the use counters.
If we disable layout.css.use-counters.enblaed, we don't create use counters
object, so layout.css.use-counters-unimplemented.enabled doesn't work,
either.
Differential Revision: https://phabricator.services.mozilla.com/D43860
--HG--
extra : moz-landing-system : lando
In FrameLayerBuilder::ChooseScale we hit this line https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/layout/painting/FrameLayerBuilder.cpp#6124 and aVisibleRect is empty (because every call site except for nsDisplayMasksAndClipPaths::CreateWebRenderCommands (which doesn't need to) passes empty for the size of the bounds) and so the maxScale stays at 4, and we clamp to 4 instead of something 30-50.
The call to ChooseScale in StackingContextHelper::StackingContextHelper is the only place the size of aBounds is ever looked at. And we only ever call ChooseScale if we are passed a mBoundTransform which only nsDisplayTransform does. So this change should be quite safe.
Differential Revision: https://phabricator.services.mozilla.com/D43546
--HG--
extra : moz-landing-system : lando
