Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
- Remove code for align/denumalign/numalign attributes.
- Remove tests checking support for them.
- Remove warning message and counter.
- numalign/denomalign atoms are not removed, since they
are still used by nsTreeSanitizer.
Differential Revision: https://phabricator.services.mozilla.com/D154197
Adds trait ZeroNoPercent to check for values that are 0 (such as 0px) but not 0%
Updated test css/css-transforms/animation/translate-interpolation.html and removed unnecessary formatting changes
Differential Revision: https://phabricator.services.mozilla.com/D154930
There's no point using a helper thread if we're going to wait for it
immediately. We do perform non-incremental GCs sometimes (and in shutdown) and
this avoids the possibility of scheduling issues affecting us.
This applies to background sweeping, decommiting and unmarking.
(I think I argued against this at one point, but I've come round to thinking
it's a good idea.)
Differential Revision: https://phabricator.services.mozilla.com/D155610
We have an extra check in DoMarking that allows gray marking in the atoms zone
even when it's in the marking black only state. It's simpler to start this zone
in the marking black and gray state and remove the special case.
The reason for this case is that we can't delay gray marking in zones that are
marking black only for atoms like we do for objects. In that case we push the
CCWs into the black zone on a list and mark them later when that zone
transitions to black and gray marking. But the atoms zone may have direct
references from any zone that don't go through CCWs.
Differential Revision: https://phabricator.services.mozilla.com/D155605
These frames don't honor overflow in any meaningful way, except for
textarea, where overflow inherits into its editing root.
That style change however should be handled on its own by reflowing
(thus avoiding the reframe).
We need to fix GetDesiredScrollbarSizes, which wasn't accounting for
having scrollbars + overflow: hidden / scrollbar-width: none. Reftests
caught that.
Differential Revision: https://phabricator.services.mozilla.com/D155535
formatURL is only used in one other place - nsContextMenu.js, so we don't really need that when we can call the necessary function direct.
Also moves `searchEnginesURL` into SearchUIUtils, as that seems a reasonable place to start storing things like that.
Differential Revision: https://phabricator.services.mozilla.com/D155496
This can happen in a container containing no actual characters.
Previously, we would end up in an infinite loop in this case.
Differential Revision: https://phabricator.services.mozilla.com/D155570
This bug is regressed by Bug 1686603 Part 4 [1]. When the used flex-basis is
'content', the old code computes flex base size by using 'auto' as the main size
in `nsContainerFrame::ComputeSizeWithIntrinsicDimensions()`. The method is for
replaced elements to compute sizes, even if the element has no preferred
aspect-ratio such as an `<svg>` without viewBox nor aspect-ratio property.
However, Bug 1686603 Part 4 made replaced elements without preferred
aspect-ratio uses 'max-content' when computing flex base size. Unfortunately, we
only trigger the replaced elements intrinsic sizing via 'auto' but not via
'max-content', so this patch restores the behavior via emplacing 'auto' in
`styleFlexBaseSize`.
[1] https://phabricator.services.mozilla.com/D101795
Differential Revision: https://phabricator.services.mozilla.com/D155628
The three wpt tests are adapted from dholbert's testcases in the bug, and
written in checkLayout flavor. They should have the same rendering.
Differential Revision: https://phabricator.services.mozilla.com/D155627
* Only show the mobile promo when tab syncing is enabled
* Toggle the promo & confirmation visibility in all setup states to ensure it gets hidden when we re-enter the sign-in to FxA state
* Add test coverage for signing out
* Ensure we always restore the mocks
Depends on D155427
Differential Revision: https://phabricator.services.mozilla.com/D154850
Unfortunately this test doesn't run as expected on our CI since macs on our CI
are running normal DPI mode.
I tested this test works properly on my macbook, it fails without the fix in the
previous commit and it passes with the fix.
Differential Revision: https://phabricator.services.mozilla.com/D153688
Additionally,
* `PropItem` -> `PendingStyle`
* `StyleCache` -> `PendingStyleCache`
* `AutoStyleCacheArray` -> `AutoPendingStyleCacheArray`
And finally, `PendingStyle` (formally `PropItem`) is changed to `class` and
its members are encapsuled.
Differential Revision: https://phabricator.services.mozilla.com/D155318
For consistency with the previous patch, we should rename them too. Then, we're
getting rid of unclear word "Prop" from the public methods.
Differential Revision: https://phabricator.services.mozilla.com/D155316
I usually retry to understand what they mean. Therefore, I'd like to give new
names for them (and rename `TypeInState` class in a following patch).
Differential Revision: https://phabricator.services.mozilla.com/D155315
Only the value member needs to be updated when setting the prop multiple times.
Therefore, we cannot change all members to constants.
Differential Revision: https://phabricator.services.mozilla.com/D155313
According to the debug, its value can be CSS property value if in the CSS mode.
For making the value meaning easier to understand, this renames it to
mAttributeValueOrCSSValue.
Differential Revision: https://phabricator.services.mozilla.com/D155312
It's currently no problem to manage it with a raw pointer because it may be
set to a dynamic atom only when `nsIHTMLEditor.insertLinkAroundSelection` is
called with unknown attribute, but comm-central uses it only with `href`
attribute.
I think that we should change the API just to take `href` value in the future,
but for now, it should be `RefPtr<nsAtom>`.
Differential Revision: https://phabricator.services.mozilla.com/D155311
It's always a pointer to `nsStaticAtom` instance or `nullptr`. Therefore,
it can be `nsStaticAtom*` and we can make its users treat `nsStaticAtom`
instead of `nsAtom`.
Additionally, this patch changes some pointer parameters to references if
they are never `nullptr`.
Differential Revision: https://phabricator.services.mozilla.com/D155310
In bug 1739524, I misunderstood the meaning of `aOffset` of `SelAdjJoinNodes`.
After joining 2 nodes, and a point points right node which will have ex-left
node content, the point needs to point ex-start of the right node to keep
next insertion point as-is. Therefore, it's not useful with new join nodes
direction, it needs to know the ex-offset of the right node.
Differential Revision: https://phabricator.services.mozilla.com/D155438
