183517 - Scrolling in mail folder pane requires you wait for the timer to finish

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[tehlers]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

When moving mails from the listing of mails in a single folder to another folder
by dragging the mail to the appropriate folder in the folder list by mouse, the
folder list window doesn't scroll when moving the mouse with the dragged item to
the bottom of the window. It it necessary to scroll the window with the
scrollbar first, and drag the mail afterwards. Mozilla 1.0.1 did scroll
automatically, which is very convenient when the folder list it too long to fit
on the screen. 

Reproducible: Always

Steps to Reproduce:
1. Make sure the folder list is long enough that it doesn't fit on the screen 
2. Try dragging a mail into a folder that is not visible on the screen without
scrolling. 
3.

Actual Results:  
Nothing. I need to use the scrollbars every time before dragging a mail. 

Expected Results:  
Scroll the mail window automatically when moving the mouse to the bottom of the
folder list, like previous versions of Mozilla (at least 1.0.1 and before, I did
not try 1.1) did.

Comment 1

[laurel]

This worksforme with win2000 using dec2 commercial trunk, doesn't work with dec3
commercial trunk.

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

When I verified bug 167841 as fixed, I either missed the case of not hitting the
scrollbars, or that worked back then.

Regardless, you can't drag and scroll without touching over the scrollbars, and
I'm sorry that I missed that in our discussion.  Thanks to Gary for the
enlightenment.  Confirming this bug with build 2002-12-04-08, Windows 2000. 
Upping severity to normal.

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

Jan, when you originally fixed (and I verified) bug 167841 back in Sept, I
either didn't catch the fact that we can't scroll without hitting the
scrollbars, or it's regressed since then.  Any chance you know of a fix for
this?  Thanks.

Comment 4

[Jan Varga [:janv]]

I think it is a regression ?
There were some nsITimer changes recently, bug 181961

Comment 5

[Jan Varga [:janv]]

It works on Linux, so I guess it has something to do with idle timers on windows

Comment 6

[John Morrison]

> This worksforme with win2000 using dec2 commercial trunk, doesn't work with 
> dec3 commercial trunk.

laurel: can you confirm that. That would be "does work with Monday morning's
build", "does not work with Tuesday morning's build". 

If that's the case, then "not guilty as charged". The nsITimer changes landed
on Tuesday afternoon. ;-)

Comment 7

[grylchan]

Tried 12-3 commercial trunk on win2k.
It worked fine for me. Tried both small and max size windows

Then tried commercial trunk 
2002-12-05-08-trunk on XP
2002-12-05-08-trunk on linux 2.2
& mozilla trunk
2002-12-05-07-trunk on 10.1.5

this seems to be working for me. I can take a mesg
drag it down to one of my bottom folders in the folder pane
and it scrolls. Sometimes little slow but it works.
Tried scolling up and that was ok to.
Tried with small messenger window and messenger in full
screen mode. Both worked.
Tried with alot of folders in a imap account or lots of subfolders
under Local Folders and no problem.


I asked few others and it seems to be working fine on windows
with current trunk (2k, 98).

I don't know why it seems to work one day and not the next.
I somehow think once in a while we get into a state where
it doesn't appear to work or takes few seconds before 
the folder pane starts scrolling? I see that once in a while
But if I stop and try again it works.

I could have sworn it didn't work with 12-3 or 12-4 builds but
it seems fine. 

marking as works for me.

If anyone sees this problem again or can suggest another
test case, please reopen.

Comment 8

[Jan Varga [:janv]]

jrgm, sorry I didn't mean to blame you :)

Comment 9

[lchiang]

Laurel is on vacation for the next few days.  I can easily reproduce this
problem on a build I'm using (trunk - from 11-25).  Let me update my build to
today's to see if the problem is still there.  I'll post findings once I have them.

Comment 10

[Jan Varga [:janv]]

I just updated my windows build and I was not able to reproduce it.

Comment 11

[lchiang]

I updated to 2002120508 build and I still have this problem. Windows XP. jrgm -
I can show you if you stop by.  Pls reopen this bug.

Comment 12

[[e-mail] (gone - use [e-mail] instead)]

Reopening for re-triage.  So, to resummarize:

There are 3 ways of auto-scrolling into the Folder Pane:

1) Dragging on the scrollbars
2) Dragging quickly through the folder pane and ending up on the statusbar
3) Dragging within the whitespace and

For case #2, which is what Lisa is used to doing, because she's dragging so
quickly, we're not hitting the timer interval, and thus not completing the
scroll.  If we eliminated the timer, everybody would see their folders scrolling
instantaneously.

For case #3, you still have to wait for the timer interval to go off to complete
the scroll.

Jan, is there a reason we put a timer (PR_wait, whatever)?  Using Netscape 7.0
(and whatever milestone Mozilla build that was based off of, 0.9.x?), the
behavior is such that we instantly scroll without waiting for the timeout to
finish firing.

Changing the summary to 'Scrolling in mail folder pane requires you wait for the
timer to finish'.  If someone can come up with a better summary (that's more
easily searchable), please resummarize.

Comment 13

[Jan Varga [:janv]]

I think we should not eliminate this timer. Maybe just decrease the default
timeout. The currect default value is 400 ms.
Check bug 142642 for more details.

Comment 14

[R.K.Aa.]

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

Comment 15

[Samir Gehani]

Mail triage team: nsbeta1+/adt3

Comment 16

[[e-mail] (gone - use [e-mail] instead)]

Attachment: Patch

Comment 17

[[e-mail] (gone - use [e-mail] instead)]

Okay.  The patch I attached won't bring us back to Netscape 7.0/Mozilla 1.0
parity.  It helps once you're in the scroll area, but there seems to be
something else introduced in bug 142642 that causes even the area of the
drag/drop target to be reduced.

Comment 18

[Alec Flett]

Comment on attachment 110832 [details] [diff] [review]
Patch

sr=alecf contingent specifically on r=varga or r=hyatt

Comment 19

[[e-mail] (gone - use [e-mail] instead)]

Jan has landed my delay-reducing timer patch, but I'm wondering if we need to
bring this up to 7.0/Mozilla 1.0 parity.  (I guess the answer to that question
lies in the fixing of bug 142642, though.

For now, I'm marking this FIXED, so that the remaining issue can be discussed
elsewhere.

Comment 20

[Ninoschka Baca]

Trunk build 2003-03-05: WinXP, Linux RH 8 - Fixed
Trunk build 2003-03-05: Mac 10.1.5 - Fixed, althought slow but this has been
around since N701 and N702 (possibley bug# 178090)
Verified Fixed