Looks like we handle this unexpected condition safely -- we return null, which is the same behavior as if the filter references a nonexistent element: https://searchfox.org/mozilla-central/rev/c7e8bc4996f979e5876b33afae3de3b1ab4f3ae1/layout/svg/nsSVGFilterInstance.cpp#140-143 So, this is non-scary (--> P3) but it probably indicates that we're doing something wrong (unless the semantics of URL nullness changed at some point). I'm guessing this may have been fallout from bug 1552878 which I think changed filter parsing. (Or perhaps this was possible further back, and we only just stumbled on a testcase that triggers it.)
Bug 1569648 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Looks like we handle this unexpected condition safely -- we return null, which is the same behavior as if the filter references a nonexistent element: https://searchfox.org/mozilla-central/rev/c7e8bc4996f979e5876b33afae3de3b1ab4f3ae1/layout/svg/nsSVGFilterInstance.cpp#140-143 So, this is non-scary (--> P3) but it probably indicates that we're doing something wrong (unless the semantics of URL nullness changed at some point). I'm guessing this may have been fallout from bug 1552878 and/or bug 1552708 which I think changed filter/URI parsing. (Or perhaps this was possible further back, and we only just stumbled on a testcase that triggers it.)