536454 - Animation on 'display' property of used element makes it stay hidden

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Daniel Holbert [:dholbert]]

STEPS TO REPRODUCE:
 Load attached testcase, in a mozilla-central nightly.

EXPECTED RESULTS:
 There should be two lines of blinking text.

ACTUAL RESULTS:
 The first line (for the <use>

Comment 1

[Daniel Holbert [:dholbert]]

(Sorry, accidentally hit 'enter' while filing)

ACTUAL RESULTS:
 The first blinking line (for the <use> element) just blinks off once, and stays hidden from there on out.  It also triggers this warning:
{
WARNING: Someone passed native anonymous content directly into frame construction.  Stop doing that!: file ../../../mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6117
}

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 3

[Timothy Nikkel (:tnikkel)]

This is the same problem as bug 496011 where we get a reconstruct on a native anonymous content node except for this twist in nsCSSFrameConstructor::GetAnonymousContent

#ifdef MOZ_SVG
    // least-surprise CSS binding until we do the SVG specified
    // cascading rules for <svg:use> - bug 265894
    if (aParent &&
        aParent->NodeInfo()->Equals(nsGkAtoms::use, kNameSpaceID_SVG)) {
      content->SetFlags(NODE_IS_ANONYMOUS);
    } else
#endif
    {
      content->SetNativeAnonymous();
    }

So the node we are reconstructing isn't set as the root of a native anonymous subtree and the fix in bug 496011 doesn't fix this case.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Yep.  <use> is just pretty broken in general, imo.

Comment 5

[Robert Longson [:longsonr]]

Both seem to blink off and not come back now. Not sure when that second text animation regressed.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Robert Longson [:longsonr] from comment #5)

Both seem to blink off and not come back now. Not sure when that second text animation regressed.

Behavior has changed several times here, actually.

• Nightly 2009-12-31: first line blinks away & stays missing, second line blinks. (as described in comment 1)
• Nightly 2010-12-31: first line is visible (not blinking), second line is missing entirely.
• Nightly 2011-12-31: first line is visible (not blinking), second line blinks.
• Nightly 2017-12-31: (same as above)
• Nightly 2018-07-01: first line is visible (not blinking), second line blinks away & stays missing.
• Nightly 2018-12-31: first line blinks away & stays missing, second line blinks away & stays missing.
• Nightly 2024-10-17: (same as above)

So I think our behavior was unchanged from the end of 2011 through the end of 2017, and then there were two regressions in 2018, and our behavior's been unchanged since then.

I'll try to get a regression-range for the 2018 behavior-changes.

Comment 7

[Daniel Holbert [:dholbert]]

2018 regression #1:
Last good revision: (2018-05-04): first line is visible (not blinking), second line blinks.
First bad revision: (2018-05-05): first line is visible (not blinking), second line blinks away & stays missing.
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5207b1392b11db534550a5eb801302e6dbb58f95&tochange=9a2eac450781b026b42c44ca8f0f92bb0846b6e2

--> Probably bug 1458814

2018 regression #2:
Last good revision: (2018-07-19) first line is visible (not blinking), second line blinks away & stays missing.
First bad revision: (2018-07-20) first line blinks away & stays missing, second line blinks away & stays missing.
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=690cb3015db6645b335ac4835a50073cb6a3e23c&tochange=6eec814dea789707d04f42bbb01097d44532e2a9

--> Probably bug 1450250

(Though this behavior-change -- "2018 regression #2" -- was arguably an improvement, since it made the <use> clone scenario (the first line) match the rendering of a non-use-clone scenario (the second line) instead of being inexplicably different.)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (delayed the animation begin a bit, so you can see the initial state)

Comment 9

[Daniel Holbert [:dholbert]]

Interop-wise: current Chrome, WebKit (epiphany) and Firefox all agree on the two testcases here - the text disappears and doesn't ever come back.

This is easiest to see with my just-attached testcase 2, since the delayed-animation-start means you can reliably see the text paint when the page loads. (Whereas testcase 1 -- with no animation-delay -- only paints the text very-briefly in Chrome, and only if you get lucky. And it never seems to paint the text in WebKit. I think that's just due to how they schedule the first paint vs. the start of the animation.)

Comment 10

[Daniel Holbert [:dholbert]]

So: this bug was originally about SMIL-animations of display in a <use> clone causing that clone to stay hidden; but nowadays this happens regardless of whether we're dealing with <use> or not.

Additionally: I no longer get the warning-spam mentioned in comment 1 and the bug title, so let's remove that from the bug title.

Additionally, this actually is only a problem if there's no from state in the animation. I'll attach another testcase to demonstrate.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: making text blink via various animations with 5 repeats

Here's a testcase to poke at this a bit more. I think the expected-result here is for all of the lines to blink in the same way (for 5 iterations).

In Firefox, nearly all of the lines blink the same, except for one which stays hidden during all of the repeats -- that line is: Blinking by animating 'display' with 'to'

But we can successfully animate display with from/to and with values as shown here.

Comment 12

[Daniel Holbert [:dholbert]]

testcase 3 is "good" (all lines blink the same) until "2018 regression #1", i.e. it regressed due to bug 1458814.

I'll spin off a new bug to cover that, which might (?) really be the only form of brokenness that remains here.

Comment 13

[Daniel Holbert [:dholbert]]

All three testcases give expected-results in a local build with bug 1925324's patch.

• testcase 1 and 2 show two lines of blinking text.
• testcase 3 has all of its lines blinking consistently, at the same frequency.

So once bug 1925324's fix merges to central, we can consider this FIXED, mostly by bug 1450250 (which fixed the <use>-specific specialness here) and by bug 1925324 (which is fixing a regression from bug 1458814 that prevented us from landing on the fully-correct outcome when bug 1450250 landed).

Comment 14

[Daniel Holbert [:dholbert]]

--> Closing as FIXED by bug 1450250 and bug 1925324