Using namespace id fixes this issue because in Gecko, the pref of MathML
(as well as SVG) works in the way that we choose a different namespace
id (the disabled id) for the elements. Those ids are mapped to the same
namespace atom as normal ids, which means if we use the atom, we would
treat the elements like normal mathml elements.
MozReview-Commit-ID: 9YBBokbP04M
--HG--
extra : rebase_source : 397f09db41a22bfa34e4abe26ad10027dab83d0d
This was already marked fuzzy but now the difference between the test and
reference images is even more pronounced. Technically this might still be fuzzable
because the thickness of the text (which is what is different) is not what the
test is testing for. But if we fuzz it the fuzz numbers would be so high that
legitimate failures might get fuzzed as well, so it's better to just mark it
failing for now and deal with it later.
MozReview-Commit-ID: 3Wt32XB1TWG
--HG--
extra : rebase_source : 5310a5b2deb187dcf0e4d3bc009bfae6abd1ef24
When a reframe happens on the parent of a pseudo element which has animations,
we need to grab style for the pseudo element that includes the animations'
style and also *replace* old style context (that does not include animations'
style) with it. Otherwise, we will use the old style context that has *no*
animations style, as a result, we will see a flicker right after the reframe.
Two reftests in this patch fail without this fix. One is for CSS transitions,
the other one is for CSS animations.
MozReview-Commit-ID: 6pCdnQ1DGUY
When display style is changed from 'none' to other in animation-only restyle
we need to resolve descendant elements' style that were in the display:none
subtree.
Three possible ways to resolve the descendant elements' style;
1) Traversing unstyled elements in animation-only restyle
We can't simply traverse unstyled elements in the animation-only restyle
since when we decided to traverse the unstyled elements we don't know yet
the elements will be initially styled or are in display:none subtree. It
will result that the new elements are styled in animation-only restyle,
it's undesirable.
2) Creating a SequentialTask and resolve the descendants' style with
ServoStyleSet::StyleNewSubtree()
We can't resolve the descendants' styles with ServoStyleSet::StyleNewSubtree()
in SequentialTask since at the moment we are still in servo traversal (i.e.
sInServoTraversal is true). That means AutoSetInServoTraversal fails
in PrepareAndTraverseSubtree().
3) Creating a SequentialTask and set restyle subtree hint and defer descendants'
restyle in a subsequent normal traversal
Note that, when we process throttled animations flush, we don't process
normal traversal so the descendants will not be traversed until normal
restyle happens but it will not be a big problem since it's really rare
that user clicks display animation element just at the right moment when
display property changes from none to other. Also, if it will be really
a problem, we should process *only* transform animations on the compositor,
it's ideally right thing to do. Display property never runs on the
compositor.
This patch takes the third approach.
MozReview-Commit-ID: Krxa3kkdIq4
--HG--
extra : rebase_source : 33e9db953f21168c76716329568191625bd15896
After bug 1356141, the setup of animation-only dirty bit should have matched
to normal dirty bit's one (Though they don't match in post traversal due to
throttled animation flush). An unset_animation_only_dirty_descendants call
removed in this patch cleared dirty bits which are needed for post traversal if
there is a second animation-only traversal and if there is no need to restyle
for the second animation-only traversal.
The reftest in this patch fails without either this fix or the fix for bug
1367975.
See [Gecko bug 1384435 comment 12](https://bugzilla.mozilla.org/show_bug.cgi?id=1384435#c12)
for more detail what's going on at that time.
MozReview-Commit-ID: Dw24Vgoabmd
--HG--
extra : rebase_source : 7f64dc16b03b0c0a32ac5dfeb4f8561c900d461e
With this patch, we now have an automated test to verify if a transition
is run properly on a visited link. Note that the test aims to verify
the behavior in Stylo should match that in Gecko. Due to Bug 868975, we
haven't supported transitioning on visited styles yet, so the test should
be put in our own repo for now. This test can be tweaked and put into
web-platform repo once we resolve Bug 868975.
MozReview-Commit-ID: Ci1cERXkIUK
--HG--
extra : rebase_source : 7feb1229bc2dc430bc2a1e40be40047049469fbd
This doesn't actually implement style context reparenting in the style set yet; that part is next.
There is one behavior difference being introduced here compared to Gecko: we
don't reparent the first block piece of an {ib} (block-inside-inline) split
whose first inline piece is being reparented. This is actually a correctness
fix. In this testcase:
<style>
#target { color: green; }
#target::first-line { color: red; }
</style>
<div id="target">
<span>
<div>This should be green</div>
</span>
</div>
Gecko makes the text red, while every other browser makes it green.
We're preserving Gecko's behavior for out-of-flows in first-line so far, but
arguably it's wrong per spec and doesn't match other browsers either. We can
look into changing it later.
MozReview-Commit-ID: 5eC6G449Mlh
--HG--
extra : rebase_source : 8c333a0afe96c68a4e3b6aeca1b742ef8d5edd3b
Manish Goregaokar
Boris Zbarsky
Sebastian Hengst
Wes Kocher
Xidorn Quan
Yoshi Huang
Kartikaya Gupta
KuoE0
Emilio Cobos Álvarez
Carsten "Tomcat" Book
J. Ryan Stinnett
Ya-Chieh Wu
Hiroyuki Ikezoe
Lee Salzman
Tooru Fujisawa
Nazım Can Altınova
Jonathan Kew
Jonathan Watt
Jeremy Chen
Cameron McCormack
Bobby Holley