Marco Castelluccio [:marco] Reporter
	Description • 8 years ago

It works in Firefox 49.0.2, it doesn't work in Firefox 53.
I'm not sure when the regression was introduced.

	Marco Castelluccio [:marco] Reporter
	Comment 1 • 8 years ago

Actually, it doesn't work in Firefox 49.0.2 (or 50) either.

STR:
1) Open http://consumaregiusto.it/
2) Scrolling works
2) Ctrl+F, type something
3) Close the find bar
4) Scrolling doesn't work

	Xidorn Quan [:xidorn] UTC+11
	Comment 2 • 8 years ago

I cannot reproduce this issue with Firefox 50 on macOS.

If this is a regression, could you probably use mozregression to find the regression range?

	Marco Castelluccio [:marco] Reporter
	Comment 3 • 8 years ago

37:30.78 INFO: Last good revision: 977d78a8dd78afbc0153d37fd9887c3a200dce6a
37:30.78 INFO: First bad revision: 66e07ef46853709e3fa91e7c9ad9fe6abf0d5f06
37:30.78 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=977d78a8dd78afbc0153d37fd9887c3a200dce6a&tochange=66e07ef46853709e3fa91e7c9ad9fe6abf0d5f06

37:34.45 INFO: Looks like the following bug has the changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1239861

I'm not sure if the range is correct or if the bug is not always reproducible.

	Alice0775 White
	Comment 4 • 8 years ago

I got a different regression window on Windows10.
Regression window with STR comment#1:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a5472dd5fafded59961360da30e166e0c1bf27fd&tochange=5c6accc2386666ec9361024db8f6db8779ea788e

Suspect: Bug 1239799

And I can also reproduce the problem on Edge Windows10 with STR comment#1.

	Daniel Holbert [:dholbert]
	Comment 5 • 8 years ago

I can reproduce in *much* older builds (before the regression range in comment 4) -- e.g. I can reproduce using a random Firefox 15 Nightly build from 2012, launched using this command:

  mozregression --launch 2012-06-01 -a "http://consumaregiusto.it/"

I can also reproduce this in Alice0775's purportedly last-good build from comment 4 (a5472dd5fafded59961360da30e166e0c1bf27fd) *if* I disable layout.css.prefixes.webkit.

SO: it seems this never really worked, except it briefly worked for a period of time on Nightly when we had partial webkit prefix support. (The site only works correctly if we support a specific subset of webkit-prefixed features but not "@media (-webkit-transform-3d)".)

So, this is not really a Firefox regression, and only sort of a regression from bug 1239799.  This is almost certainly a Tech Evang issue, especially given that it's reproducible in Edge.  Mike, perhaps you can get to the bottom of it?

	Adam Stevenson [:adamopenweb]
	Comment 6 • 8 years ago

This doesn't reproduce for me in OSX, but using Windows 10 with Firefox 50 & 53 it does.

	Eric Tsai (no more review request accepted)
	Comment 7 • 8 years ago

I can reproduce this on Firefox 50 & 53 on ubuntu too.

	Mike Taylor [:miketaylr]
	Comment 8 • 8 years ago

On an actual windows machine I see the following:

Same as reported by Marco in Fx (just opening find in page/ctrl+f is enough)
Can't scroll in Chrome if I open the search box (same as Firefox)
Can't scroll *at all* in Edge via trackpad (mouse works)

This site's custom scrolling is super busted (and probably developed/tested only on OSX).

	Mike Taylor [:miketaylr]
	Comment 9 • 8 years ago

(And on OSX in Chrome, find just doesn't work, it won't navigate to the found word -- http://www.giphy.com/gifs/l3vR6qiHNWZhpc9iM)

	Mike Taylor [:miketaylr]
	Comment 10 • 8 years ago

OK, probably not worth digging into more -- this jQuery NiceScroll plugin they used is full of bugs related to cmd+f/search:

"https://github.com/inuyaksa/jquery.nicescroll/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20search"

They're using v3.5.4 and the current release is v3.6.8, it's possible some things were fixed in the newer version. The repo hasn't been updated in 9 months, so possibly it's unmaintained (w/ 229 open issues...).

*Possibly* this PR fixes it: https://github.com/inuyaksa/jquery.nicescroll/pull/600/files

Let's set to "needscontact", though I don't have high hopes for asking people to apply random patches to minified 3rd party scripts. :/

	Mike Taylor [:miketaylr]
	Comment 11 • 8 years ago

(left out some other notes)

The problem is possibly in the isScrollable method that gets checked in its onmousewheel handler. I suspect that some kind of expected/actual clientHeight mismatch when the cmd+f bar is open somehow screws up the scripts expectations. Maybe?

	Mike Taylor [:miketaylr]
	Comment 12 • 8 years ago

(linking Bug 407817, because that's a side effect of using a lib like Nice Scroll and cmd+f search)

	Karl Dubost💡 :karlcow
	Comment 13 • 8 years ago

mike,

As you said it might be hard to get them to apply patches. One solution is to remove it entirely.
Do you know of any other third party equivalent libs which would be good for them to explore?

It seems that "jQuery NiceScroll plugin" is for customizing scrollbars.
http://ourcodeworld.com/articles/read/179/top-7-best-custom-browser-scrollbar-javascript-and-jquery-plugins

	Mike Taylor [:miketaylr]
	Comment 14 • 8 years ago

In a perfect world, they just remove the custom scrollbar design entirely -- it creates more problems than it solves IMO. If they really want some special designs, they can use CSS to get custom scrollbars for browsers that understand the -webkit-scrollbar stuff: https://css-tricks.com/custom-scrollbars-in-webkit/. 

(I'm not aware of any nice custom scrollbar plugins, sorry)

	Adam Stevenson [:adamopenweb]
	Comment 15 • 6 years ago

Issue still exists, reaching out to info@consumaregiusto.it