Closed Bug 416312 Opened 17 years ago Closed 10 years ago

Scrolling scrolls two pages instead of one when scrolling page containing table

Categories

(Core :: Layout, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: john.p.baker, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008020708 Minefield/3.0b4pre
Build Identifier: 

On scrolling - using scrollbar -  a page with (large) table there is a delay before the next page is displayed and, frequently, the scroll is two pages instead of one.

Reproducible: Always

Steps to Reproduce:
1. Go to page with large table - eg bonsai (see URL)
2. Click in the scrollbar area to go up or down one page

Actual Results:  
The overlap pixels are displayed in their new location and then there is a delay (extraneous reflow?) before the rest of the page displays. Very frequently the display is two page scrolls instead of just one.

Expected Results:  
smooth scroll
Version: unspecified → Trunk
Just more funky behaviour ...
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Reopening.  I can reproduce the double scroll part of the problem
and it's also reproduce in a build dated before bug 414298 landed.
It's easy to reproduce at
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Assignee: nobody → jag
Status: UNCONFIRMED → NEW
Component: Layout → XP Toolkit/Widgets
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: layout → xptoolkit.widgets
Summary: strange behaviour when scrolling page containing table → Smooth scrolling scrolls two pages instead of one when scrolling page containing table
John, is it a (recent) regression ? (with a timeframe)

*****

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008020602 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

I can't reproduce (with either URLs), with new profile, (before bug 414298 landed).
No delay, no double scroll.

John, Mats, could you give SeaMonkey a try ?
In hope to determine if it could be FF specific... (or my computer...)
(In reply to comment #3)
> John, Mats, could you give SeaMonkey a try ?

I can reproduce in SeaMonkey 2008020801 and Firefox 2008020804, on Linux.
It occurs more often when the application/PC is busy.
STEPS TO REPRODUCE:
0. set the pref general.smoothScroll = true
1. go to http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox
   and wait until it's fully loaded
2. open a second window and load a bookmark that opens hundreds of tabs
   (this is to slow the application/PC down)
3. in the first window: click in the scrollbar below the thumb --
   this should scroll the window one page down, often it scrolls two
   pages down (I've never seen it scroll more than two).
(In reply to comment #3)
> John, is it a (recent) regression ?

I only noticed this week - probably earlier than 414298 - but it became much more obvious with the funky behaviour.

I can, with difficulty, reproduce on

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008020804 Minefield/3.0b4pre ID:2008020804

a) without smoothScroll
b) It is possible that you need to click reasonable distance - more than one thumb height - above/below thumb but this could be a red herring.
Summary: Smooth scrolling scrolls two pages instead of one when scrolling page containing table → Scrolling scrolls two pages instead of one when scrolling page containing table
Assignee: jag → nobody
Component: XP Toolkit/Widgets → General
QA Contact: xptoolkit.widgets → general
(In reply to comment #5)
> (In reply to comment #3)
> 
> I can, with difficulty, reproduce on
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008020804
> Minefield/3.0b4pre ID:2008020804

This can be made easier by increasing the size of the table. It nearly always happens on http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-02-01&maxdate=2008-02-08&cvsroot=%2Fcvsroot

> a) without smoothScroll
> b) It is possible that you need to click reasonable distance - more than one
> thumb height - above/below thumb but this could be a red herring.

this appears to be true

Another example is the STR from bug 418948 - (a) with the window small enough that it needs more than two pages and (b) clicking more than a thumb height from the thumb.

I also see it on a CMS edit page, containing a Java editor, if I scroll while the editor is initialising; I get hit by this one quite often as the editor is on page 2.

I suspect that looking for a regression range is quite likely to find when 'table reflow became slower than scroll repeat interval' rather than 'scroll repeat activated incorrectly on slow reflow'.

Requesting blocking as I am probably not the only person with a PC slow enough to exhibit this bug.
Flags: blocking1.9?
Component: General → Layout: Tables
QA Contact: general → layout.tables
(In reply to comment #7)
> I suspect that looking for a regression range is quite likely to find when
> 'table reflow became slower than scroll repeat interval' rather than 'scroll
> repeat activated incorrectly on slow reflow'.

What do you mean by "scroll repeat"?

Is this really specific to tables?  I doubt it.
(In reply to comment #8)
> What do you mean by "scroll repeat"?

Basically, the behaviour is as if 'click and hold' - which continues scrolling until release - instead of 'click' has been actioned; I am assuming that on mousedown an interval timer starts and this is cleared on mouseup and, if reflow takes too long, it is firing once. [I am also assuming that there is code in the timer routine that stops scrolling when the thumb goes under the pointer] [I haven't found any of this code yet but that is how the widget behaves]

> Is this really specific to tables?  I doubt it.

I doubt it too. It became noticeable when scrolling a page with a table became much slower - and there may be a table bug there (see also regression bug 418948); The URL scrolls smoothly, on PageDown, in firefox 2 and has a noticeable delay in firefox 3.0b4pre.

Flags: blocking1.9? → blocking1.9-
I finally decided to report this bug. I have experienced in many times, and in earlier versions, too. I never associated it with tables, and can in fact state that it happens even when the page contains zero tables.

I used to think it was a problem with my system. I finally decided to search Bugzilla to find out if others experience the same thing. This bug is close enough.

Right now, it is happening at https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&content=double+scroll in another tab. It is also happening on the page I was originally reading. It is not happening on this page. I checked, and the original page has a small table at the top, and another small table at the bottom. Who knew? Anyhow, these tables do not to be visible in the window when the behavior happens, as there is a lot of text between the too tables (it took 16 clicks to scroll from the bottom to the top. It should have taken over 20 clicks but the screen double scrolled at least 4 times). 

I don't know if telling you this helps: the screen redraw is slower than normal when this happens.

I am using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 and Windows 2000 5.00.2195 Service Pack 4.

I have one Firefox window with 4 tabs. All other applications are minimized. Adobe Reader version 7.1.0, Thunderbird 2.0.0.14, and OOo-dev 3.0.0 dev are the other applications.
I have just upgraded to Firefox 3.0.1 for the Mac and this bug is driving me crazy.  On a Mac, clicking anywhere in the scroll bar should jump down a page (if the preference in "Appearance" is set to do that).  Instead, it jumps two pages on about half or more of the sites I visit.  The same sites work as expected with other browsers.  I don't know if there are tables on the pages or not.
Do others still have this bug?

You may wish to see my comment at https://bugzilla.mozilla.org/show_bug.cgi?id=584503#c17

As far as I can tell bug 584503 is not html table related although I now only get it with XUL tables - eg about:config and Thunderbird mail lists.
WFM, Firefox Nightly on Linux64 (on a PC with well above average performance).
Can anyone else still reproduce this? (in particular on slower machines)
Component: Layout: Tables → Layout
Keywords: qawanted
(In reply to Mats Palmgren (:mats) from comment #13)

Are you saying the bug works for you or that you no longer have the bug?

I plan to keep to TenFourBird 10.0.11 on my PPC 7450 for several years to come. 

I would appreciate information about any hack I can experiment with to cure this.

Please read all my comments at bug 584503.
Heh!  I left the above bug report _six_ years ago and just started receiving cc's of the recent responses in this thread :)  I didn't even remember having this problem and thought maybe someone hacked my bugzila account :)  Although no one has signed up to fix it, it must have gotten fixed by something else ages ago.  I'm currently on Firefox 28 and OS X 10.6.8 and can't reproduce it.

@Neville:  PPC 7450?!  And I thought _I_ was a holdout :)
Status: NEW → RESOLVED
Closed: 17 years ago10 years ago
Resolution: --- → WORKSFORME
I still have the problem and am not happy that Mats has changed the status of this bug.

Please read all my comments at bug 584503
We believe that the problem doesn't occur in recent versions of Firefox.
Feel free to reopen it if you can reproduce it in a supported version
of Firefox, i.e. Firefox 29 or later at this time.
My hardware does not support the latest version.

I have concerns about a bug monitoring process which states that a bug has been 'resolved' when it probably has not been.

The bug may have been removed by unknown changes but this is not the same as resolved.

It is also possible that the bug may still exists on slow hardware.
Issue is Resolved - removing QA-Wanted Keywords - QA-Wanted query clean-up task
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.