Closed Bug 96899 Opened 20 years ago Closed 20 years ago
Scrolling up in address pane doesn't display the address
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) ;-)
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. ***
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.
*** 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 <http://bugzilla.mozilla.org/show_bug.cgi?id=94943>, which touches autocomplete.xml in a place that looks like it could be related to this: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=autocomplete.xml&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=08%2F16%2F2001&maxdate=08%2F18%2F2001&cvsroot=%2Fcvsroot I think that change is significantly more likely to have caused the behavior reported here.
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!
Status: NEW → ASSIGNED
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
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: "Result: 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
Status: ASSIGNED → NEW
Just got back from vacation. This bug is my top priority. I should have a fix soon.
Status: NEW → ASSIGNED
*** 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.
Comment on attachment 49409 [details] [diff] [review] Ugly hack alert. This works around the problem. r=mscott I'm always game for reviewing hacks =).
email@example.com, but open a new bug and cite its number here, to find and exterminate the underlying problem, or widget, or whatever. /be
*** 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.
Status: ASSIGNED → RESOLVED
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
*** 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.
Status: RESOLVED → VERIFIED
*** Bug 100496 has been marked as a duplicate of this bug. ***
*** Bug 101226 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.