Tag is unused.
This changes how some mixes of MathML and html get wrapped in anonymous table
boxes (in particular, it changes whether it uses a MathML or an HTML table
frame). The main thing this affects is whether the frame responds to certain
attributes. Responding to mathml attributes on its mContent when that mContent
is not a MathML element is weird. So arguably this is also more correct.
However, that seems acceptable to me, and you can already get that mixing
manually. On a few (arguably simple) manual test-cases mixing MathML and HTML
tables I couldn't manage to get the patched build to render differently.
Plus, neither our reftests nor the WPT MathML test-suite upstreamed by Fred Wang
for WebKit rely on this.
MozReview-Commit-ID: 8IV3iF5xIs0
This covers all the reftests that have lower fuzz (or zero fuzz) and
were producing an UNEXPECTED-PASS result with webrender on windows. In
many cases I just adjusted the lower bound of the existing webrender
fuzz. In other cases existing fails-if conditions had to be tweaked to
exclude webrender.
MozReview-Commit-ID: 49LvS0vuYWR
--HG--
extra : rebase_source : d194e24affb87fe4560a127ff4016f9c38f414fd
Many of these could probably be fuzzed but in the interests of getting
the reftest suite turned on sooner I'm doing a blanket fails-if. This
covers all the reftests where there is more fuzz with webrender on
windows than any of existing annotations account for. In some cases the
fuzz is only a few pixels more than the equivalent Linux fuzz already
annotated, but I'll clean that up in a future bug.
MozReview-Commit-ID: IaKarbnL46d
--HG--
extra : rebase_source : 71889340305b0b12fa8eace722e42bb3faf14419
This test started failing after a reftest rebucketing. It's likely a
particularly-bad special case of known win7 intermittent bug 1392106. For now,
let's mark it as random on Win7 and continue investigating the general issue in
bug 1392106.
MozReview-Commit-ID: KX707Y9ycIC
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
And then fix up everything else that needs to change as well.
MozReview-Commit-ID: GDMfERqdQAc
--HG--
extra : rebase_source : 01fe06c3182245a409099a53383d92bf4fa0155c
We don't extend svg elements, except in a lone test, that isn't really impacted
by this.
I agree this should look at the frame btw, though that looks a bit out of scope
for this bug.
MozReview-Commit-ID: MbvIE5TszB
We never extend xul:tooltip, xul:menupopup or xul:popup, so this can go away.
MozReview-Commit-ID: LZsGYRdI5tW
--HG--
extra : rebase_source : 7d520fa9729f27b1a6a0b2ad3f4eed55f9729aeb
This patch does the following things:
* Create a new class ServoFontFaceRule for CSSOM of @font-face rule
which mostly follows how nsCSSFontFaceRule was implemented.
* Remove the old nsCSSFontFaceRule and binding code to create it.
* Have FontFace backed by Servo data via making mRule and mDescriptors
of the class hold RawServoFontFaceRule like ServoFontFaceRule.
To keep this patch small, it effectively just delays the conversion
from Servo data to nsCSSValue from parsing to using. This may cause
worse performance if the font set is flushed repeatedly. Supposing we
don't flush font set very frequently, it may not be a big deal.
We may still want to remove the intermediate nsCSSValue conversion at
some point, and have everything converted to their final form directly
when used, but that can happen in followups.
There are some unfortunate bits from this change:
* We lose style sheet for logging in FontFaceSet. This is probably not
all that worse, because we wouldn't have that before either if the
page doesn't use CSSOM to visit it. But we should figure out some
approach to fix it anyway.
* InspectorFontFace no longer shares the same rule object as CSSOM.
This isn't really a problem if the @font-face rule isn't very mutable.
Unless we want to make the rule returned from InspectorFontFace to be
mutable (i.e. via inspector), not using the same object probably isn't
too bad.
This patch switches the code we use to serialize stuff in FontFace and
CSSFontFaceRule, which leads to some failures in tests. Specifically,
the expected changes including:
* Value of font-family now can be serialized to identifier sequence like
font-family property. The old code always serializes it to string,
but it doesn't seem to have different requirement than the property.
Blink can serialize to identifier as well.
* Family name inside local() is also changed to use the same way as
family names elsewhere (i.e. can be identifier sequence). Blink has
the same behavior as the old code, but I don't think it's a big deal.
* The order of descriptors serialized gets changed. I don't think it
matters at all.
* Empty string as font-family via using string syntax is no longer
considered invalid for FontFace. I don't find it is mentioned anywhere
that it should be specifically treated invalid.
MozReview-Commit-ID: 32Fk3Fi9uTs
--HG--
extra : rebase_source : 6221ec8fc56de357b06dd27e770fb175348a2f77
This patch basically does:
* Add descriptor setters and generation count to CounterStyleRule in
Servo. (This code is mostly based on the old code inside
nsCSSCounterStyleRule for handling mutation.)
* Use RawServoCounterStyleRule in CounterStyleManager.
* Add ServoCounterStyleRule and remove nsCSSCounterStyleRule.
Test change:
* "fixed" was parsed as and thus serialized to "fixed 1", but Servo
doesn't do so. It preserves whether the number presents. Either way
is probably fine.
MozReview-Commit-ID: EtKTeu32isi
--HG--
extra : rebase_source : ec44f01c581003ce4b6ef69435a05de7f3da5469
In the state of STATE_WAITING_TO_FIRE_INVALIDATE_EVENT, we flush all pending
styles and layout and wait for a MozAfterPaint that caused by the flush. This
will be repeated until neither pending styles nor layout exists. But if there
is any throttled animation, flush for the throttled animation might
cause a new MozAfterPaint. That means that we will get stuck until the
throttled animation finished.
In this patch, to avoid this situation, we don't flush throttled animations in
the state of STATE_WAITING_TO_FIRE_INVALIDATE_EVENT.
MozReview-Commit-ID: LUz279w3Yoj
--HG--
extra : rebase_source : 9a1f0fa791645d46c3105c1ba56a2cf5914ffa9d
This feature is B2G only. Remove it to make AccessibleCaret simpler to
maintain.
MozReview-Commit-ID: 7JZw5XtaUeU
--HG--
extra : rebase_source : aba249d361723feeaf769a3b802564dbcd6ca9ea
The new StaticPrefs machinery means that StylePrefs can be removed.
Note that this approach mirrors all static prefs into Rust, but I have only
updated structs.rs for the prefs that Stylo uses.
On a CLOSED TREE, since a sheriff closed the tree while I was about to land this
via autoland.
MozReview-Commit-ID: G1SY0987WJ7
Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer
to the canonical pointer to that static atom. Which is pretty weird! The
notable thing thing about it is that these structs are in an array, and that
gives us the only way to iterate over all static atoms in a single class, for
registration and lookups.
But thanks to various other recent changes to the implementation of static
atoms, we can now put the static atoms themselves into an array, which can be
iterated over. So this patch does that. With that done, nsStaticAtomSetup is no
longer necessary.
According to the `size` utility, on Linux64 this reduces the size of libxul.so
by the following amounts:
> text: 62008 bytes
> data: 20992 bytes
> bss: 21040 bytes
> total: 104040 bytes
- The bss reduction is one word per atom, because the canonical static atom
pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're
now initialized at compile time instead of runtime.
- The data reduction is one word per atom, because we remove two words per atom
for the nsStaticAtomSetup removal, but gain one word per atom from the
previous bullet point.
- I'm not sure about the text reduction. It's three words per atom. Maybe
because there is one less relocation per atom?
Other notable things in the patch:
- nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom,
not nsAtom, because that's more precise.
- Each static atoms array now has an enum associated with it, which is used in
various ways.
- In the big comment about the macros at the top of nsStaticAtom.h, the pre-
and post-expansion forms are now shown interleaved. The interleaving reduces
duplication and makes the comment much easier to read and maintain. The
comment also has an introduction that explains the constraints and goals of
the implementation.
- The SUBCLASS macro variations are gone. There are few enough users of these
macros now that always passing the atom type has become simpler.
MozReview-Commit-ID: 1GmfKidLjaU
--HG--
extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
For nsCSSAnonBoxes.cpp, nsCSSPseudoElements.cpp, nsDirectoryService.cpp, the
corresponding .h file includes nsStaticAtom.h. For the other files in this
patch, nsStaticAtom.h is not needed at all.
MozReview-Commit-ID: IpMmbXwZHhu
--HG--
extra : rebase_source : 46d0a6b40a41ee233adad7c205cf907fa27de34a
This patch adds three test cases;
1) Animation on position:absolute element in a zero-height iframe
This animation should be throttled.
2) Animation on a non-zero width and hight position:absolute element but whose
parent has a zero height
This animation should NOT be throttled since the animation is visible
3) Animation on a zero-height position:absolute element whose parent also has
zero height.
This animation should be throttled since the animation is invisible
The first test fails without this fix and passes with the fix.
The second one passes regardless of the fix
The third one is marked as 'todo' since it doesn't pass with this fix.
MozReview-Commit-ID: 8pNUFQ71ivj
--HG--
extra : rebase_source : d1d37e5324247efc20a39d86a0f8849450cc7533
BACKGROUND:
Early in flex layout, we have to resolve the 'flex-basis' value to produce the
"flex base size" (basically, the flex-basis resolved to an absolute length).
This resolution happens in two "phases" (which both happen within
nsFlexContainer::GenerateFlexItemForChild()):
First phase: we try to resolve the flex-basis by creating a ReflowInput for the
flex item (which gets us some other things as well). Under the hood, we use
the flex-basis when resolving this ReflowInput's main-axis size. The code for
this lives in nsFrame::ComputeSize (and in
nsFrame::ComputeSizeWithIntrinsicDimensions, via some frame classes' overrides of
ComputeSize).
Second phase: If the first phase didn't get us a definite size, then that means
we have to do reflow to measure the content size & produce a resolved flex base
size, which we do via ResolveAutoFlexBasisAndMinSize().
NOTES ON THIS PATCH:
To add 'flex-basis:content' support to layout, this patch only needs to modify
the first phase discussed above. If it turns out we also have some second-phase
work to do (i.e. if we need to do reflow to resolve 'flex-basis:content'), this
patch causes that reflow to happen by simply making us use eStyleUnit_Auto in
the main axis's nsStyleCoord in the first phase. (And then, if that 'auto'
nsStyleCoord really does require reflow, then that first phase will end up
producing an unconstrained main-size in the flex item's ReflowInput, which will
automatically trigger the second phase.)
MozReview-Commit-ID: 2nH4Fh78C81
AccessibleCaretManager uses scroll and reflow observers to detect when
to update the position of carets. However, it currently only registers
the observers on the leaf docshell, so only changes in the innermost
iframe are detected; that is, it fails to update caret position when an
ancestor iframe is scrolled. This patch makes it register observers on
all ancestor docshells so that changes in ancestor iframes are detected
as well.
MozReview-Commit-ID: bwiSjj8936
--HG--
extra : rebase_source : d567f1d8df67f79769c6532b061e2df1e5ab878f
This happens when an nsIFrame* that builds an nsDisplayWrapList is deleted, but then the memory is immediately reused for another frame that builds the same type display item, within the same display list.
PreProcessDisplayLists chooses not to descend into the nsDisplayWrapList for the deleted frame, and so mOldItems remains uninitialized for the old sublist.
When adding the new instance, IsChanged returns false, since the pointers are the same, and we're checking HasDeletedFrame on the new instance (where it's never true), instead of the old. We then recurse into MergeDisplayLists, with an uninitialized mOldItems array, and crash.
I haven't added a test because I haven't yet figured out how to create a minimal testcase, and the test would rely on implementation details of the frame allocator to remain unchanged to be useful.
MozReview-Commit-ID: pHimEvfAND
--HG--
extra : rebase_source : 10baa8cabf1eca8d592f2be0eb7bc7c9461f9785
When we finish decoding an image frame, we need to trigger reflow for the
frame containing a float with shape-outside: <image>, and delay the firing
of the document's onload event until that reflow is complete.
When we finish decoding an image frame, we need to trigger reflow for the
frame containing a float with shape-outside: <image>, and delay the firing
of the document's onload event until that reflow is complete.
This reworks bug 1440561 so that we only precompute loads that belong to our
user font set, avoiding messing up with fonts in the cache that belong to other
pages.
The loadability of a font is precomputed in PreTraverse in the same way as we
did, but only for the fonts that we may end up loading. This is stored in
FontFaceSet now.
Also, the principal shenanigans that this code did are reworked to be explicit
about when the document principal changes in ResetToURI, instead of having a
member around and a mutable variable. This makes the code easier to follow.
MozReview-Commit-ID: 9ofTbaLDUF7
Bug 1443492 made us flush the parent document for cross-doc getComputedStyle
situations. That can kill the shell we're flushing, let's handle that case
gracefully.
MozReview-Commit-ID: HpFsPQvjKcZ
There's been a clarification to the spec text that this comment was worried about:
https://github.com/w3c/csswg-drafts/issues/2316
And with that clarification, this comment is no longer applicable.
This patch should not affect behavior.
Logic-wise: the idea behind this patch is to behave as if the
'usingFlexBasisForHeight' variable were always false, which in turn lets us
remove an "if (!usingFlexBasisForHeight || ...)" check, because it trivially
passes when that bool is false.
Background on this special case & why we can remove it:
=======================================================
In the original flexbox implementation, we had some special-case code to be
sure we didn't end up swapping in e.g. "flex-basis:-moz-min-content" for
"height" in these ComputeSize functions, because that was a scenario that
previously would've been prevented at the parser level (height:-moz-min-content
is rejected for now), and hence may not have ended up being handled robustly.
However, nowadays it'll be handled just fine in these functions, and will
produce the same result as our special-case exception tries to achieve.
In particular, for a nsFrame that is a flex item in a flex container with a
vertical main axis (the scenario that these special cases are catching):
- If the (vertical) main axis is this nsFrame's inline axis (i.e. if this
nsFrame has a vertical writing-mode), then Stylo actually converts
enumerated flex-basis values like "-moz-min-content" to "auto" when
producing the computed values that layout sees. So it's not actually
possible for layout to see a computed "flex-basis" of -moz-min-content, in
that scenario.
- Otherwise, i.e. if the (vertical) main axis is this nsFrame's block axis,
then these ComputeSize functions will now end up getting an enumerated
"blockStyleCoord" (really pointing to flexBasis), but that'll still end up
being treated like 'auto'. This happens by virtue of ComputeSize's calls to
ComputeAutoSize (which initializes the tentative bsize value to
NS_UNCONSTRAINEDSIZE) and to nsLayoutUtils::IsAutoBSize (which returns
"true" for eStyleUnit_Enumerated values and then makes us leave the
ComputeAutoSize result unperturbed).
The dirty bit fiddling is nontrivial, but it's pretty much what we do for
invalidation and allows to keep this incrementally easily.
The only caller that we cared about for the GetFlattenedTreeParent check in
DestroyFramesForAndRestyle was the old ShadowRoot invalidation functions that
went away.
MozReview-Commit-ID: GmgPPJ6d2qX
This was useful because nsRuleData in the old style system may not hold
all the data, but the only subclass ServoSpecifiedValues is always able
to hold any data, and thus passes NS_STYLE_INHERIT_MASK to mSIDS. Given
this, this method and mSIDs seems to be useless and can be removed.
MozReview-Commit-ID: 4vWcV4DRS2i
--HG--
extra : rebase_source : 4f364d431821e29838082e391c6dde08af7f5343
I don't have a strong preference about blending with white vs. just doing alpha
0.5, so I kept doing what we were doing, since Blink and WebKit also apply the
blending to the text background, and I'm not sure that's particularly desirable.
MozReview-Commit-ID: AwYtAgdlcxj
NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
