Spinning off this bug for the additional-test-requests that I made in https://phabricator.services.mozilla.com/D173833 . Ideally we should add these tests before turning on the `discard` element by default for release users (beyond Nightly). I'll copypaste my notes about requested tests form that above-linked phab page, for convenience, with minor edits. (Sorry for the 1,2,A,B,C... numbering scheme.) --- I'm curious about what happens if there's JS with a reference to the removed elements (the <discard> element and/or its target). Presumably that JS can just add the element back after it's been removed, right? Could you add a test to check that that works? in particular, I would expect: (1) the removed element renders again if it's added back to the DOM via JS (2) and the discard element can fire again if it's added back to the DOM (and probably *will* immediately fire again, since we're already past its begin time) Also, on this "what happens if JS adds the element back" -- presumably the tree structure of the removed element remains intact, i.e. if you add it back to the DOM, then its children will get added back as well. And so, if the discard element were a child, then the resurrected element will still have that discard element as a child when you add it back; and it'll get insta-removed again, perhaps. :) (Not sure that specific thing needs testing, but I imagine it's a footgun that you might run into accidentally when poking at tests in this sort of scenario, so I wanted to mention it as something to think about at least.) Other scenarios worth testing: (A) What happens if you have two <discard> elements that fire at the same time that are both targeting the same element (by ID)? (presumably that element and both discards should be removed, and nothing should explode) (B) Same as (A), but now there's a second element later in the DOM that has the same ID. (Presumably that second element should not be removed; both of the discards should target the first element at the same instant.) (C) Same as (B), but now the two discard elements fire at slightly different times. What happens now? Does the discard-that-fires-first target the first element, and the discard-that-fires-second targets the second element? [That'd be my guess...] Does anything happen differently if we advance the timeline in one large jump, vs. if we advance it more slowly and sample one element first and then the other one? [ Depending on how we batch stuff up, I could imagine that a large jump might make us mistakenly remove just the first element if we service both discard elements in a single sample...] (D) Can you have a discard element that targets ~an animation element~ another discard element? [I think so] e.g. <rect><discard begin="5s"><discard begin="1s"> would result in both discard elements disappearing and the rect sticking around, I imagine, right? Also worth testing what would happen that same scenario but with the begin times both being the same, or swapped (the innermost one being higher). I'm guessing [but not sure] things might also work out differently depending on whether we get an animation sample between the start times vs. if we seek directly to after both start times; the node-removal means that we end up getting some statefulness depending on where our samples fall on the timeline. (E) We should test that xlink:href doesn't work on discard -- e.g. in the following sort of setup... ``` <rect id="foo"/> <rect> <discard xlink:href="#foo" begin="2s"/> </rect> ``` ...we should test that the discard element removes its parent, and that #foo does not get removed. (F) what if the <discard> element targets the root <svg> element itself (it's sorta interesting to be removing the element that sorta owns all the animation machinery, in the middle of an animation sample, from a "hopefully stuff doesn't explode" perspective). (G) what happens if the <discard> element targets something that doesn't directly render, like a SVG <view> or <filter> or a paint server. (Hopefully the rendering just updates such that it looks like that thing was never there in the first place.) (H) what happens if the <discard> element targets an even-more-nonrendering element like <link rel="stylesheet"> or <style> or even script? Can you use <discard> to delete special elements like those? (I imagine you can, and things should Just Work as if you removed them via JS... At least for the style-based ones, they should be ~easy to test -- just set up a scenario with a stylesheet that makes everything red, so that things only look good only after discard yanks that link and/or style element from the DOM.
Bug 1941039 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Spinning off this bug for the additional-test-requests that I made in https://phabricator.services.mozilla.com/D173833 . Ideally we should add these tests before turning on the `discard` element by default for release users (beyond Nightly). I'll copypaste my notes about requested tests from that above-linked phab page, for convenience, with minor edits. (Sorry for the 1,2,A,B,C... numbering scheme.) --- I'm curious about what happens if there's JS with a reference to the removed elements (the <discard> element and/or its target). Presumably that JS can just add the element back after it's been removed, right? Could you add a test to check that that works? in particular, I would expect: (1) the removed element renders again if it's added back to the DOM via JS (2) and the discard element can fire again if it's added back to the DOM (and probably *will* immediately fire again, since we're already past its begin time) Also, on this "what happens if JS adds the element back" -- presumably the tree structure of the removed element remains intact, i.e. if you add it back to the DOM, then its children will get added back as well. And so, if the discard element were a child, then the resurrected element will still have that discard element as a child when you add it back; and it'll get insta-removed again, perhaps. :) (Not sure that specific thing needs testing, but I imagine it's a footgun that you might run into accidentally when poking at tests in this sort of scenario, so I wanted to mention it as something to think about at least.) Other scenarios worth testing: (A) What happens if you have two <discard> elements that fire at the same time that are both targeting the same element (by ID)? (presumably that element and both discards should be removed, and nothing should explode) (B) Same as (A), but now there's a second element later in the DOM that has the same ID. (Presumably that second element should not be removed; both of the discards should target the first element at the same instant.) (C) Same as (B), but now the two discard elements fire at slightly different times. What happens now? Does the discard-that-fires-first target the first element, and the discard-that-fires-second targets the second element? [That'd be my guess...] Does anything happen differently if we advance the timeline in one large jump, vs. if we advance it more slowly and sample one element first and then the other one? [ Depending on how we batch stuff up, I could imagine that a large jump might make us mistakenly remove just the first element if we service both discard elements in a single sample...] (D) Can you have a discard element that targets ~an animation element~ another discard element? [I think so] e.g. <rect><discard begin="5s"><discard begin="1s"> would result in both discard elements disappearing and the rect sticking around, I imagine, right? Also worth testing what would happen that same scenario but with the begin times both being the same, or swapped (the innermost one being higher). I'm guessing [but not sure] things might also work out differently depending on whether we get an animation sample between the start times vs. if we seek directly to after both start times; the node-removal means that we end up getting some statefulness depending on where our samples fall on the timeline. (E) We should test that xlink:href doesn't work on discard -- e.g. in the following sort of setup... ``` <rect id="foo"/> <rect> <discard xlink:href="#foo" begin="2s"/> </rect> ``` ...we should test that the discard element removes its parent, and that #foo does not get removed. (F) what if the <discard> element targets the root <svg> element itself (it's sorta interesting to be removing the element that sorta owns all the animation machinery, in the middle of an animation sample, from a "hopefully stuff doesn't explode" perspective). (G) what happens if the <discard> element targets something that doesn't directly render, like a SVG <view> or <filter> or a paint server. (Hopefully the rendering just updates such that it looks like that thing was never there in the first place.) (H) what happens if the <discard> element targets an even-more-nonrendering element like <link rel="stylesheet"> or <style> or even script? Can you use <discard> to delete special elements like those? (I imagine you can, and things should Just Work as if you removed them via JS... At least for the style-based ones, they should be ~easy to test -- just set up a scenario with a stylesheet that makes everything red, so that things only look good only after discard yanks that link and/or style element from the DOM.
Spinning off this bug for the additional-test-requests that I made in https://phabricator.services.mozilla.com/D173833 . Ideally we should add these tests before turning on the `discard` element by default for release users (beyond Nightly). I'll copypaste my notes about requested tests from that above-linked phab page, for convenience, with minor edits. (Sorry for the 1,2,A,B,C... numbering scheme.) --- I'm curious about what happens if there's JS with a reference to the removed elements (the <discard> element and/or its target). Presumably that JS can just add the element back after it's been removed, right? Could you add a test to check that that works? in particular, I would expect: (1) the removed element renders again if it's added back to the DOM via JS (2) and the discard element can fire again if it's added back to the DOM (and probably *will* immediately fire again, since we're already past its begin time) Also, on this "what happens if JS adds the element back" -- presumably the tree structure of the removed element remains intact, i.e. if you add it back to the DOM, then its children will get added back as well. And so, if the discard element were a child, then the resurrected element will still have that discard element as a child when you add it back; and it'll get insta-removed again, perhaps. :) (Not sure that specific thing needs testing, but I imagine it's a footgun that you might run into accidentally when poking at tests in this sort of scenario, so I wanted to mention it as something to think about at least.) Other scenarios worth testing: (A) What happens if you have two <discard> elements that fire at the same time that are both targeting the same element (by ID)? (presumably that element and both discards should be removed, and nothing should explode) (B) Same as (A), but now there's a second element later in the DOM that has the same ID. (Presumably that second element should not be removed; both of the discards should target the first element at the same instant.) (C) Same as (B), but now the two discard elements fire at slightly different times. What happens now? Does the discard-that-fires-first target the first element, and the discard-that-fires-second targets the second element? [That'd be my guess...] Does anything happen differently if we advance the timeline in one large jump, vs. if we advance it more slowly and sample one element first and then the other one? [ Depending on how we batch stuff up, I could imagine that a large jump might make us mistakenly remove just the first element if we service both discard elements in a single sample...] (D) Can you have a discard element that targets ~an animation element~ another discard element? [I think so] e.g. perhaps `<rect><discard begin="5s"><discard begin="1s">` would result in both discard elements disappearing, but the `<rect>` sticking around, I imagine, right? Also worth testing what would happen that same scenario but with the begin times both being the same, or swapped (the innermost one being higher). I'm guessing [but not sure] things might also work out differently depending on whether we get an animation sample between the start times vs. if we seek directly to after both start times; the node-removal means that we end up getting some statefulness depending on where our samples fall on the timeline. (E) We should test that xlink:href doesn't work on discard -- e.g. in the following sort of setup... ``` <rect id="foo"/> <rect> <discard xlink:href="#foo" begin="2s"/> </rect> ``` ...we should test that the discard element removes its parent, and that #foo does not get removed. (F) what if the <discard> element targets the root <svg> element itself (it's sorta interesting to be removing the element that sorta owns all the animation machinery, in the middle of an animation sample, from a "hopefully stuff doesn't explode" perspective). (G) what happens if the <discard> element targets something that doesn't directly render, like a SVG <view> or <filter> or a paint server. (Hopefully the rendering just updates such that it looks like that thing was never there in the first place.) (H) what happens if the <discard> element targets an even-more-nonrendering element like <link rel="stylesheet"> or <style> or even script? Can you use <discard> to delete special elements like those? (I imagine you can, and things should Just Work as if you removed them via JS... At least for the style-based ones, they should be ~easy to test -- just set up a scenario with a stylesheet that makes everything red, so that things only look good only after discard yanks that link and/or style element from the DOM.
Spinning off this bug for the additional-test-requests that I made in https://phabricator.services.mozilla.com/D173833 . Ideally we should add these tests before turning on the `discard` element by default for release users (beyond Nightly). I'll copypaste my notes about requested tests from that above-linked phab page, for convenience, with minor edits. (Sorry for the 1,2,A,B,C... numbering scheme.) --- I'm curious about what happens if there's JS with a reference to the removed elements (the <discard> element and/or its target). Presumably that JS can just add the element back after it's been removed, right? Could you add a test to check that that works? in particular, I would expect: (1) the removed element renders again if it's added back to the DOM via JS (2) and the discard element can fire again if it's added back to the DOM (and probably *will* immediately fire again, since we're already past its begin time) Also, on this "what happens if JS adds the element back" -- presumably the tree structure of the removed element remains intact, i.e. if you add it back to the DOM, then its children will get added back as well. And so, if the discard element were a child, then the resurrected element will still have that discard element as a child when you add it back; and it'll get insta-removed again, perhaps. :) (Not sure that specific thing needs testing, but I imagine it's a footgun that you might run into accidentally when poking at tests in this sort of scenario, so I wanted to mention it as something to think about at least.) Other scenarios worth testing: (A) What happens if you have two <discard> elements that fire at the same time that are both targeting the same element (by ID)? (presumably that element and both discards should be removed, and nothing should explode) (B) Same as (A), but now there's a second element later in the DOM that has the same ID. (Presumably that second element should not be removed; both of the discards should target the first element at the same instant.) (C) Same as (B), but now the two discard elements fire at slightly different times. What happens now? Does the discard-that-fires-first target the first element, and the discard-that-fires-second targets the second element? [That'd be my guess...] Does anything happen differently if we advance the timeline in one large jump, vs. if we advance it more slowly and sample one element first and then the other one? [ Depending on how we batch stuff up, I could imagine that a large jump might make us mistakenly remove just the first element if we service both discard elements in a single sample...] (D) Can you have a discard element that targets ~an animation element~ another discard element (and remove it before the targeted discard gets a chance to take action)? e.g. perhaps `<rect><discard begin="5s"><discard begin="1s">` would result in both discard elements disappearing (from the innermost one firing), but the `<rect>` sticking around, I imagine, right? Also worth testing what would happen that same scenario but with the begin times both being the same, or swapped (the innermost one being higher). I'm guessing [but not sure] things might also work out differently depending on whether we get an animation sample between the start times vs. if we seek directly to after both start times; the node-removal means that we end up getting some statefulness depending on where our samples fall on the timeline. (E) We should test that xlink:href doesn't work on discard -- e.g. in the following sort of setup... ``` <rect id="foo"/> <rect> <discard xlink:href="#foo" begin="2s"/> </rect> ``` ...we should test that the discard element removes its parent, and that #foo does not get removed. (F) what if the <discard> element targets the root <svg> element itself (it's sorta interesting to be removing the element that sorta owns all the animation machinery, in the middle of an animation sample, from a "hopefully stuff doesn't explode" perspective). (G) what happens if the <discard> element targets something that doesn't directly render, like a SVG <view> or <filter> or a paint server. (Hopefully the rendering just updates such that it looks like that thing was never there in the first place.) (H) what happens if the <discard> element targets an even-more-nonrendering element like <link rel="stylesheet"> or <style> or even script? Can you use <discard> to delete special elements like those? (I imagine you can, and things should Just Work as if you removed them via JS... At least for the style-based ones, they should be ~easy to test -- just set up a scenario with a stylesheet that makes everything red, so that things only look good only after discard yanks that link and/or style element from the DOM.