Closed Bug 96899 Opened 20 years ago Closed 20 years ago

Scrolling up in address pane doesn't display the address.


(MailNews Core :: Composition, defect)

Not set


(Not tracked)



(Reporter: skasinathan, Assigned: hyatt)



(Keywords: regression, Whiteboard: PDT+)


(1 file)

1. Compose and  sent it to mutiple recepients. (In my case,  To:  is my email
id, and multiple (5+) Bcc address.)
2.  Scroll up to view the first address. The address aren't displayed.
3.  Similarly scroll down, you will not see any address.  When I click send the
msg is sent though. 

Build: today's trunk build on Win 2K. Also in 8/22 build.
Nominating for nsBranch.  (I hope it is the correct keyword) ;-)
Keywords: nsbranch
reassign to varada
Assignee: ducarroz → varada
*** Bug 96933 has been marked as a duplicate of this bug. ***
*** Bug 97356 has been marked as a duplicate of this bug. ***
Keywords: regression
OS: Windows 2000 → All
Hardware: PC → All
Adding Naving to cc list. This is the bug I was talking to you and stephend
about disappearing addresses. But your case may be different as you said, you
removed it from the address list and  the removed address recd the mail.
Well, this could very well be the reason because I scrolled up and down but I do
remember having
removed them also. Anyway this bug should be fixed for emojo.  changing
milestone to 0.9.5, 
though it would be good if we can get to it in this milestone.
Target Milestone: --- → mozilla0.9.5
cc mscott and sspitzer, this can be dangerous and I think it needs to be 
immediately addressed. 
Moving into .9.4. for investigation. Although I didn't see this using a build
from 8/27.
Target Milestone: mozilla0.9.5 → mozilla0.9.4
I take it back I do see this in todays builds. 

The good news is JF comes back on Tuesday so we can try to load balance this to
him Tuesday as varada has a lot of .9.4 bugs that are pretty important. adding
nsbranch+ keyword. This needs to be fixed for eMojo.
Keywords: nsbranchnsbranch+
*** Bug 97403 has been marked as a duplicate of this bug. ***
is this a tree widget painting regression? Seems strange that it could be as I
didn't think the tree widget code had changed in a long time. cc'ing the tree
widget expert.
I have tracked this down to the changes made on the 17th. The early morning
build is ok but the weekend builds are hosed. The likely target would be dmose's
autocomplete and ldap changes. The turning off of autocomplete and ldap seems to
get rid of this problem. I am CCing dmose and srilatha
I looked at my changes to MsgComposeCommands.js, and I really don't touch
anything that's not LDAP related, but this bug persists with even just local
directory autocomplete turned on.

So srilatha and I just tried using the "New List" feature of the addressbook,
which only does local autocompletes (and presumably doesn't go through
MsgComposeCommands.js), and it had essentially the same problem.  

So poking around with bonsai, we found that hyatt landed a big XUL change on the
17th <>, which touches
autocomplete.xml in a place that looks like it could be related to this:

I think that change is significantly more likely to have caused the behavior
reported here.
Taking it...
Assignee: varada → ducarroz
*** Bug 98039 has been marked as a duplicate of this bug. ***
It's also possible that the problem is caused by bryner checking in nsFrame.cpp!
1) The problem occurs only when the textfield value is set by the autocomplete
widget itself. If you type the full address yourself, the problem does not occurs.

2) I just did a build pull by date: 08/18/2001 00:00:00 and it has the problem
already. This build is before the both checkin we were suspecting!
I backed up peterlubczynski changes in nsObjectFrame.cpp (rev 1.248) but that
did not resolve the problem either.
The regression has been caused by one of the checking between 08/17/01 15:00 &
08/17/01 19:00. That give us a 4 hours window to look at...
The regression has been caused by David Hyatt check in for bug 94943. I cannot
find how exactly which part of it had caused the problem, maybe it had just
exposed it!

A build pulled on 08/17/2001 at 17:59 works while a build pulled on 08/17/2001
at 18:05 doesn't.

David, can you take a look please. Thanks
Sigh.  I guess reassign the bug to me.  I still don't understand what the bug
even is. :(
I'll come to see you tomorrow at the office...
*** Bug 98442 has been marked as a duplicate of this bug. ***
PDT+ per PDT
Whiteboard: PDT+
jf, hyatt - I'm assuming you spoke and now hyatt understands the severity of
this. But, just in case you haven't discussed this yet, lemme quote from my own
DUP filing on this bug:
Name at top is gone. A refresh does not bring it back (minimizing, or the like)
Here's the worst part: the name is really still there, because if you send the
message, it gets delivered to the "missing" addressee. BAD BAD BAD."
We should proabably mark this P1.
*** Bug 98380 has been marked as a duplicate of this bug. ***
Varada talked to hyatt last week and Dave understands the problem now. Varada
says this bug is supposed to go to hyatt. 
Assignee: ducarroz → hyatt
Just got back from vacation.  This bug is my top priority.  I should have a fix
*** Bug 99398 has been marked as a duplicate of this bug. ***
At least with the 0.9.4 branch build 2001091215 this problem doesn't occur if
one *replies* to a previous message - only with new addresses. You can reply and
the add new addresses until the addresses scroll off the top of the address
pane. When you scroll back all the addresses added will have become invisible
except the replied to address. So it's the text entry that has something to do
with this behaviour.
*** Bug 98680 has been marked as a duplicate of this bug. ***
*** Bug 99326 has been marked as a duplicate of this bug. ***
Well, I have a rather involved fix for 96291 that seems to solve that problem.
Unfortunately the fix for 96291 did not fix this bug.  So I'm back to square one
trying to figure out what the actual bug is here.  No fix forthcoming until I
can figure out what the real problem is.
*** Bug 99648 has been marked as a duplicate of this bug. ***
In case this helps troubleshoot:  I can see all the addresses if I maximize my
Mail Compose window.  The address is just clipped funny.
For some bizarre reason, the popupset is sizing itself around the popup child 
(something that should never happen), and this only seems to be happening when 
used inside a tree.  This is sufficiently rare and complicated that I'm just 
going to wallpaper over the problem for now with a cheap hack.

Looking for r/sr.
Attachment #49409 - Flags: review+
Comment on attachment 49409 [details] [diff] [review]
Ugly hack alert.  This works around the problem.


I'm always game for reviewing hacks =)., but open a new bug and cite its number here, to find and
exterminate the underlying problem, or widget, or whatever.

*** Bug 99723 has been marked as a duplicate of this bug. ***
0.9.4 is out the door
Target Milestone: mozilla0.9.4 → mozilla0.9.5
*** Bug 99863 has been marked as a duplicate of this bug. ***
looks like this one is ready.  lets get it on the branch soon to shake it out.
Fixed on branch and trunk.
Closed: 20 years ago
Resolution: --- → FIXED
verified this on the following branch build. Adding keyword vtrunk since this 
needs verification on the trunk builds. 

win98-0.9.4 -2001-09-19-05
linux&mac-0.9.4 -2001-09-19-04
Keywords: vtrunk
*** Bug 101476 has been marked as a duplicate of this bug. ***
verified on trunk builds:
2001-09-25-05 win98, mac OS 9.1, linux RH 6.2
remove keyword vtrunk since it is verified on the trunk build too. 
Keywords: vtrunk
*** Bug 100496 has been marked as a duplicate of this bug. ***
*** Bug 101226 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.