Closed
Bug 1448830
Opened 7 years ago
Closed 3 years ago
Scrolling through "Related Images" on Bing.com has a really small progress.
Categories
(Web Compatibility :: Site Reports, defect, P1)
Web Compatibility
Site Reports
Tracking
(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.
Comment 1•7 years ago
|
||
Hm, this seems to scroll fine for me on macOS 10.13.3 with 60.0b4. I'll try on different machines tomorrow.
Reporter | ||
Comment 2•7 years ago
|
||
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.
Comment 3•7 years ago
|
||
I can reproduce the slow scrolling issue. It indeed only happens with mousewheel, and it does not happen in Chromium.
Comment 4•7 years ago
|
||
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.
Comment 5•7 years ago
|
||
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
Updated•7 years ago
|
platform-rel: --- → ?
Whiteboard: [platform-rel-microsoft][needsdiagnosis]
Comment 6•7 years ago
|
||
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
Comment 7•7 years ago
|
||
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)
Comment 8•7 years ago
|
||
Yes, I can reproduce. This smells like another case of devs just assuming that WheelEvent.deltaMode is in pixels. I'll confirm.
Comment 9•7 years ago
|
||
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)
Comment 10•7 years ago
|
||
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]
Comment 11•7 years ago
|
||
Reaching out via partner mailing list.
Flags: needinfo?(astevenson)
Whiteboard: [platform-rel-microsoft][needscontact] → [platform-rel-microsoft][sitewait]
Assignee | ||
Updated•6 years ago
|
Product: Tech Evangelism → Web Compatibility
Comment 12•6 years ago
|
||
See bug 1547409. Moving webcompat whiteboard tags to keywords.
Keywords: webcompat:site-wait
Comment 13•3 years ago
|
||
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)
Reporter | ||
Comment 14•3 years ago
|
||
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)
Comment 15•3 years ago
|
||
Thank you, Oana for confirming. Closing this as FIXED.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•