Firefox doesn't auto scroll when selecting content downwards

Bug #744580 reported by Alan Pope 🍺🐧🐱 πŸ¦„ on 2011-03-28
80
This bug affects 17 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox (Ubuntu)
Medium
Chris Coulson
Natty
Medium
Chris Coulson

Bug Description

Binary package hint: firefox

Open firefox 4
Go full screen
Open a long page such as this one:- http://mail.gnome.org/archives/commits-list/2011-March/msg03805.html
Try to highlight a large chunk of text starting on screen and move the mouse down and try to go off the bottom of the screen (selecting text). Note that the browser doesn't scroll down. This is the bug.

Note that if you scroll the window to the bottom and drag upwards it does scroll upwards as you select.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: firefox 4.0~rc2+build3+nobinonly-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-7.39-generic 2.6.38
Uname: Linux 2.6.38-7-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Mon Mar 28 22:25:33 2011
FirefoxPackages:
 firefox 4.0~rc2+build3+nobinonly-0ubuntu1
 flashplugin-installer N/A
 adobe-flashplugin N/A
 icedtea-plugin 1.1~20110320-0ubuntu1
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox
UpgradeStatus: Upgraded to natty on 2011-01-19 (68 days ago)

Build Identifier:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110324
Firefox/4.2a1pre ID:20110324030442

Drag selection does not work properly in fullscreen mode.

Drag selection upward : scroll down is very slow
Drag selection downward : scroll stops at the bottom of screen.

Steps to Reproduce:
1. Start Minefield with new profile
2. Open Web page (long enough to scroll)
3. Selection start by mouse down and hold the mouse
4. Drag selection downward or upward
Actual Results:
  Drag selection downward : Scroll tops at the bottom of screen.
  Drag selection upward : Scroll speed is slightly slow.

Expected Results:
  The selection should be expanded.

*** Bug 645547 has been marked as a duplicate of this bug. ***

This also happens for me under KDE on Maverick. Firefox installed from mozilla-stable PPA.

Changed in firefox (Ubuntu):
status: New → Confirmed
Chris Coulson (chrisccoulson) wrote :

The issue seems to be that scrolling doesn't start until the mouse moves outside of the top-level window, which breaks it for maximized windows.

Changed in firefox (Ubuntu):
importance: Undecided → Medium

I'm forwarding this from https://launchpad.net/bugs/744580:

Steps to reproduce:
Open firefox 4
Go full screen
Open a long page such as this one:- http://mail.gnome.org/archives/commits-list/2011-March/msg03805.html
Try to highlight a large chunk of text starting on screen and move the mouse down and try to go off the bottom of the screen (selecting text). Note that the browser doesn't scroll down. This is the bug.

Note, that if the window is not maximized, you will notice that auto-scrolling does eventually happen - but not until the pointer is outside of the window (which breaks completely for maximized windows)

Changed in firefox (Ubuntu):
status: Confirmed → Triaged
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed

*** Bug 645855 has been marked as a duplicate of this bug. ***

Changed in firefox (Ubuntu):
assignee: nobody → Chris Coulson (chrisccoulson)
Changed in firefox:
importance: Medium → Unknown
status: Confirmed → Unknown
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed
affects: firefox (Ubuntu) → ubuntu
affects: Ubuntu Natty → firefox (Ubuntu Natty)

After doing some digging today, I realised that this only ever worked in 3.6 because the statusbar made it possible for the pointer to travel beyond the end of the scrolled area.

This is caused because nsTypedSelection::DoAutoScroll calls PresShell::ScrollFrameRectIntoView with a 1x1 nsRect (in app units). This means that the pointer needs to travel beyond the edge of the scrolled area before that nsRect is out of view (which is what triggers scrolling).

To fix this, you can make the nsRect passed to ScrollFrameRectIntoView a bit larger. I've attached a patch which does this, which ensures that the nsRect starts to go out of view before the pointer reaches the edge of the scrolled area

Created attachment 522841
Fix selection autoscroll in fullscreen

The patch seems to work nicely, but needs tests.
roc or mats could review it.

Probably simpler to use nsIntRect(...).ToAppUnits(...);

