Open Bug 1616588 Opened 3 years ago Updated 2 months ago

Scrolling is broken on kaipoche.co

Categories

(Web Compatibility :: Desktop, defect, P5)

defect

Tracking

(firefox73 wontfix, firefox74 wontfix, firefox75 wontfix, firefox76 wontfix, firefox77 fix-optional)

Tracking Status
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- fix-optional

People

(Reporter: mberlinger, Unassigned, NeedInfo)

References

(Regression, )

Details

(Keywords: regression, webcompat:needs-contact)

Attachments

(4 files)

Attached image scroll.gif

Affected versions

  • 75.0a1 (2020-02-19)
  • 74.0b5
  • 73.0.1

Affected platforms

  • Windows 10x64
  • macOS 10.13
  • Ubuntu 18.04x64

Steps to reproduce

  1. Launch Firefox.
  2. Go to the website http://www.kaipoche.co/
  3. Scroll down until the boat crashes and then scroll up.

Expected result

  • Scrolling works properly.

Actual result

  • Scrolling on the website at some point after boat crashes makes the water disappear.

Regression range

  • This issue is not a recent regression since I was able to reproduce it on Firefox 73.0.1. I’ll come with a regression range asap.

Additional notes

  • I’ll attach a screen recording with the issue.
Attached image image.png

I can reproduce this. It's not a graphical glitch in Firefox, though -- when this happens, it's because the site has manually added background:size: 4% 0px to that element, which I think (correctly) prevents it from rendering the water.

Here's a screenshot showing that styling in devtools, when the water has disappeared.

When they remove the 0px there (as they do if I keep playing with the page and scrolling), then the water shows up again.

I haven't been able to reproduce the issue in Chrome, or in Firefox spoofing a Chrome user-agent string, so I think the site may be doing some UA-sniffing shenenigans here.

Maria, could you check my results by doing the following:
(1) View the site in responsive design mode (Ctrl+Shift+M), with "responsive" in the leftmost dropdown as the choice-of-device, and paste this into the user agent field on the right:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.17 Safari/537.36

(2) Reload the page so the user agent string can take effect
(3) Try to reproduce the bug.

I can't reproduce unless I use a Firefox user agent string, personally, which makes me think this the site doing something bad if they think we're Firefox.

Flags: needinfo?(maria.berlinger)
Regressed by: 1560198, 1305957

(In reply to Daniel Holbert [:dholbert] from comment #2)

Maria, could you check my results by doing the following:
(1) View the site in responsive design mode (Ctrl+Shift+M), with "responsive" in the leftmost dropdown as the choice-of-device, and paste this into the user agent field on the right:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.17 Safari/537.36

(2) Reload the page so the user agent string can take effect
(3) Try to reproduce the bug.

I can't reproduce unless I use a Firefox user agent string, personally, which makes me think this the site doing something bad if they think we're Firefox.

Hello,

I've followed the provided steps and I wasn't able to reproduce it.

Flags: needinfo?(maria.berlinger)

(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.)

Component: Layout: Scrolling and Overflow → Desktop
Product: Core → Web Compatibility

Webcompat, marking as fix-optional for 73/74 to remove it from our weekly regression triage queue.

Hi,

I was able to reproduce this issue on Mac 10.14 with Firefox version Nightly 77.0a1 (2020-04-28) (64-bit). Marking that flag as affected.

Priority: -- → P3
Attached file kaipoche.co.js

There's an inline script that's forking on behavior if you're Chrome, Firefox, or Safari. Let's try to get in touch with them and let them know that we aligned with Chrome here.

Actually, this was a site made by a creative agency for a 2016 festival. I don't expect much to come of outreach, but we can at least try.

Priority: P3 → P5

The page seems to have a small UI change, as the boat is not present, and the scrolling of the page is very minimal:

https://prnt.sc/d5iYTp457KoE

Reporter, can you please confirm this outcome?

Tested with:

Browser / Version: Firefox Release 100.0.2 (64-bit)/ Firefox Nightly 102.0a1 (2022-05-23) (64-bit) /FChrome Version Version 101.0.4951.67 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Flags: needinfo?(maria.berlinger)
Flags: needinfo?(maria.berlinger) → needinfo?(camelia.badau)
You need to log in before you can comment on or make changes to this bug.