Bugzilla

(In reply to Maria Berlinger [:maria_berlinger], Release Desktop QA from comment #5)
> I've followed the provided steps [testing Firefox with Chrome UA string] and I wasn't able to reproduce it.

Thanks! FWIW, I just tried the opposite experiment (testing **Chrome** with a Firefox UA string), and I **can** reproduce the water-disappearing bug under those conditions.

So it seems quite clear that the site is sending different content depending on which browser it thinks you're using (via UA sniffing), and it's sending broken content if it thinks you're using Firefox vs. working content if it thinks you're using Chrome. :-/

(In reply to Alice0775 White from comment #4)
> There are 2 regressions at least.

Thank you. Notably, both of the changes that you identified here are cases where we made a change that happened to align with Chrome's behavior. So both "regressions" were in fact interop improvements.

Perhaps the site (or one of its libraries) had a Firefox-specific codepath that assumes our old (non-interoperable) behavior, or something?

In any case: given all the observations here (particularly the UA string observation): this seems to be a WebCompat bug, due to the site sending us different content from Chrome. (And we seem to behave interoperably on the content that they send us and on the content that they send Chrome.)

(In reply to Maria Berlinger [:maria_berlinger], Release Desktop QA from comment #5)
> I've followed the provided steps [testing Firefox with Chrome UA string] and I wasn't able to reproduce it.

Thanks! FWIW, I just tried the opposite experiment (testing **Chrome** with a Firefox UA string), and I **can** reproduce the water-disappearing bug under those conditions.

So it seems quite clear that the site is sending different content depending on which browser it thinks you're using (via UA sniffing), and it's sending broken content if it thinks you're using Firefox vs. working content if it thinks you're using Chrome. :-/

(In reply to Alice0775 White from comment #4)
> There are 2 regressions at least.

Thank you. Notably, both of the changes that you identified here are cases where we made a change that happened to align with Chrome's behavior. So both "regressions" were in fact interop improvements.

Perhaps the site (or one of its libraries) had a Firefox-specific codepath that assumes our old (less-interoperable) behavior, or something?

In any case: given all the observations here (particularly the UA string observation): this seems to be a WebCompat bug, due to the site sending us different content from Chrome. (And we seem to behave interoperably on the content that they send us and on the content that they send Chrome.)