(In reply to comment #6)
> Probably simpler to use nsIntRect(...).ToAppUnits(...);

Thanks, I didn't realise that existed. In any case, as aPoint is already in app units, it doesn't seem to make things any easier.

I'm attaching an updated patch now, slightly tidied and with a test case

Created attachment 523611
Fix selection autoscroll in fullscreen

Note, I've also verified the test fails on a current Firefox build (without the patch)

+ nscoord oneDevPixel = presContext->DevPixelsToAppUnits(1);
+ nsPoint offsetPoint = aPoint - nsPoint(oneDevPixel * 20, oneDevPixel * 20);
+ nsSize rectSize = nsSize(oneDevPixel * 40, oneDevPixel * 40);
   PRBool didScroll = presContext->PresShell()->
+ ScrollFrameRectIntoView(aFrame, nsRect(offsetPoint, rectSize),

Why not
  nsRect r = nsIntRect(-20, -20, 40, 40).
    ToAppUnits(presContext->AppUnitsPerDevPixel());
  PRBool didScroll = presContext->PresShell()->
    ScrollFrameRectIntoView(aFrame, r + aPoint);

Sure looks simpler to me!

This also related to Bug 636206

(In reply to comment #10)
> + nscoord oneDevPixel = presContext->DevPixelsToAppUnits(1);
> + nsPoint offsetPoint = aPoint - nsPoint(oneDevPixel * 20, oneDevPixel * 20);
> + nsSize rectSize = nsSize(oneDevPixel * 40, oneDevPixel * 40);
> PRBool didScroll = presContext->PresShell()->
> + ScrollFrameRectIntoView(aFrame, nsRect(offsetPoint, rectSize),
>
> Why not
> nsRect r = nsIntRect(-20, -20, 40, 40).
> ToAppUnits(presContext->AppUnitsPerDevPixel());
> PRBool didScroll = presContext->PresShell()->
> ScrollFrameRectIntoView(aFrame, r + aPoint);
>
> Sure looks simpler to me!

Yes, you're right. Thanks!

Created attachment 525563
Fix selection autoscroll in fullscreen (v2)

Updated patch

*** Bug 650678 has been marked as a duplicate of this bug. ***

Changed in firefox (Ubuntu Natty):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 4.0+nobinonly-0ubuntu3

---------------
firefox (4.0+nobinonly-0ubuntu3) natty; urgency=low

  [ Felix Geyer <email address hidden> ]
  * Fix LP: #572772 - can't save files in KDE
    - update debian/patches/mozilla-kde.patch

  [ Chris Coulson ]
  * Fix LP: #766151 - popuphiding and popuphidden events aren't dispatched
    when a menu is closed, leading to exceptions being thrown in
    browserPlacesViews.js (visible from the error console)
    - update globalmenu-extension to 1.0.2
  * Fix LP: #744580 - Firefox doesn't autoscroll when selecting content
    downwards
    - add debian/patches/fix-selection-drag-autoscroll.patch
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Tue, 19 Apr 2011 17:10:50 +0100

Changed in firefox (Ubuntu Natty):
status: Fix Committed → Fix Released

*** Bug 636206 has been marked as a duplicate of this bug. ***

*** Bug 658160 has been marked as a duplicate of this bug. ***

Seems the duplicates have noted this, dunno if it should be added to the description/title, but this behavior is also observed when the window is maximized (and there is no UI at the bottom).

Also can I asked the status of this bug? It looks like it was mostly fixed in April. Is it at a place it can land?

P.S. Hope it's alright that went ahead I updated the title.

Um, this patch may conflict with bug 552707. And I think that the body element should be scrollable on its edge of bug 552707's patch.

My bug 552707 patch is waiting final review of smaug. The patch has been already passed ui-review and roc's first review. And even if this patch would be landed first, I needed to backout of this change and need to change my patch for scrolling body on its edge. Therefore, I'd like you wait bug 552707 fix and recreate your patch based on my patch. If so, the behavior will be standardized on all situations.

I landed bug 552707 on inbound. So, the patch shouldn't be used. I'll post a new patch ASAP.

Um, I have a question.

Should this bug be fixed on all scrollable elements? I.e., should <input> and <textarea> be also scrolled when mouse cursor is on their edge?

For a11y, I think that they should be scrollable too, though. Chris's patch looks so. But I'm not sure whether it was intentional.

Changed in firefox:
status: Confirmed → In Progress

Created attachment 544683
Patch v3.0

testing on tryserver...

Created attachment 544738
Patch v3.0.1

I think this needs ui-review.

Users can scroll any selection root elements while they move mouse cursor on their edge. This means that user can scroll scrollable element always if all of it is visible.

If mouse cursor is on edge, the scrolling speed is always same which is set by prefs. If user moved the mouse cursor to outside, user would see slower scrolling than edge scrolling. I think this is odd. Therefore this patch also use on-edge scrolling speed as minimum speed of auto scrolling while mouse cursor is outside of the element. When the scrolling speed is faster than on-edge scrolling speed (i.e., user moves mouse cursor to far from the element), it doesn't use the on-edge scrolling speed.

Another proposal: Only when mouse cursor is on current screen edge, the selection root scrollable element can be scrolled on its edge. However, this would test harder than current patch. And it may confuse users to change the behavior depending on the window position/size in screen.

Comment on attachment 544738
Patch v3.0.1

Review of attachment 544738:
-----------------------------------------------------------------

sorry about the delay, approach sounds good

Created attachment 546015
Patch v3.1

Thank you, faaborg.

# fix a nit from previous patch

Note that the pref names are changed since they're used for selection root element too.

Comment on attachment 546015
Patch v3.1

Review of attachment 546015:
-----------------------------------------------------------------

r+ with that fixed

::: layout/generic/nsFrame.cpp
@@ +2663,5 @@
> +
> + // We should set minimum scroll speed same as the on-edge scrolling speed.
> + // E.g., while mouse cursor is on the edge, scrolling speed is always same.
> + // However, when the user moves 1px outside of the selection root element,
> + // the scrolling speed is slow down. We should avoid this strange behavior.

Remove the last two lines of this comment, since they're confusing; it sounds like you're describing something that actually happens with this patch applied.

@@ +2666,5 @@
> + // However, when the user moves 1px outside of the selection root element,
> + // the scrolling speed is slow down. We should avoid this strange behavior.
> + nsPoint currentScrollPos = scrollableFrame->GetScrollPosition();
> + nsRect visibleRectOfScrolledFrame = scrollableFrame->GetScrollPortRect();
> + visibleRectOfScrolledFrame.MoveTo(currentScrollPos);

This should be scrollableFrame->GetScrollPortRect() + curentScrollPos, right?

(In reply to comment #27)
> > + nsPoint currentScrollPos = scrollableFrame->GetScrollPosition();
> > + nsRect visibleRectOfScrolledFrame = scrollableFrame->GetScrollPortRect();
> > + visibleRectOfScrolledFrame.MoveTo(currentScrollPos);
>
> This should be scrollableFrame->GetScrollPortRect() + curentScrollPos, right?

Oops, I changed to:

> 1.62 + nsRect visibleRectOfScrolledFrame =
> 1.63 + scrollableFrame->GetScrollPortRect() + scrollableFrame->GetScrollPosition();

This is same as my original code only when GetScrollPortRect() is positioned 0, 0. Is that always true??

(In reply to comment #29)
> This is same as my original code only when GetScrollPortRect() is positioned
> 0, 0. Is that always true??

It's usually true, but not always. Sometimes we have scrollbars on the left so the scrollport x is > 0. Also, when the scrolled element has a left border, the scrollport x is > 0.

Oh I see. Your original code was right and my suggestion was wrong. Please fix it, sorry :-(.

http://hg.mozilla.org/integration/mozilla-inbound/rev/28127a75bb29

relanded. thank you for your quick response, roc!

This (along with most things committed on Friday afternoon) was backed out of mozilla-inbound in order to clear up orange.

Changed in firefox:
status: In Progress → Fix Released

i think it is better to remove the acceleration given by the distance from the area to scroll

trigger area and speed should be constant and slow independently from mouse position

but if user "shakes" the mouse the speed must increase (this is currently implemented and works good)

(In reply to comment #37)
> but if user "shakes" the mouse the speed must increase (this is currently
> implemented and works good)

I don't think so, see bug 672181.

Temporarily, backed out for risk management of mozilla8, see bug 675865.

Changed in firefox:
status: Fix Released → Confirmed

@masayuki see bug 623177 too

thanks

Jacopo Moronato (jmoronat) wrote :

Relanded in Oneiric (firefox 7).

Ruslan (rulet3) wrote :

 Confirm this bug on ubuntu11.10(gnome-shell or unity).

*** Bug 708477 has been marked as a duplicate of this bug. ***

madbiologist (me-again) wrote :

I updated to Firefox 9.0.1 from lucid-proposed. This bug still exists.

madbiologist (me-again) on 2012-01-01
tags: added: verification-failed-lucid
tags: removed: verification-failed-lucid
madbiologist (me-again) wrote :

Sorry about that tag Chris - I asked on #ubuntu and was advised to add it.

Greg Lynch (gregalynch) wrote :

I just noticed this bug a couple of weeks ago (before the Firefox update that just came out today). I'm not positive, but I'm fairly sure the scrolling worked before that. Was something changed in an update?

madbiologist (me-again) wrote :

@Greg Lynch - What version of Ubuntu are you using, and which Firefox update have you just installed?

Greg Lynch (gregalynch) wrote :

Mad - 11.10. An update of Firefox (to 9.0.1) came through update manager a few days ago. The problem was there before the upgrade, and still is afterward.

Still a problem on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0) Gecko/20120221 Firefox/13.0a1 ID:20120221031301

Should "Target Milestone" be changed?

Masayuki,

Would you re-land the patch anytime soon?

No. There are some issues which must be fixed before landing.

*** Bug 629673 has been marked as a duplicate of this bug. ***

heartsmagic (heartsmagic) wrote :

This is still a problem with Firefox 20.0 on Ubuntu 13.04. (Also other releases such as 12.10)

After more than an year, it's time for a friendly ping:

Is there any schedule for the patch to land, or any other solution or workaround for this bug?

Until this bug is fixed you can use one of these workarounds:

- Use shift-arrow-down instead to select the text
- Select the text starting from the bottom - go upwards.
- Make the addon bar visible
- Make the find bar visible
- These addons can put a toolbar at the bottom:
  https://addons.mozilla.org/en-US/firefox/addon/split-pannel/
  https://addons.mozilla.org/en-US/firefox/addon/searchbastard/

Findbar is now top in Nightly24.0a1.
Australis removed the addon bar and Australis will land in near future.

The probability to encounter with this bug becomes higher :(

*** Bug 909189 has been marked as a duplicate of this bug. ***

*** Bug 959238 has been marked as a duplicate of this bug. ***

*** Bug 997925 has been marked as a duplicate of this bug. ***

Another workaround which works only on FF29 and later is to install the "The Addon Bar (restored)" addon.

The addonbar is hidden in fullscreen-mode.

The only proper workaround is the bug being fixed.
It's only 4.5 years after the regression, give it a year or two.

@Elbart, You are correct that the addonbar is hidden in fullscreen-mode but the bug happens also in maximized-window mode so at least in this mode that workaround will work.

Firefox user for about 6 months. Didn't encounter this issue prior to Firefox 29 probably because of the add-on bar being enabled in previous versions. Adding this comment to hopefully to raise urgency of a fix. Being able to scroll while selecting on a netbook or smaller screen is pretty critical.

Not sure how to do it properly, but bug #157456 seems a duplicate of this one...

The scope of the bug 157456 is wider. The occurrences of the bug are not limited to full screen.

Cassio Martini (cassiomartini) wrote :

Hi.

I get this same bug. But it's not restricted to firefox. I get it in google chrome too.

Any news on this?

Cassio Martini (cassiomartini) wrote :

BTW, I'm using Ubuntu 14.04 with Firefox 35.0

*** Bug 113294 has been marked as a duplicate of this bug. ***

This was fixed by Bug 623432

Changed in firefox:
status: Confirmed → Invalid
Changed in firefox:
status: Invalid → Fix Released

Well, it's been 2 years after that comment.
The bug is still there...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.