Closed Bug 1448830 Opened 6 years ago Closed 2 years ago

Scrolling through "Related Images" on Bing.com has a really small progress.

Categories

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

Product:
Web Compatibility
Component:
Site Reports
Type:
defect

Tracking

(platform-rel ?, firefox-esr52 affected, firefox59 affected, firefox60 affected, firefox61 affected)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
platform-rel --- ?
firefox-esr52 --- affected
firefox59 --- affected
firefox60 --- affected
firefox61 --- affected

People

(Reporter: obotisan, Unassigned)

References

Details

(Keywords: webcompat:site-wait, Whiteboard: [platform-rel-microsoft][sitewait]) 

[Affected versions]:
- Esr 52.7.3
- Firefox 59.0.1
- Beta 60.0b6
- Nightly 61.0a1

[Affected platforms]:
- Windows 10 x64
- macOS 10.12, macOS 10.13
- Ubuntu 16.04

[Steps to reproduce]:
1. https://www.bing.com/images/
2. Perform a search
3. Click on an image
4. Hover over the image and click on the magnifying glass / "Search within this image" button
5. Scroll through the results. 

[Expected result]:
- The scroll goes at a normal speed.

[Actual result]:
- The scroll has a slower speed. It doesn't seem to lag. The action is performed smoothly, it's just that it seems to navigate a short distance. 

[Regression range]:
- I don't think this is a regression. I can reproduce the issue even on Nightly 20.0a1.
Hm, this seems to scroll fine for me on macOS 10.13.3 with 60.0b4. I'll try on different machines tomorrow.
I forgot to mention, that this happens only when the wheel on the mouse is used. 

It works perfectly when using the arrows/Home/End/Page UP/Page Down from the keyboard and the autoscroll.
I can reproduce the slow scrolling issue. It indeed only happens with mousewheel, and it does not happen in Chromium.
Pretty sure this is due to the page intercepting wheel events and doing its own scrolling. Most likely they are doing pixel scrolling instead of line scrolling or something like that.
There's no easy way for me to test changes to the JS. The behaviour in Chrome is also kind of janky/jarring, and behaves a lot better when I remove the wheel event listener that's attached to the iframe <html> element. Moving this to TE, I'm pretty sure this needs to be fixed by Bing.
Component: Panning and Zooming → Desktop
Product: Core → Tech Evangelism
platform-rel: --- → ?
Whiteboard: [platform-rel-microsoft][needsdiagnosis]
Hey Dennis, can you take a look at the scroll code mentioned in Comment #4 when you get a chance? Thanks.
Flags: needinfo?(dschubert)
Priority: -- → P1
Huh, I'm really confused. I tested in both Release and Nightly here from Germany, and I could not reproduce at all. Even more interesting, when following the exact STR, my body does not include an iFrame, contrary to what has been pointed out in comment 5. I double checked with `document.querySelector("iframe")` just to make sure, but there is no iFrame in the body at all.

The <html> on that page has a scroll listener, but only one, and it is responsible for showing and hiding the "All saves" button. That, by itself, does not cause any performance issues for me. I can't find any other scroll handlers, and I also do not notice any difference in the scroll wheel behavior between that site and other websites. :/

If I don't follow the STR exactly, but use the "Find more images like this" button on the result overview page instead, I see an iFrame, and its <html> element has three scroll handlers attached to it, but none of them is doing anything inherently bad. One of them seems to some kind of telemetry stuff, one of them, again, is responsible for showing the "All saves" button (although it's not even visible on that site).

The third one could potentially be an issue, as it sets height/width attributes on div#detail_img, which is the large picture in the top. The handler is responsible for shrinking the top image unless it's small enough and gets scrolled out of the view. It's not slowing down for me, but I took a profile and saw that we're spending quite a bit of time re-rendering the image as it gets smaller and smaller (which is to be expected), but it does not cause any frame drops for me, and our rerender times are comparable to Chromes.

In all cases, I couldn't find any event handlers for the wheel event, only scroll handlers, which also fires for using my trackpad. If the scroll wheel behaves differently, that indeed sounds like a captured wheel event, but I'm not seeing anything. :/

Tom, I suspect this might be geography-based A/B testing. Do you mind cross-checking if you can reproduce the issues mentioned in comment 0?
Flags: needinfo?(dschubert) → needinfo?(twisniewski)
Yes, I can reproduce. This smells like another case of devs just assuming that WheelEvent.deltaMode is in pixels. I'll confirm.
Indeed, right in their HTML markup they have this handler:

    this.handleWheel = function(n) {
      r.props.isPageActive && (r.setScroll(n.deltaY), r.switchOrLoadInsights(r.props), r.handleHideRightRailInsights(n.deltaY,"Scroll"))
    };

They are just assuming deltaY is in pixels. They should really do something like I suggest for https://webcompat.com/issues/15071 and adjust the value based on the event's deltaMode. We're investigating changing Firefox's default to pixels in bug 1392460, but even if we fix that, they will still have breakage elsewhere (for instance, Chrome on Windows uses pages instead of pixels sometimes, based on user preferences).
Flags: needinfo?(twisniewski)
Thanks Dennis and Tom.

Adam, can we let Microsoft know about this issue? See the recommended fix in the webcompat bug Tom points to in Comment 9.
Flags: needinfo?(astevenson)
Whiteboard: [platform-rel-microsoft][needsdiagnosis] → [platform-rel-microsoft][needscontact]
Reaching out via partner mailing list.
Flags: needinfo?(astevenson)
Whiteboard: [platform-rel-microsoft][needscontact] → [platform-rel-microsoft][sitewait]
Product: Tech Evangelism → Web Compatibility

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Keywords: webcompat:site-wait
See Also: → 1629101

The issue seems to be fixed as it works for me. Following the steps to reproduce, the newly generated list of results can be scrolled with no issues encountered (performance issues, lag, the same number of search results, same list length).

Oana, is the issue still reproducible on your side?

Tested with:

Browser / Version: Firefox Nightly 101.0a1 (2022-04-10) (64-bit) / Chrome Version 100.0.4896.75 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Flags: needinfo?(oana.botisan)

I am not able to reproduce this issue anymore. I think it's safe to close it as fixed. Thank you.

Flags: needinfo?(oana.botisan)

Thank you, Oana for confirming. Closing this as FIXED.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.