136237 - scrolling problems with compose addresses when mouse down

Status: RESOLVED WONTFIX

(MailNews Core :: Composition, defect)

Description

[(not reading, please use [e-mail] instead)]

scrolling problems with compose addresses.

ok, I can reproduce this one 100% of the time, but it's hard to explain.

compose a new message
enter in a bunch of addresses (7 or more)
click and hold in the last address, and drag the mouse up.

this causes the addressing widget to scroll, but the rows don't paint.

I'll screen shot for you.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: screen shot

Comment 2

[(not reading, please use [e-mail] instead)]

there 5 other email addresses above the first visible one in that screen shot.

this doesn't happen in older builds, as clicking and dragging upwards doesn't
cause a scroll.

Comment 3

[Rainer Bielefeld]

I can confirm Problem with
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020403(03)

Reporter or owner, please add relevant keywords as
mail4 
or similar

Comment 4

[Rainer Bielefeld]

still actual with 
Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020409(03)

Comment 5

[Waheed Islam]

ahh yes, I see it. Not only does it not repaint, but it seems to cause some app
freezing behaviour.

20020820 08 - winnt
yes, yes, need a new build. ;)

Comment 6

[Waheed Islam]

whoops,
20020820 08 -> 20020802 08.

hehe, an even older build.

Comment 7

[Daniel Schroeter]

Is Bug #154454 a dup? It's just the other way: from up to down.

I can reproduce the problem under Linux with Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.2b) Gecko/20020918. Can you change OS to "All"!?

Like I wrote in Bug #154454:
If you have this blank window and you click to your normal text window in the
composer your only chance to get the adresses back is to use the wheel mouse in
the address area. (I found no other way.)

Comment 8

[Rainer Bielefeld]

This problem is still actual for
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030502

Comment 9

[luca]

One of my users reported this problem on 1.3. I tested it with 1.4rc1 and it's
still there. Don't know if it's clear from comment 5, but when this happen it's
impossible to select anything from the menus and to click any button in the
toolbar. The only way out is to try and close the window and clicking "yes" when
mozilla asks if you want to save the message.

Comment 10

[Jim Booth]

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

Comment 11

[Ant]

Attachment: How to reproduce the bug in Mozilla v1.3.1.

I am having this problem too. This is very annoying when I accidently reproduce
this bug. The only thing I can is close the window to get prompt to save as
Draft (all the time if the e-mail is important) or Don't Save.

I have attached my screen shots (from Windows XP). I was able to reproduce
under Red Hat Linux v7.1 and Windows XP and 2000. I am sure my PowerBook G4 1
Ghz (MacOS X) will have this problem. They all use Mozilla v1.3.x.

Comment 12

[Ant]

Oh, and down method works too. I didn't know there was a problem with that.

Comment 13

[Vincent Deconinck]

Whoo ... weird indeed.
It seems once the caret goes out of visible space, no mouse clicks are taken
into account anymore in chrome (mouse clicks still move the caret in the mail
body). Keyboard shortcuts can still be used to navigate menus, so the "close and
save as draft" is by far not the only option. 
Moreover, there are multiple ways of getting back to a functional window by
managing to get the caret back in the visible area :
- wheel mouse scrolling in the recipients area as somebody said 
- if the focus is still in the recipients area (even if not visible), the area
can be scrolled by fiddling with keyboard arrows and selecting a new dummy
address or hitting Tab repeatedly.
- if the focus is in the body area, some menus shortcuts can get it back to the
headers area (Attach File, Select Addresses, ...)

Though I use Mozilla for years both at work and at home and never encountered
this bug before I reproduced the steps, I think it could happen to my hesitating
grandma and for sure she's not the one who'll feel comfortable with menu
shortcuts...

Comment 14

[Mike Cowperthwaite]

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

Comment 15

[Mike Cowperthwaite]

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

Comment 16

[Asa Dotzler [:asa]]

This can also be reproduced by giving focus to one of the lower addresses (fill
in 5 or 6 to test) and using the mousewheel to scroll the list up. Also a
problem in Thunderbird 0.5+

Comment 17

[Chris]

Attachment: This file illustrated that the bug is related to xul

Comment 18

[Chris]

Attachment: The problem can be solved with only one modification

The bug happened because the action actually fired a mousepress event then a
mouse drag event. the handler of these event are located in the nsFrame.cpp.
The Listbox frame has its own ScrollMediator to process the action of its
scrollbar. the content are removed as its scoll out the listbox and recreated
as its come into the listbox. That's why those row don't painted.

The easilest way to solve this bug is to simply shield this action and that's
what I did

Comment 19

[Mike Cowperthwaite]

There's no need to leave the previous line in the source, commented-out.
You'd better choose a different reviewer, Seth doesn't check in much.

Comment 20

[Chris]

Comment on attachment 196886 [details] [diff] [review]
The problem can be solved with only one modification

>Index: ./layout/generic/nsSelection.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/layout/generic/nsSelection.cpp,v
>retrieving revision 3.204
>diff -u -w -r3.204 nsSelection.cpp
>--- ./layout/generic/nsSelection.cpp	24 Aug 2005 17:46:45 -0000	3.204
>+++ ./layout/generic/nsSelection.cpp	21 Sep 2005 06:31:57 -0000
>@@ -5120,7 +5120,8 @@
>   if (NS_FAILED(result))
>     return result;
> 
>-  return DoAutoScrollView(aPresContext, aView, aPoint, PR_TRUE);
>+  return DoAutoScrollView(aPresContext, aView, aPoint, PR_FALSE);
> }
> 
> nsresult

