Closed Bug 24950 Opened 26 years ago Closed 26 years ago

prefiled recipient in Msg Compose doesn't show up until you click in it

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Other
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mscott, Assigned: buster)

References

Details

(Whiteboard: [PDT+] landing 2/14?)

Using a fresh build from this morning for M14: 1/24/00, if I am viewing a web page or reading a message with a mailto url in it and I click on that url, the compose window comes up but it is blank!! i.e. clicking on mailto:mscott@netscape.com brings me a compose window with the To field empty instead of addressed to mscott@netscape.com. Jean-Francois, I've traced this through and we are creating the url correctly, extracting the to field correctly from the url. And then we call open openWindow in nsMsgComposeService.cpp which passes in a field comp item. We never try to read the headers out of the msg compose fields object. I suspect these problems may be related to the stuff you checked into M13 and M14 Friday afternoon. If so, we may need to consider this as a regression fix to go into m13 too...otherwise just M14.
Works fine for me!
Scott - this works for me in M13 build from today (win32).
so, it may be a problem in M14 only.
Works for me with a M14 build from today at around 11am. Will check again tomorrow...
QA Contact: lchiang → laurel
Actually the problem isn't with mailto urls. Bringing up a new compose window or hitting reply has the same problem!! The editor instance is DOA and the To / cc info isn't filled in. I just repulled before lunch and still see it. Marking as dogfood
Summary: Clicking on embedded mailto urls come up with blank information → [DOGFOOD] Clicking on embedded mailto urls come up with blank information
Adding to the blocker list for today. On windows, the compose window is totally defunct. You can't send mail today. Jean-Frnacois, can you please take a look at this as soon as you can. We may hold the tree closed for this.
Summary: [DOGFOOD] Clicking on embedded mailto urls come up with blank information → [DOGFOOD] [BLOCKER] Clicking on embedded mailto urls come up with blank information
Severity: normal → blocker
I still not able to reproduce the problem either on my Mac or on my PC with debug build from today. I just spok with mscott and apparently the problem is due to some local change he has in WebShell. He is backing up his change...
Status: NEW → ASSIGNED
Removing blocker status. We'll still use this to track the fact that sometimes the To/cc fields aren't showing up when you reply to a message or hit a mailto link. (this is the same symptom that waterson reported in the builds today). Somehow these things don't show up unless you force an extra reflow.
Summary: [DOGFOOD] [BLOCKER] Clicking on embedded mailto urls come up with blank information → [DOGFOOD] Clicking on embedded mailto urls come up with blank information
Putting on PDT+ radar.
Whiteboard: [PDT+]
update summary
Summary: [DOGFOOD] Clicking on embedded mailto urls come up with blank information → [DOGFOOD] prefiled recipient in Msg Compose doesn't show up until you click in it
Target Milestone: M14
Sound to be a reflow problem with text field widget. Reassign to editor folk for investigation.
Assignee: ducarroz → beppe
Status: ASSIGNED → NEW
*** Bug 25586 has been marked as a duplicate of this bug. ***
reassign to buster
Assignee: beppe → buster
Putting dogfood in the keyword field.
Keywords: dogfood
Whiteboard: [PDT+] → [PDT+] landing 2/14?
*** Bug 27090 has been marked as a duplicate of this bug. ***
Here is what I see on WinNT. If I click on a mailto URL, the recipient always shows up fine. If I reply to a mailnote, the recipient always shows up fine. If I reply-all to more than one person, the first recipient always shows up and the subsequent ones do NOT, until I click on them. Sometimes I get some odd scrolling behaviors. Sometimes I see the same recipient in the list more than once.
Status: NEW → ASSIGNED
Hi Steve, The problem occurs only with recipient rows that are created dynamically from JS. The xul file define only one row but when we need more than 1 recipient, I duplicate the row node to create a new row, once the row is created, I set the value in the select element and i the Input element. I've already had several problem (especially selection/focus) with those elements created on the fly because they seems to be fully operational only after the first reflow which appends only when the JS script is done. The best way to testing it is to enter the following mailto url into a browser window: mailto:qwe@qwe.com,asd@asd.com I have solved my focus problem by using a timer which call a JS function, this will append after the reflow. I'll quickly do a test to see if I reset the value after the reflow using this timer function solve the problem.
Resetting the value after the first reflow using a timer does not fix the problem!
Summary: [DOGFOOD] prefiled recipient in Msg Compose doesn't show up until you click in it → prefiled recipient in Msg Compose doesn't show up until you click in it
Here's what's going on. The second and all subsequent text controls are not getting incremental reflows in response to DocumentChanged(). They are getting reflows with reason=dirty instead. Here's some annotated debug output: ComposeLoad from XUL Compose: ComposeStartup [fieldsAddr=44049328] [format=0] [type=8] [nsIMsgIdentity: id1] WARNING: XXX Fix me!! Converting Dirty to Resize!! Table need to implement reflo w Dirty!!, file S:\mozilla\layout\xul\base\src\nsTreeOuterFrame.cpp, line 115 Created nsEditorShell Created editorShell editor initialized in HTML mode Attaching to WebShellWindow[_blank] First_Address_TextControl: set to "qwe@qwe.com" First_Address_TextControl: got reflow command incremental for reflow #41 First_Address_TextControl: got reflow command resize for reflow #42 awCopyNode Second_Address_TextControl: got reflow command initial for reflow 1 Second_Address_TextControl: got reflow command initial for reflow 2 Second_Address_TextControl got an initial reflow that was not my first reflow! Second_Address_TextControl: set to "asd@asd.com" Second_Address_TextControl: got reflow command dirty for reflow 3 set focus on the body notice that Second_Address_TextControl got a "dirty" reflow, not an "incremental" reflow, in response to a call to nsIDocument::ContentChanged(mContent, nsnull) at the bottom of nsGfxTextControlFrame::SetTextControlFrameState().
I seem to have fixed this.
hyatt fixed part of this. I fixed the rest. The REAL problem was the text control was indirectly firing off a recursive reflow to itself during initial relfow. very, very bad. the recursive reflow came from an innocent call to GetText(). that's been replaced with code that specifically checks the cached state and the content,'s attributes and never calls back to itself. it was the call from GetPrimaryFrame from the content node that caused the XUL document to flush pending reflow commands. this was checked in last night, should be able to verify against today's daily build.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Using 2000-02-14-08m14 commercial on NT 4.0: OK for mailto, reply and reply all cases. Using 2000-02-14-09m14 mozilla build on linux rh 6.0: OK for mailto and reply cases. Not okay for reply all, but I believe that is really evidence of bug #26618. No mac build yet today.
You need to have more than one address to verify this bug as the first recipient has always been displayed correctly.
Marking this verified. On all platforms recipients filled in properly, however bug #26618 still is incurred if reply-all to long recipient list. OK using 2000-02-16-08m14 mozilla build on NT 4.0 OK using 2000-02-16-08m14 mozilla build on linux rh6.0 OK using 2000-02-16-08m14 commercial build on mac OS 9.0
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.