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

Status: RESOLVED DUPLICATE of bug 1230176

(Firefox for Android Graveyard :: Toolbar, defect, P3)

Description

[James Willcox (:snorp) ([e-mail]) (he/him)]

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?

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

This is very noticeable on bostonglobe.com articles, which has drawn the ire of blassey.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Isn't this the same as bug 1230176?

Comment 3

[Kartikaya Gupta (email:[e-mail])]

(.. which they fixed on their end)

Comment 4

[James Willcox (:snorp) ([e-mail]) (he/him)]

Maybe so, but the issue appears to be back.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

If it's a regression on their side, can we ping them again?

Comment 6

[James Willcox (:snorp) ([e-mail]) (he/him)]

Mike might know people there, but I also think we're just not doing what people expect.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Dropping stale needinfo. Also duping this over to bug 1230176 which was reopened.