Comment 21

[Chris]

Comment on attachment 196886 [details] [diff] [review]
The problem can be solved with only one modification

>Index: ./layout/generic/nsSelection.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/layout/generic/nsSelection.cpp,v
>retrieving revision 3.204
>diff -u -w -r3.204 nsSelection.cpp
>--- ./layout/generic/nsSelection.cpp	24 Aug 2005 17:46:45 -0000	3.204
>+++ ./layout/generic/nsSelection.cpp	21 Sep 2005 06:31:57 -0000
>@@ -5120,7 +5120,8 @@
>   if (NS_FAILED(result))
>     return result;
> 
>-  return DoAutoScrollView(aPresContext, aView, aPoint, PR_TRUE);
>+  return DoAutoScrollView(aPresContext, aView, aPoint, PR_FALSE);
> }
> 
> nsresult

Comment 22

[Chris]

Attachment: Same as previous one, but remove commented-out line

Comment 23

[David :Bienvenu]

I can't review layout changes - you need a layout module owner...

Comment 24

[David :Bienvenu]

Comment on attachment 196993 [details] [diff] [review]
Same as previous one, but remove commented-out line

David, can you change this request to someone else, if you don't want to review
it?

Comment 25

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I honestly don't see why you'd ever want to pass false for that (and currently
nothing does).  It seems like this would break some other types of scrolling,
and that the real fix might be that something is scrollable that shouldn't be. 
But Mats might know more.

Comment 26

[Chris]

THis is one of the method to solve the problem, I've also consider the effect
that may bring to other type of the scrolling. THe alternative way may need to
modify the definition of some interface. I would like to hear others opinion to
this bug.

Comment 27

[Chris]

Attachment: Not simply blocking the scroll of parent view, I made some restriction on scrolling parent view

I think the parent view should scroll only if the content in current view not
reach its end at the specified scrolling direction, and part of the current
view is not visible

Comment 28

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Could you explain what this patch does and why you think it's the right thing to do?

Also, the tabs make the patch very hard to read.  Please try to use spaces in
the future.

Comment 29

[Chris]

Point taken, I'll use space in the future.

Here is some explaination of my patch:

Previously, when the scrolling of child view causes the scrolling of its parent
view (if it is scrollable), we didn't make any restriction. This generally will
be fine, but sometimes leads to weired situation, for example, in this page, you
click and hold on the "additional comments" textarea and then drag the mice all
the way down, the parent view will scroll until reach its end. Also, this
feature causes the bug 136237.

What I'm thinking is that the parent view should scroll only if the scroller of
child view not reach its end in the specified direction and stop scrolling until
it done(or I have another patch which allow the scrolling of the parent view
only if part of child view is not visible and stop until it become totally visible).

The step of patch is:
  - Get the bounds, scroll position, and the document size of child view.
  - Get the bounds and scroll position of parent view
  - Check in which direction the user want the view to scroll.
  - Check wheather in the specified direction the scroller in the child view
reach its end.
  - Scroll the parent view if the answer in step 4 is yes...

Comment 30

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to comment #29)
> Previously, when the scrolling of child view causes the scrolling of its parent
> view (if it is scrollable), we didn't make any restriction. This generally will
> be fine, but sometimes leads to weired situation, for example, in this page, you
> click and hold on the "additional comments" textarea and then drag the mice all
> the way down, the parent view will scroll until reach its end. Also, this

The behavior on this page seems correct to me:  when the mouse moves
out of the viewport, it causes the entire page to scroll.  It should
do that.  Does your patch change that behavior?

> What I'm thinking is that the parent view should scroll only if the scroller of
> child view not reach its end in the specified direction and stop scrolling until

This doesn't make any sense.  Why should the parent only scroll if
the child is *not* at the end?  I'd think the parent should scroll
only if the child *is* at the end.

> it done(or I have another patch which allow the scrolling of the parent view

What do you mean by "stop scrolling"?  not scroll unless the child
is at the end?  I don't see what scrolling would be happening that
would be stopped.

> only if part of child view is not visible and stop until it become totally visible).

Comment 31

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 198981 [details] [diff] [review]
Not simply blocking the scroll of parent view, I made some restriction on scrolling parent view

minusing review request until questions are answered.  Roc might be a better reviewer for this patch, though.

Comment 32

[Michael Klepikov]

Attachment: Reproducible in Thunderbird 3 alpha1 (20061221)

This reproduces with regular scrolling using the scrollbar to the right of the message composer address pane -- clicking on the up/down buttons of the scrollbar, dragging the scrollbar slider. No need to try to drag selection on the addresses themselves.
With keyboard navigation the addresses show up fine -- using up/down arrows or ENTER.

Comment 33

[Wayne Mery (:wsmwk)]

still see this with current trunk

Comment 34

[Mats Palmgren (inactive)]

Wayne, do you have steps to reproduce?  on which platform?
(WFM, TB3 on OSX)

Comment 35

[Wayne Mery (:wsmwk)]

exactly per comment 0.  specifically, there must be enough addresses to cause a scroll bar to appear

vista, Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091127 Shredder/3.0.1pre

Comment 36

[Mats Palmgren (inactive)]

ok, I can reproduce it on OSX now, thanks.  Looks like the scrolling
is correct, except we're not invalidating the view as we should.

Comment 37

[Wayne Mery (:wsmwk)]

Not applicable in newer versions