1665047 - Past editions on https://www.miragefestival.com/ shows broken animations

Status: RESOLVED DUPLICATE of bug 1787623

(Web Compatibility :: Site Reports, defect, P3)

Description

[Rares Doghi, Desktop QA]

Attachment: Mirrage.png

[Affected platforms]:
Platforms: ALl

Steps :

1. Launch the Firefox browser and reach https://www.miragefestival.com/archive
2. Hover the mouse pointer on different editions from the list.

Expected Results :
The animations from the past editions should change from black and white to color when hovered over

Actual Results :
The animation of the past editions thumbnails go blank when hovered over.

Comment 1

[Rares Doghi, Desktop QA]

I think this is a Web Compatibility issue and it should have an S3 severity.

Comment 2

[Jim Mathies [:jimm]]

Can be found on https://www.miragefestival.com/ down at the bottom. Looks like a background image vs something like canvas. I can reproduce on Win10 / Nightly.

Comment 3

[Andrew Osmond [:aosmond] (he/him)]

It doesn't appear this is a regression. It was always broken with basic compositor.

Comment 4

[Jim Blandy :jimb]

Requesting triage from WebCompat team.

Comment 5

[Ksenia Berezina [:ksenia]]

Attachment: 1665047.html

I've created a reduced test case. The site is using a data: URL svg filter which has https intstead of http in the xml namespace.
So it's:
<svg xmlns="https://www.w3.org/2000/svg">
instead of:
<svg xmlns="http://www.w3.org/2000/svg">

FWIW, this looks like a typo, since they have another filter on the the same element (in the default, non hovered state) based on a similar svg and it has http in the namespace. We should contact the site to see if they can fix it.

Comment 6

[Ksenia Berezina [:ksenia]]

Attachment: 1665047.html

Comment 7

[Ksenia Berezina [:ksenia]]

When trying to open any data: URL svg with https in the namespace, neither Chrome or Firefox recognize it as an svg and only when using filter Chrome does and Firefox doesn't.

Based on this discussion: https://github.com/w3c/svgwg/issues/738 and the spec, I think Firefox is correct. Hi Daniel, wonder if you have any thoughts on this?

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Ksenia Berezina [:ksenia] from comment #7)

Hi Daniel, wonder if you have any thoughts on this?

Hi! Yeah, it's not just HTTP vs HTTPS; it looks like Chrome actually doesn't care about the xmlns attribute at all, in this testcase. I can swap in:

      filter: url("haha-this-is-not-a-filter");

...and Chrome doesn't change its rendering.

So this might just be a disagreement about how to handle invalid filter values, rather than how to handle http vs https.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a testcase with a clearly-bogus filter value.

Comment 10

[Calin Tanase (OOO until 22nd of Nov)]

I was not able to reproduce this issue on the latest Nightly. Rares, can you please take a look and give us an update?

Tested on:
Operating system: Windows 10
Browser/Version: Firefox Nightly 111.0a1 (2023-01-26) / Chrome 109.0.5414.75

Comment 11

[Rares Doghi, Desktop QA]

Hi @Calin, I can no longer reproduce this issue in our latest Release, Beta or Nightly builds, but I was able to reproduce it in our latest 102.7.0esr build. I will update the flags accordingly.

Comment 12

[Daniel Holbert [:dholbert]]

Fix range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f7567091b43ba717392db9e5f780145d9b34ec45&tochange=06480f550b00b750081427dd4b359f1dd37c8ebf

--> duplicate of bug 1787623