Closed Bug 141051 Opened 23 years ago Closed 23 years ago

[RC 1.0 bug] New email window shows briefly old subject

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: dneri98, Assigned: bugzilla)

References

Details

(Keywords: privacy, Whiteboard: have fix [adt2 rtm] [Needs a=])

Attachments

(2 files)

Proposed branch fix, v1
553 bytes, patch
vparthas
: review+
bugzilla
: superreview+
Details | Diff | Splinter Review
Proposed trunk fix, v2
2.31 KB, patch
vparthas
: review+
mscott
: superreview+
brendan
: approval+
Details | Diff | Splinter Review
Build: RC1.0 (2002.04.15.03) OS: WinNT 4.0 sp5 Steps to reproduce: 1. Write an email...be sure to include a subject. 2. Send the email. 3. Create a new email message. 4. While the new window is spawning, look at the titlebar. It will temporarily display the previous subject. Reproduceability: Always Notes: Marking major as this is a potential security issue.
Not browser, and not composer.
Assignee: syd → ducarroz
Component: Editor: Composer → Composition
Product: Browser → MailNews
QA Contact: sujay → esther
Whiteboard: DUPEME
look like we need to fully cleanup the compose window on close instead on open
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
i think this should be closed,i can not reproduce this bug.use 2002/05/08 build on windows2000
I'm able to reproduce it under RC2 (2002051006) on Win2k. This should NOT be closed!
Anyone want to change the Summary to be RC2? Also, I made up the [] without guidance; someone want to make it standard as well?
nominating nsbeta1
Keywords: nsbeta1, privacy
Summary: [RC 1.0 bug] New email window shows old subject → [RC 1.0 bug] New email window shows briefly old subject
Whiteboard: DUPEME
Target Milestone: mozilla1.0.1 → mozilla1.0
We were correctly erasing the subject line but we weren't reseting the window title when recycling the compose window therefore the previous subject was showing up briefly in the title when reopening the compose window. This patch will take care of that.
Whiteboard: have fix
Comment on attachment 83770 [details] [diff] [review] Proposed branch fix, v1 Looks good to me r=varada. The passing of the event value - can it be removed altogether or is it necessary for debugging purposes.
Comment on attachment 83770 [details] [diff] [review] Proposed branch fix, v1 Looks good to me r=varada. The passing of the event value - can it be removed altogether or is it necessary for debugging purposes.
Attachment #83770 - Flags: review+
You are right, we are not using the event anymore, I'll clean up the code...
Remove unused parameter in function SetComposeWindowTitle()
Attachment #83770 - Attachment is obsolete: true
Comment on attachment 83781 [details] [diff] [review] Proposed trunk fix, v2 YAY!! we got rid of another few extra lines :-) r=varada
Attachment #83781 - Flags: review+
Attachment #83781 - Flags: superreview+
Comment on attachment 83781 [details] [diff] [review] Proposed trunk fix, v2 sr=mscott
Fix checked in the trunk. This is a safe fix we should consider to take for rtm
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Many thanks for the quick turnaround! :)
Keywords: nsbeta1 → adt1.0.0, nsbeta1+
Whiteboard: have fix → have fix [adt2 rtm]
adt1.0.0+ (on ADT's behalf) for approval to checkin to the 1.0 branch, pending Driver's approval . After, checking in, please add the fixed1.0 keyword.
Blocks: 143047
Keywords: adt1.0.0 → adt1.0.0+, approval
Whiteboard: have fix [adt2 rtm] → have fix [adt2 rtm] [Needs a=]
It looks like the only fix is the first hunk in the first file in the patch, and the rest is cleanup to remove a mostly-useless parameter. I'll approve, but pls. check my analysis here. /be
Blocks: 143200
Comment on attachment 83781 [details] [diff] [review] Proposed trunk fix, v2 a=brendan@mozilla.org for 1.0 checkin today (or you will miss the boat). /be
Attachment #83781 - Flags: approval+
Brendan, you are totally right. Too play 100% safe I can check only the patch v1 in the branch which does only the strict minimum (without the clean up part). Let me know asap...
Attachment #83770 - Attachment description: Proposed fix, v1 → Proposed branch fix, v1
Attachment #83770 - Attachment is obsolete: false
Attachment #83781 - Attachment description: Proposed fix, v2 → Proposed trunk fix, v2
Comment on attachment 83770 [details] [diff] [review] Proposed branch fix, v1 sr=mscott (from patch v2)
Attachment #83770 - Flags: superreview+
I've approved patch v2, but it makes it a lot easier on drivers' fried brains (ADT's too) if you minimize patches in the end-game. Please do so in the future -- thanks. /be
Patch v1 checked in the branch
Keywords: fixed1.0.0
oops, I forget to wait for Brendan answer! And I have checked in the patch v1 which is the same than v2 but without the extra cleanup did in v2.
Let's quit while we're ahead :-). Job done, /be
using branch build 20020522 on winxp, mac 9.1 mac 10.1 and linux this is fixed. Verified. Note: I never saw the problem on linux, but I did see it on the other platforms, but verified on all.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.0 → verified1.0.0
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: