Firefox doesn't auto scroll when selecting content downwards

Bug #744580 reported by Alan Pope ๐Ÿบ๐Ÿง๐Ÿฑ ๐Ÿฆ„
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)

Revision history for this message
In , Alice0775 (alice0775) wrote :

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.

Revision history for this message
In , Mats Palmgren (matspal) wrote :

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

Revision history for this message
Alan Pope ๐Ÿบ๐Ÿง๐Ÿฑ ๐Ÿฆ„ (popey) wrote :
Revision history for this message
mark johnson (mark.johnson) wrote :

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

Changed in firefox (Ubuntu):
status: New → Confirmed
Revision history for this message
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
Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

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
Revision history for this message
In , Alice0775 (alice0775) wrote :

*** 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)
Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

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

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

Created attachment 522841
Fix selection autoscroll in fullscreen

Revision history for this message
In , Olli-pettay (olli-pettay) wrote :

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

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

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

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

(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

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

Created attachment 523611
Fix selection autoscroll in fullscreen

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

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

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

+ 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!

Revision history for this message
In , Alice0775 (alice0775) wrote :

This also related to Bug 636206

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

(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!

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

Created attachment 525563
Fix selection autoscroll in fullscreen (v2)

Updated patch

Revision history for this message
In , Alice0775 (alice0775) wrote :

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

Changed in firefox (Ubuntu Natty):
status: Triaged → Fix Committed
Revision history for this message
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
Revision history for this message
In , Karlt (karlt) wrote :

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

Revision history for this message
In , Bijumaillist (bijumaillist) wrote :

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

Revision history for this message
In , Caspy77 (caspy77) wrote :

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.

Revision history for this message
In , Masayuki (masayuki) wrote :

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.

Revision history for this message
In , Masayuki (masayuki) wrote :

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.

Revision history for this message
In , Masayuki (masayuki) wrote :

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

Revision history for this message
In , Masayuki (masayuki) wrote :

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
Revision history for this message
In , Masayuki (masayuki) wrote :

Created attachment 544683
Patch v3.0

testing on tryserver...

Revision history for this message
In , Masayuki (masayuki) wrote :

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.

Revision history for this message
In , Masayuki (masayuki) wrote :

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.

Revision history for this message
In , Faaborg (faaborg) wrote :

Comment on attachment 544738
Patch v3.0.1

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

sorry about the delay, approach sounds good

Revision history for this message
In , Masayuki (masayuki) wrote :

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.

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

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?

Revision history for this message
In , Masayuki (masayuki) wrote :
Revision history for this message
In , Masayuki (masayuki) wrote :

(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??

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

(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.

Revision history for this message
In , Roc-ocallahan (roc-ocallahan) wrote :

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

Revision history for this message
In , Masayuki (masayuki) wrote :
Revision history for this message
In , Masayuki (masayuki) wrote :

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

relanded. thank you for your quick response, roc!

Revision history for this message
In , Joe-drew (joe-drew) wrote :

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

Revision history for this message
In , Masayuki (masayuki) wrote :
Revision history for this message
In , Joe-drew (joe-drew) wrote :
Changed in firefox:
status: In Progress → Fix Released
Revision history for this message
In , Giorgio-liscio (giorgio-liscio) wrote :

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)

Revision history for this message
In , Masayuki (masayuki) wrote :

(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.

Revision history for this message
In , Masayuki (masayuki) wrote :

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

Changed in firefox:
status: Fix Released → Confirmed
Revision history for this message
In , Giorgio-liscio (giorgio-liscio) wrote :

@masayuki see bug 623177 too

thanks

Revision history for this message
Jacopo Moronato (jmoronat) wrote :

Relanded in Oneiric (firefox 7).

Revision history for this message
Ruslan (rulet3) wrote :

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

Revision history for this message
In , Mats Palmgren (matspal) wrote :

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

Revision history for this message
madbiologist (me-again) wrote :

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

madbiologist (me-again)
tags: added: verification-failed-lucid
tags: removed: verification-failed-lucid
Revision history for this message
madbiologist (me-again) wrote :

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

Revision history for this message
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?

Revision history for this message
madbiologist (me-again) wrote :

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

Revision history for this message
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.

Revision history for this message
In , Alex Mayorga (alex-mayorga) wrote :

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?

Revision history for this message
In , Alex Mayorga (alex-mayorga) wrote :

Masayuki,

Would you re-land the patch anytime soon?

Revision history for this message
In , Masayuki (masayuki) wrote :

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

Revision history for this message
In , Overholt-u (overholt-u) wrote :

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

Revision history for this message
heartsmagic (heartsmagic) wrote :

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

Revision history for this message
In , Firefox-a (firefox-a) wrote :

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?

Revision history for this message
In , L252566 (l252566) wrote :

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/

Revision history for this message
In , Alice0775 (alice0775) wrote :

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 :(

Revision history for this message
In , Alice0775 (alice0775) wrote :

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

Revision history for this message
In , Alice0775 (alice0775) wrote :

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

Revision history for this message
In , Mats Palmgren (matspal) wrote :

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

Revision history for this message
In , L252566 (l252566) wrote :

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

Revision history for this message
In , Elbart (elbart) wrote :

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.

Revision history for this message
In , L252566 (l252566) wrote :

@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.

Revision history for this message
In , James0r (james-auble2) wrote :

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.

Revision history for this message
In , Goozak (goozak) wrote :

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

Revision history for this message
In , Nicolas-barbulesco (nicolas-barbulesco) wrote :

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

Revision history for this message
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?

Revision history for this message
Cassio Martini (cassiomartini) wrote :

BTW, I'm using Ubuntu 14.04 with Firefox 35.0

Revision history for this message
In , Mats-l (mats-l) wrote :

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

Revision history for this message
In , Alice0775-t (alice0775-t) wrote :

This was fixed by Bug 623432

Changed in firefox:
status: Confirmed → Invalid
Changed in firefox:
status: Invalid → Fix Released
Revision history for this message
In , Andrey Pozdnyakov (andreypz) wrote :

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.