Closed Bug 1393424 Opened 5 years ago Closed 5 years ago
Autoscrolling starts instantly on Print Preview mode
59 bytes, text/x-review-board-request
[Note]: - Reproducible on Firefox 56.0b5 with apz.autoscroll.enabled set to True [Affected versions]: - Nightly 57.0a1 [Affected platforms]: - Win 10 64-bit - Ubuntu 16.04 64-bit [Steps to reproduce]: 1. Open a long page (eg: https://en.wikipedia.org/wiki/Main_Page) 2. Select Menu - Print Preview 3. Middle mouse click to autoscroll the page [Expected result]: - Autoscrolling icon is placed under mouse pointer; moving mouse pointer up / down starts to autoscroll the page in the desired direction [Actual result]: - Autoscrolling icon is placed below (Windows) or under (Ubuntu) mouse pointer and scrolling starts immediately (without other user interaction). Having two displays and the browser on the second one will place the icon on the first one. [Regression range]: - This is not a regression. On older versions (before implementing APZ autoscrolling), the autoscrolling could not be performed in print preview mode. [Additional notes]: - Not reproducible on OS X (Print Preview option is not available)
Possibly dupe of bug 384914.
This looks like a coordinate system problem, the icon (on my machine) shows up about 2/3rds of the way between the origin and where you click. The same goes for tooltips, actually - if you hover over a link the tooltip is misplaced. The autoscrolling starting on it's own is probably a side-effect of the icon (and therefore the autoscroll "origin") being misplaced. I'm going to file another bug for the coordinate system problem and make this dependent on that.
Priority: -- → P3
5 years ago
Depends on: 1393494
It looks like with main-thread autoscrolling, the autoscroll anchor appears on the Print Preview page in the incorrect location, but no scrolling occurs. With APZ autoscrolling, the anchor appears in the same incorrect location, and scrolling based on that incorrect location does occur. So, there was still a change in behaviour, even though the behaviours before and after are both incorrect. Since no scrolling is arguably better than incorrect scrolling, it might make sense to investigate the change in behaviour, and see if we can make APZ autoscrolling not do any scrolling in this case either, until the underlying bug 1393494 is fixed.
(In reply to Botond Ballo [:botond] from comment #3) > It looks like with main-thread autoscrolling, the autoscroll anchor appears > on the Print Preview page in the incorrect location, but no scrolling occurs. > > With APZ autoscrolling, the anchor appears in the same incorrect location, > and scrolling based on that incorrect location does occur. > > So, there was still a change in behaviour, even though the behaviours before > and after are both incorrect. The reason we don't scroll with main-thread autoscroll is that the content-side JS code that initiates autoscrolling triggers an exception due to something being null in Print Preview mode. The exception happens after it has sent the Autoscroll:Start message, so the parent process shows the anchor, but before it registers the requestAnimationFrame callback which causes scrolling. With APZ autoscrolling, the parent process initiates the APZ scrolling upon receiving the Autoscroll:Start message, so scrolling does happen. It would be rather silly to try to exactly replicate the main-thread behaviour with APZ. Instead, the patch I posted just disables autoscrolling on the Print Preview page (with or without APZ). There's no point having it enabled if it doesn't work properly.
Comment on attachment 8903684 [details] Bug 1393424 - Don't try to autoscroll in Print Preview mode. https://reviewboard.mozilla.org/r/175462/#review180568 ::: toolkit/content/browser-content.js:141 (Diff revision 1) > > this.findNearestScrollableElement(event.originalTarget); > > if (!this._scrollable) > return; > + nit: whitespace
Attachment #8903684 - Flags: review?(bugmail) → review+
(In reply to Botond Ballo [:botond] from comment #5) > Instead, the patch I posted just disables autoscrolling > on the Print Preview page (with or without APZ). There's no point having it > enabled if it doesn't work properly. Filed bug 1396028 to track fixing and re-enabling it.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/f584ae5d61c4 Don't try to autoscroll in Print Preview mode. r=kats
Verified on latest Nightly 57.0a1 2017-09-07 under Win 10 64-bit and Ubuntu 14.04 64-bit that autoscrolling is disabled in print preview mode.
You need to log in before you can comment on or make changes to this bug.