31108 - Can not scroll after 3 emails in to, cc, and bcc fields

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P1)

Description

[bijals (gone)]

Steps:
1) Open a new email compose dialog
2) Type test1 and hit return
3) Next line, type test2 and hit return
4) Next line, type test3 and hit return
(You will not have 3 emails as TO fields)
5) Go to the scoll bar and go to [e-mail]
6) Next blank lin, type test4 and hit return
7) Scroll again

Actual Results: Can not scroll to top email or scrolling leaves bottom line blank

Expected Results: Can scroll to any email address

Build Date/Platform: WinNT with 3/9/00 late build

Comment 1

[lchiang]

this should be fixed for beta1.

Comment 2

[Jean-Francois Ducarroz]

I can see this problem on my Windows debug build from this morning. However, it 
works fine on Mac with a debug build pulled about the same time (30 minute 
earlier).

If I set a different recipient type (to, cc, bcc, etc...) for each entry, I can 
see that the select element scroll normally but not the edit field. It's maybe a 
side effect of buster recent fix about gfxTextWidget position. Reassign to 
buster, cc'ing hyatt.

Must be fixed for B1, must be a PDT+.

Comment 3

[leger]

Putting on PDT+ radar for beta1.  MUST FIX ASAP!

Comment 4

[buster]

fix is trivial, though I'm not sure why the code I wrote is necessary.  All I do 
is manually reposition the view, something nsContainerFrame::FinishReflowChild() 
should do for me.  Hyatt, when the text control gets recreated in response to 
scrolling, can you verify that 
nsContainerFrame::FinishReflowChild(textControlFrame)
gets called?

Comment 5

[Jim Roskind]

Sounds like we need a review from Hyatt.
Hyatt: Comments??
When reviewed, get Chofmann to schedule a landing plan, and post that date to
the status whiteboard.
Thanks,
Jim

Comment 6

[buster]

hyatt or troy could review this.  my question to hyatt was mostly wondering out 
loud why this doesn't work automatically in the tree widget (and only the tree 
widget, as far as I know.)

Comment 7

[buster]

diff for ricky:

cvs server: Diffing .
Index: nsGfxTextControlFrame.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/forms/src/nsGfxTextControlFrame.cpp,v
retrieving revision 3.149
diff -r3.149 nsGfxTextControlFrame.cpp
2358a2359,2374
>       nsCOMPtr<nsIPresShell> presShell;
>       rv = aPresContext->GetShell(getter_AddRefs(presShell));
>       if (NS_FAILED(rv)) { return rv; }
>       if (!presShell) { return NS_ERROR_FAILURE; }
>       nsIView *view;
>       GetView(aPresContext, &view);
>       if (view)
>       {
>         nsCOMPtr<nsIViewManager> viewMan;
>         presShell->GetViewManager(getter_AddRefs(viewMan));
>         if (!viewMan) { return NS_ERROR_FAILURE; }
>         nsIView* parView;
>         nsPoint origin;
>         GetOffsetFromView(aPresContext, origin, &parView);
>         viewMan->MoveViewTo(view, origin.x, origin.y);
>       }

Comment 8

[buster]

pref removed, fixed, on both branch and trunk

Comment 9

[laurel]

Scrolling to all email address lines is OK (plain text and html compose
windows). This is ok when using all one type of header, all different headers,
changing headers after entering addressees.

Using:

2000-03-13-18-nb1b commercial build NT 4.0
2000-03-14-05-nb1b mozilla build linux rh6.0
2000-03-14-05-nb1b mozilla build mac OS 9.0

I'm not sure if this is exactly what ducarroz refers to in his 3/09 comments,
but I see this lingering issue (Win32 only) which I'll separate into another
bug:

1.  Open compose window.
2.  Type addr1 then Enter.
3.  Type addr2 then Enter.
4.  Type addr3 then Enter.
5.  Scroll upward to top address line.
    Result:  Address lines 2 and 3 now show the same addressee. (If sent, the
real, separate addressees are honored.)

Logged above issue as bug #31832.

Closing this bug (scroll to all address lines) as verified in beta branch, will
also check in trunk/m15 build.

Comment 10

[buster]

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

Comment 11

[laurel]

If you're marking bug #31832 as a duplicate of this, then I guess I'll reopen
this one...

Comment 12

[buster]

before you reopened this, did you try today's build?  the fix was checked in 
yesterday.

Comment 13

[laurel]

I tried in last night's beta Win32 build since there's none today!  It's from
6pm last night and your comments indicated you checked in around 2pm.  I thought
the fixes would be caught since we're in prep-for-beta mode, but will try again
when we get a build today.

Comment 14

[Jim Roskind]

Please mark this bug as fixed, and open a second bug for the "third line
incorrectly displays the same text as the second line."  I don't know if the new
bug will get a PDT+, but it is different enough that it should be judged separately.
In addition, we need to mark this bug as closed with a PDT+ so that it will be
verified.
Thanks,
Jim

Comment 15

[laurel]

Marking this one fixed again. Will assess this and symptom from bug #31832 again
in the next win32 beta build.

Comment 16

[buster]

thanks, laurel!

Comment 17

[laurel]

OK, everyone:
I tested this again with 2000-03-15-06-nb1b commercial build on NT 4.0.
Same results as yesterday -- I can scroll to all email address lines, but there
is a problem where address lines will mimic another line's address as I
mentioned in bug #31832.

So, I'm going to mark this one verified and reopen bug #31832 to stand on its
own (according to comments by jar requesting a separate bug).

Comment 18

[lchiang]

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