>>> My Info: Win7_64, Nightly 49, 32bit, ID 20160526082509 STR_1: 1. Open attachment 8557479 [details] 2. Click on <select> to open list of options 3. Hover mouse over the vertical scrollbar, but not on the scrollbar thumb 4. Click AR: List of options teleports to new position ER: List of options should smoothly scroll to new position. References of that behavior: 1) non-e10s 2) both e10s and non-e10s if in Step 4 I rotate mouse wheel (My mouse wheel is configured to "scroll by 1 screen", so I expect the same action for (2) and Step 4). 3) both e10s and non-e10s if in Step 4 I double-click or triple-click instead of just clicking 4) both e10s and non-e10s if in Step 4 I hold left mouse button and list scrolls automatically You should check regression range. This is regression from bug 1235478. Regression range: > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=978349072992b565123bcd97e0778abaa7a67256&tochange=66252157547f3f4e0b9ad9fb3b0b96d6df5938fe@ Hiroyuki Ikezoe (:hiro): It seems that this is a regresion caused by your change. Please have a look.
Component: Untriaged → Layout: Form Controls
Product: Firefox → Core
status-firefox50: --- → wontfix
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
Is the regression range correct? I can see the same behavior between today's nightly and 2016-01-01 nightly.
Regression range seems a bit fishy to me too. I would double check it before investigating further.
I tried re-bisecting this and was definitely able to reproduce the jankiness reported in this bug, but I've still had a difficult time bisecting it down to a culprit commit. I can also reproduce the janky scrolling prior to bug 1235478 landing.
status-firefox51: affected → wontfix
status-firefox52: affected → fix-optional
status-firefox53: affected → fix-optional
status-firefox54: --- → fix-optional
You need to log in before you can comment on or make changes to this bug.