See comment. Not sure how easy to test this is in practice since it
involves nodes getting cc'd.
I tried to repro (not too hard) with a crashtest running
SpecialPowers.gc() but that didn't cut it, looks like.
Differential Revision: https://phabricator.services.mozilla.com/D154891
This patch doesn't change behavior but I had it lying around in my
machine, and makes the code a bit easier to follow, so no reason not
to land it IMO.
Differential Revision: https://phabricator.services.mozilla.com/D154886
The only thing that could trigger this is a bogus key, or overriding an
already-loading stylesheet which we didn't correctly coalesce.
Either of those is a bug.
Differential Revision: https://phabricator.services.mozilla.com/D154915
We can move a float frame into its block parent's PushedFloatsList during column
balancing when it cannot fit in the available block-size.
Later, when the column balancing algorithm reflows the last column in an
unconstrained block-size (in the very last reflow if needed [1]), we have to
reflow the line which contains the float's placeholder. The old code uses
`GetPrevInFlow() || GetNextInFlow()` to detect this scenario, which is
insufficient because the float's block parent might not have any continuation.
This patch uses `NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR` bit to detect this instead.
[1] https://searchfox.org/mozilla-central/rev/5c04fc7016eb7f52cf835d482f1125c8f139c959/layout/generic/nsColumnSetFrame.cpp#1144-1154
Differential Revision: https://phabricator.services.mozilla.com/D154860
This has the side effect of firing the media query list change event for
printing, but it also improves the print emulation on DevTools, which is
an extra win!
Differential Revision: https://phabricator.services.mozilla.com/D154906
The font here is a copy of Ahem with a COLRv1 table added, using various of the
COLRv1 paint and transform tables. This is far from an exhaustive set of tests,
but serves to check that basic rendering functionality is working.
The reference file uses CSS blocks filled with gradients, etc, to simulate the
expected rendering of the colored Ahem glyphs. This is unlikely to be a perfect
match in any but the simplest cases, thanks to antialiasing, pixel-rounding, etc.,
but the results are visually indistinguishable, or virtually so, and the amount
of "fuzz" is far less than the differences would be in the case of the COLRv1
glyphs actually being mis-rendered.
(There's a try run *without* the fuzz annotations at
https://treeherder.mozilla.org/jobs?repo=try&revision=4a2e2f7190661614ecddd223dd7178589d0ec5f2
where the results can be viewed in reftest-analyzer.)
We may eventually want to move this or similar tests into WPT, but I'm expecting
more extensive test coverage to be a co-operative effort with the other vendors
who are also implementing support, so this is intended as an interim step just to
ensure we have the basic functionality tested in-tree.
Depends on D154585
Differential Revision: https://phabricator.services.mozilla.com/D154586
The fix is the one line in
nsImageLoadingContent::MaybeForceSyncDecoding, but I added new asserts
that should prevent this from regressing in the future.
Differential Revision: https://phabricator.services.mozilla.com/D154815
By making image loading in <embed> and <object> behave more like when
an <iframe> loads an image, we can make sure that the synthetic
document generated is process switched if the image is cross
origin. This is done by making image loading in nsObjectLoadingContent
follow the document loading path.
We also make sure that we pass the image size back to the embedder
element to not get stuck with the intrinsic size.
To avoid named targeting being able to target these synthetic
documents, as well as showing up in `Window.frames` and being counted
in `Window.length`, we keep a filtered list of non-synthetic browsing
contexts for that use-case.
This feature is controlled by two prefs:
* browser.opaqueResponseBlocking.syntheticBrowsingContext
This triggers the creation of synthetic documents for images loaded
in <object> or embed.
* browser.opaqueResponseBlocking.syntheticBrowsingContext.filter
This turns on the filtering of synthetic browsing contexts in named
targeting, `Window.length` and `Window.frames`.
Differential Revision: https://phabricator.services.mozilla.com/D148117
The font here is a copy of Ahem with a COLRv1 table added, using various of the
COLRv1 paint and transform tables. This is far from an exhaustive set of tests,
but serves to check that basic rendering functionality is working.
The reference file uses CSS blocks filled with gradients, etc, to simulate the
expected rendering of the colored Ahem glyphs. This is unlikely to be a perfect
match in any but the simplest cases, thanks to antialiasing, pixel-rounding, etc.,
but the results are visually indistinguishable, or virtually so, and the amount
of "fuzz" is far less than the differences would be in the case of the COLRv1
glyphs actually being mis-rendered.
(There's a try run *without* the fuzz annotations at
https://treeherder.mozilla.org/jobs?repo=try&revision=4a2e2f7190661614ecddd223dd7178589d0ec5f2
where the results can be viewed in reftest-analyzer.)
We may eventually want to move this or similar tests into WPT, but I'm expecting
more extensive test coverage to be a co-operative effort with the other vendors
who are also implementing support, so this is intended as an interim step just to
ensure we have the basic functionality tested in-tree.
Depends on D154585
Differential Revision: https://phabricator.services.mozilla.com/D154586
The font here is a copy of Ahem with a COLRv1 table added, using various of the
COLRv1 paint and transform tables. This is far from an exhaustive set of tests,
but serves to check that basic rendering functionality is working.
The reference file uses CSS blocks filled with gradients, etc, to simulate the
expected rendering of the colored Ahem glyphs. This is unlikely to be a perfect
match in any but the simplest cases, thanks to antialiasing, pixel-rounding, etc.,
but the results are visually indistinguishable, or virtually so, and the amount
of "fuzz" is far less than the differences would be in the case of the COLRv1
glyphs actually being mis-rendered.
(There's a try run *without* the fuzz annotations at
https://treeherder.mozilla.org/jobs?repo=try&revision=4a2e2f7190661614ecddd223dd7178589d0ec5f2
where the results can be viewed in reftest-analyzer.)
We may eventually want to move this or similar tests into WPT, but I'm expecting
more extensive test coverage to be a co-operative effort with the other vendors
who are also implementing support, so this is intended as an interim step just to
ensure we have the basic functionality tested in-tree.
Depends on D154585
Differential Revision: https://phabricator.services.mozilla.com/D154586
When the dynamic toolbar is completely collapsed and calculating the visible
rect for out of flow content, ensure that the visible rect is expanded to
include the dynamic toolbar max height.
Differential Revision: https://phabricator.services.mozilla.com/D152807
This lets users e.g. print-to-scale where it matters.
Custom margins are still clamped to unwriteable margins, even when all zeroes,
to avoid impacting user-specified & persisted margins.
Differential Revision: https://phabricator.services.mozilla.com/D152900
For this to work, we need to add a move-constructor to `Locale`, so that it's
possible to write `loc = {}`. (We need move instead of copy semantics, because
`Locale` has UniquePtr members.) All other `Locale` members except for
`LanguageTagSubtag` already support move semantics. Add copy-constructors to
`LanguageTagSubtag`, so defaulted move-constructor/assignment works for `Locale`.
`LanguageTagSubtag` gets copy- instead of move-constructors, because there isn't
a good reason to disallow copying when moving is allowed.
Also add extra assertions and comments to document the requirement that `TryParse`
expects a new, empty `Locale`.
Differential Revision: https://phabricator.services.mozilla.com/D154496
- Remove the preference and corresponding tests.
- nsMathMLmencloseFrame continues to implement the radical notation for
now, since it's still used by nsMathMLmsqrtFrame. Ideally, we should
refactor our code so that msqrt/mroot share the same implementation.
Differential Revision: https://phabricator.services.mozilla.com/D154194
Before this change, BrowserChild::RecvUIResolutionChanged calls
UIResolutionChangedSync first, then updates CV bounds. With the setup, when
UIResolutionChangedInternal gets called, the CV bounds hasn't yet been updated
so that UpdateSizesBeforeReflow doesn't get the proper metrics.
This change consists of three parts;
1) Use UIResolutionChangedSync instead of UIResolutionChanged in
nsDocumentViewer::SetBoundsWithFlags which calls
nsPresContext::AppUnitsPerDevPixel which needs to be actually updated by
UIResolutionChangedSync.
2) Move the UIResolutionChangedSync call in RecvUIResolutionChanged after
the SetPositionAndSize in the function.
3) Add a UpdateSizesBeforeReflow call in UIResolutionChangedInternal
As for 1), nsDocumentViewer::SetBoundsWithFlags calls
nsPresContext::AppUnitsPerDevPixel so that UIResolutionChangedInternal needs to be
called synchronously rather than asynchronously.
As for 2), SetPositionAndSize gets called only if the BrowserChild size is changed,
so we need to call UIResolutionChangedSync in other cases.
Differential Revision: https://phabricator.services.mozilla.com/D153687
When block size is initially indefinite but later was determined by the contain intrinsic
size, we calculate the repeat fill count using the contain intrinsic block size.
Differential Revision: https://phabricator.services.mozilla.com/D153933
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
When block size is initially indefinite but later was determined by the contain intrinsic
size, we calculate the track sizes using the contain intrinsic block size.
Differential Revision: https://phabricator.services.mozilla.com/D153623
By making image loading in <embed> and <object> behave more like when
an <iframe> loads an image, we can make sure that the synthetic
document generated is process switched if the image is cross
origin. This is done by making image loading in nsObjectLoadingContent
follow the document loading path.
We also make sure that we pass the image size back to the embedder
element to not get stuck with the intrinsic size.
To avoid named targeting being able to target these synthetic
documents, as well as showing up in `Window.frames` and being counted
in `Window.length`, we keep a filtered list of non-synthetic browsing
contexts for that use-case.
This feature is controlled by two prefs:
* browser.opaqueResponseBlocking.syntheticBrowsingContext
This triggers the creation of synthetic documents for images loaded
in <object> or embed.
* browser.opaqueResponseBlocking.syntheticBrowsingContext.filter
This turns on the filtering of synthetic browsing contexts in named
targeting, `Window.length` and `Window.frames`.
Differential Revision: https://phabricator.services.mozilla.com/D148117
This is a follow-up to bug 1783500. The existing expansion for the
screen area works great on Windows and so on, but on macOS it can
conceptually cause a menulist to go off-screen, because of this margin
used to move menulists to the left:
https://searchfox.org/mozilla-central/rev/f655bdf6b4bf01b42609750ab94fc37635397260/toolkit/themes/osx/global/popup.css#85
Instead we should do the same as that bug did, and use the
input-region-margin, which is the amount of space that has no content
(that is, that contains the shadow and so on) and is zero on macOS
(because shadows on macOS are drawn by the OS unlike on Windows /
Linux).
This required extra test changes so it was worth getting it reviewed
separately.
Differential Revision: https://phabricator.services.mozilla.com/D154401
Now that the style system has keywords for this, we don't need to define them in gfx
but can just use the enum directly. (No functional change, just code simplification.)
Depends on D154237
Differential Revision: https://phabricator.services.mozilla.com/D154238
With part 1, ReflowChildren and ReflowColumns are identical except for the
constness of the ReflowConfig. I choose to remove ReflowChildren because
ReflowColumns is more meaningful and keeping it requires less change to the
existing code.
Differential Revision: https://phabricator.services.mozilla.com/D154428
Remove the flag because it doesn't serve its purpose for current multicolumn
frame hierarchy (i.e. after we introduce ColumnSetWrapperFrame). Nowadays, we
limit the column's block-size with the column container's block-size and
max-block-size in [1]. If the column container has content which exceeds its
max-block-size, we are going to give up column balancing and reach [2] after the
first iteration in the column balancing `while` loop in FindBestBalanceBSize().
However, the flag can still be set in cases with absurd `nscoord` values, so
this patch still changes the behavior. For example, in crashtests with bogus
sizes such as 673770.html,
```
contentBEnd > aReflowInput.mCBReflowInput->ComputedMaxBSize() && aConfig.mIsBalancing
```
can still be true when `contentBEnd` is greater than `nscoord_MAX`. In such
cases, we might spend extra iterations in column balancing. Other than that, our
rendering shouldn't have perceived behavior change.
[1] https://searchfox.org/mozilla-central/rev/6a37a2ab9328bec6a29f688d1b2fba6974d34905/layout/generic/nsBlockFrame.cpp#3834-3844
[2] https://searchfox.org/mozilla-central/rev/6a37a2ab9328bec6a29f688d1b2fba6974d34905/layout/generic/nsColumnSetFrame.cpp#1145-1162,1169-1173
Differential Revision: https://phabricator.services.mozilla.com/D154427
Emilio Cobos Álvarez
Marian-Vasile Laza
Ting-Yu Lin
Jonathan Kew
Oriol Brufau
Iulian Moraru
Andreas Farre
Noemi Erli
Andi-Bogdan Postelnicu
Dan Robertson
David Shin
Butkovits Atila
Martin Robinson
André Bargull
Frederic Wang
Hiroyuki Ikezoe
Ziran Sun
Sandor Molnar