Don't send duplicate DOM 'scroll' event due to sub-pixel scrolling

RESOLVED DUPLICATE of bug 1230176

Status

()

Firefox for Android
Toolbar
P3
normal
RESOLVED DUPLICATE of bug 1230176
a year ago
a year ago

People

(Reporter: snorp, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox54 affected)

Details

Right now on a high-DPI screen it's possible to get duplicate 'scroll' events (i.e., the same pageY) if you scroll slowly. I know we've brought this up before, but it appears to be one of the reasons that fixed-position navbars have problems in Fennec. They often do a "if (curPageY <= lastPageY) showNavBar();" type of thing, and our current behavior causes it to constantly show/hide when you creep along. It could be argued that this is a web compat issue that we should punt to developers, but I also think we should just be reasonable. If we only scrolled by a sub-pixel in terms of page coordinates, then a scroll didn't actually occur, right?
This is very noticeable on bostonglobe.com articles, which has drawn the ire of blassey.
Isn't this the same as bug 1230176?
See Also: → bug 1230176
(.. which they fixed on their end)
Priority: -- → P3
Maybe so, but the issue appears to be back.
If it's a regression on their side, can we ping them again?
Flags: needinfo?(miket)
Mike might know people there, but I also think we're just not doing what people expect.
My main objection to making a gecko change was stated in bug 1230176 comment 6 but if our behaviour is different from other browsers here I'm fine with changing it. I just don't want to trade one set of compat problems for another.
Dropping stale needinfo. Also duping this over to bug 1230176 which was reopened.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(miket)
Resolution: --- → DUPLICATE
Duplicate of bug: 1230176
You need to log in before you can comment on or make changes to this bug.