Doing forward inline, edit message as new or edit as draft in the 3-pane won't bring up a compose window



18 years ago
10 years ago


(Reporter: mscott, Assigned: rpotts)



Windows 2000

Firefox Tracking Flags

(Not tracked)



(5 attachments)



18 years ago
Using a windows build from yesterday night: 2001050812, hitting forward doesn't
bring up a compose window. Nothing seems to happen.

Comment 1

18 years ago
re-assigning to varada.
Assignee: ducarroz → varada
Keywords: nsbeta1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.1


18 years ago
Severity: normal → major
QA Contact: esther → sheelar

Comment 2

18 years ago
buildid:  2001050906 win98
I see this too on the above build. But only when you launch mail from the
browser tasks menu item.  I checked that if you start mail with -mail from the
command prompt forward works fine and brings up the compose window. Adding
regression to the keyword
Keywords: regression

Comment 3

18 years ago
*** Bug 79783 has been marked as a duplicate of this bug. ***

Comment 4

18 years ago
Even I start mail with -mail from the command prompt, forward is still not 

Comment 5

18 years ago
Nope, I take it back. Now I am not able to forward no matter how I launch mail. 
I can swear that same build I could forward when I launched with -mail.  Not 
anymore.  I also noticed that when you click on forward button and close the 
application Netscp6 is still running in the task manager. I have to kill the 
application from the task manager to be able to launch again.

Comment 6

18 years ago
I am using today's release build - Win NT 2001050904- able to forward - and
close the application without any hanging or showing up in the task manager.
Sheela could you let me know what platform and OS this is happening.
sheela. Try using argument "-mail -console" to see if you get any JS error on
the console when you press the forward button.

Comment 8

18 years ago
I did the -mail - console and I did not see any JS error in the console.
Clicking forward button did not change anything in the console.

Comment 9

18 years ago
i don't see this either.  I wonder if this is related to 79768?
Priority: -- → P1

Comment 10

18 years ago
I am using today's build on win98 buildid: 2001050906 commercial build.

Comment 11

18 years ago
actually it happens only if your default is set to Forward inline, forwarding as
an attachment works fine

Comment 12

18 years ago
maybe the summary should be changed to "forward as an attachment doesn't work"

Comment 13

18 years ago
oops... in my last comment i meant "Forward inline not working"
I can reproduce the problem using today's release build. But I cannot with my
debug build!

only Forward inline is broken, and this with either the forward button of the
menu item Forward or Forward inline.
Forward inline, open draft, open template or edit message as new all use the
same code patch, the draft path. Therefore I suspect something broke in mime as
it take care of draft. Reassign to myself...
Assignee: varada → ducarroz
*** Bug 79768 has been marked as a duplicate of this bug. ***

Comment 17

18 years ago
I see the same problem - able to reproduce in Release build WinNT 2001050904 but
not in the debug build.

Comment 18

18 years ago
I see this bug now.  It started happening after I restarted my build.
The problem doesn't occurs with last night release build. Also, I build a
optimized build on my PC and... I am still *not* able to reproduce it!!!

Comment 20

18 years ago
This bug is intermittent for me.  On the same build that I said worked and then
I said didn't work, I can now say works for me.  So there's a possibility that
some of the builds you think work really don't work if you try long enough.
did you ever been able to reproduce it with a debug build?

Comment 22

18 years ago
I haven't tried a debug build.
reassign to varada
Assignee: ducarroz → varada

Comment 24

18 years ago
I'm seeing this on a Macintosh, exactly as described (forwarding inline doesn't
givce a compose window, inline does).  Using buildID 2001-05-10-05.  barrettl
reported seeing it on hpux too.  Platform/OS should be changed too, I reckon.

Comment 25

18 years ago
Oops, I meant forwarding inline does not work, as attachment does.

Comment 26

18 years ago
Created attachment 33948 [details]

Comment 27

18 years ago
See screenshot above.  Each time you hit Forward but no compose window, you get
a new 'blank menu item' greyed out under the Tasks menu.

Comment 28

18 years ago
Marking Fixed.
Last Resolved: 18 years ago
Resolution: --- → FIXED
Varada closed the bug by accident! Reopen
Resolution: FIXED → ---
So far, after 2 days of work on this bug by varada and myself, the only info we
have is that the JS code correctly call nsIMsgComposeService::OpenComposeWindow.
After that we don't have any clue why and where it failed.

As the only way to reproduce the problem is to use a commercial build installed
with the installer, I have decided to add a bunch of printf through the code to
try to figure out what append...
Created attachment 34046 [details] [diff] [review]
printf added through msgcompose and mime
checked in the patch above.
I grabbed this morning first build, installed it on my PC and gess what? Forward

But when I restarted the Netscape6 with -console, forward stoped working, oh thanks!

the trace I got show that everything seems ok until _CP#024_. For some unknown
reason, the last step, the call to nsIWindowWatcher::OpenWindow failed, I get
then the _CP#025_ instead of the _CP#26_:

  nsCOMPtr<nsIDOMWindow> newWindow;
  rv = wwatch->OpenWindow(0, chrome && *chrome ? chrome : DEFAULT_CHROME,
                 "_blank", "chrome,dialog=no,all", msgParamsWrapper,

if (NS_FAILED(rv))
  return rv;
cc'ing damn as he change nsMsgComposeService.cpp on April 10th to use

Here is wha append in short:

With a commercial release build, most of the time, when the user try to forward
a message inline, the msg compose window doesn't come up. However a blank menu
item is added at the end of the task menu. The call nsIWindowWatcher::OpenWindow

Damn, any idea?

here is maybe a clue, despite I don't really see any problem:

how this line would be intepreted:
    chrome && *chrome ? chrome : DEFAULT_CHROME

used to be before danm change:
    (chrome && *chrome) ? chrome : DEFAULT_CHROME

good news, I am able to reproduce the problem with my onw release dll I build
with the following step:

1) Install a recent commercial build, using Netscape6 installer
2) build a optimized build (set MOZ_DEBUG=, set BUILD_OPT=1)
3) Replace msgcompo.dll in your install with the one you have just generated
4) Remove the component registry file
5) Start Netscape 6
6) Quit Netscape 6
7) Start again Netscape6
8) Try to Forward...
Assignee: varada → ducarroz

Comment 37

18 years ago
Seems mailto links don't work either. Clicking on a mailto link will cause Blank
menu items to appear under the Tasks menu similar to forwarding (see screenshot
attachment of 5/10/01 14:49).

BTW, I've been seeing all this on a Mac, but I tried it on a recent trunk build
on hpux, and I didn't see it.
the failure code return by nsIWindowWatcher::OpenWindow is 0x80004005
(NS_ERROR_FAILURE). The chrome passed to the function is ok. Let's debug
nsIWindowWatcher::OpenWindow now...
we are failing in nsWindowWatcher.cpp line 635:

    if (NS_FAILED(secMan->GetSubjectPrincipal(getter_AddRefs(principal))))
      return NS_ERROR_FAILURE;

because secMan->GetSubjectPrincipal return NS_ERROR_FAILURE!

adding jst to the cc list. jst, any idea?
secMan->GetSubjectPrincipal faild because scriptContext->GetGlobalObject return
nsnull in nsScriptSecurityManager.cpp, line 1130:

    //-- If there's no principal on the stack, look at the global object
    //   and return the innermost frame for annotations.
    if (cx) 
        nsCOMPtr<nsIScriptContext> scriptContext = 
        if (scriptContext)
            nsCOMPtr<nsIScriptGlobalObject> global =
            NS_ENSURE_TRUE(global, NS_ERROR_FAILURE);

I found the following checkin comment on nsScriptSecurityManager.cpp on Tuesday
05/08 at 7:53PM:

Temporary workaround for the composer and other related problems caused by
security manager problems, change by,

adding mstoltz to cc list. mstoltz, any idea?
At this point, I gave up :-(
Reassign to
Assignee: ducarroz → mstoltz

Comment 43

18 years ago
On a CVS build, Linux, some hours old, i often see this when merely hitting the
"new msg" button:

Compose: ComposeStartup
[nsIMsgIdentity: id1],[nsIMsgIdentity: id2],[nsIMsgIdentity: id3]
Registering plain text editor commands
Have Find = true
Have SpellChecker = false
replacing child in comp fields 2 recips 
Warning prev sibling is not in our list!!!set focus on the recipient
I removed the all the trace printf added earlier.

Comment 45

18 years ago
mstoltz, when you get a chance, can you look at this?  This is a pretty
important bug to fix for mailnews.
Keywords: mailtrack

Comment 46

18 years ago
I've logged bug 80708, Edit as New and Double clicking on Templates won't bring 
up the Compose window, I'll mark that dup of this.  Wasn't sure if ducarroz 
comment on 5-9 was reporting that these are broke too or just that they all use 
the same code.  

Comment 47

18 years ago
*** Bug 80708 has been marked as a duplicate of this bug. ***

Comment 48

18 years ago
working with 2001-05-14-06 build on WinNT... 
Reply works, New works... but Forward doesn't bring up compose window

Comment 49

18 years ago
I'm changing the summary to reflect that fact that it's not working for forward
inline.  If forward inline is the default then the toolbar button work work.  
Summary: Hitting the forward button in the 3-pane won't bring up a compose window → Doing forward inline in the 3-pane won't bring up a compose window

Comment 50

18 years ago
Using today's build 2001-05-14 on win.  The Forward and Edit as New worked the 
first time I launched mail.  After closing and reopening the app, I can't use 
Forward, Edit as New or the Edit Button on a Draft.  And editing Templates 
didn't work as before.  This is more than what the Summary states, let me check 
with others in the group to see if they have the same problem on 2nd launch. 

Comment 51

18 years ago
i am wondering if this behavior is not similar to the one i described in bug # 

Comment 52

18 years ago
*** Bug 80299 has been marked as a duplicate of this bug. ***

Comment 53

18 years ago
This is confirmed. These work the first time the app launches, but don't work 
again from then on.  Scott do we want to change the Summary again?

Comment 54

18 years ago
I'm changing the summary.  If we find anything else feel free to change this to
"most actions that bring up a compose window"
Summary: Doing forward inline in the 3-pane won't bring up a compose window → Doing forward inline, edit message as new or edit as draft in the 3-pane won't bring up a compose window

Comment 55

18 years ago
*** Bug 80776 has been marked as a duplicate of this bug. ***

Comment 56

18 years ago
Also note: Windows only, when attempting to do any of these actions, then 
closing the app, we still have the process open.  User can't launch again until 
the Ctrl+Alt+Del.

Note: this is only if the user does a File|Close to end the app instead of 
File|Exit.  File|Close should end the process too.  

1. Launch app using -mail
2. Open a mail account and select a message. 
3. Select Message|Edit Message as New
4. Wait 30 seconds or so, then do a File|Close

Result:  App appears to be ended, but the process is still running, see the Task 
Manager.  User can't relaunch until they Ctrl+Alt+Del
Expected:  The app should not be running, allowing user to relaunch it.
*** Bug 80811 has been marked as a duplicate of this bug. ***

Comment 58

18 years ago
*** Bug 80813 has been marked as a duplicate of this bug. ***

Comment 59

18 years ago
*** Bug 80824 has been marked as a duplicate of this bug. ***

Comment 60

18 years ago
*** Bug 80344 has been marked as a duplicate of this bug. ***
*** Bug 80828 has been marked as a duplicate of this bug. ***


18 years ago
Keywords: mostfreq, nsdogfood

Comment 62

18 years ago
As a workaround, changing your forward pref to "as attachment" gets the button
working again immediately.

Comment 63

18 years ago
changing to blocker severity.  This is making it hard to test a lot of bug
reports in addition to making the product hard to use.
Severity: major → blocker

Comment 64

18 years ago
*** Bug 81058 has been marked as a duplicate of this bug. ***
Created attachment 34672 [details] [diff] [review]
Possible hack-ish fix. Jean-Francois, can you test this?
Yes, I'll...
I have applied the patch, generated my own optimized embeddingcomponents.dll and
tried today commercial build with and without this custom dll: That seems to fix
the problem! I said "seems" because due to the volatility of this bug, we need
to do a real life test in order to confirm it! Therefore I would say Check it In
and we will see tonight or tomorrow if it still works. Thanks
Jean-Francois, can I get your r= on this patch?
Whiteboard: [nsbeta1+] → [nsbeta1+] fix in hand
Please fix the mixture or 4 and 2 space indentation in this patch before
checking in, be consistent.
- Please check return code for SchemeIs. URIs are pluggable, and you can't trust
the out param in the case of failure.
- Brace placement after the if (isChrome) is inconsistent with the rest of the

I don't understand, after reading this bug, why we want to skip this code for
chrome.  Can you explain it to me?

Also, I'd like a review from danm and/or jst, who are, I think, more familiar
with the window-watcher code than Jean-François is (no offense, J-F!).
  The call to GetSubjectPrincipal is failing under hard-to-reproduce conditions
in mailnews. Fortunately, the URL to be laoded is always chrome in these cases,
and it so happens (in docshell) that the "owner" attribute of
nsIDocShellLoadInfo, which is what the code in question is trying to fill, is
ignored in the case of chrome URLs (actually, it's only relevant for javascript
URLs). So, we can safely skip that code and avoid the failure in mailnews.
Created attachment 34906 [details] [diff] [review]
New patch - fixed the nits
So why not just check if it _is_ javascript, and set the data then?  (Fatal
assertions might help you track down the hard-to-reproduce case, and I'd like it
if we kept this bug open until we knew what that case was, and what the effects
of the failure are.)
Fine with me if we leave this bug open, but we need some sort of fix ASAP. The
reason it specifically excludes chrome was to be as security-conservative as
possible, and get the principal in all other cases. In other words, alter the
behavior of this function as little as possible. I don't see how that affects a
post-0.9.1 effort to find the root cause of this bug.

After next Tuesday, anyone who wants to can spend all the time they want finding
the root cause of this bug, which only shows up in optimized builds, and only
when installed using the installer. In the meantime, this fixes the problem, and
there's no risk in not providing information to docshell which wasn't getting
used anyway.
If there's no risk in not setting the data where it's not used, and it's only
used for JavaScript, then I ask again: why not just check for javascript: and
speed up other URL loads a smidge?

Comment 77

18 years ago
*** Bug 81345 has been marked as a duplicate of this bug. ***

Comment 78

18 years ago
*** Bug 81470 has been marked as a duplicate of this bug. ***
Given the severity of this problem I want this checked in ASAP, therefrore I'll
say sr=jst here.

Also, the performance hit for doing getting the principal and creating the
loadinfo to pass along is minimal I'm ok with the check being exclusive for
chrome url's, this does minimize the impact of this change, and what's done here
(i.e. passing the principal to the docshell) is changing soon anyway...

This bug should remain open for finding a fix for the real problem here.
FYI I backed out the fix for this.
sr=jst for the updated patch.

Comment 83

18 years ago


18 years ago
Whiteboard: [nsbeta1+] fix in hand → [nsbeta1+] fix in hand - critical for 0.9.1
Workaround checked in, which avoids the problem, but we're still not sure what
causes it. Moving to 0.9.2 and reassigning to rpotts, who might have a better
idea about this. Please reassign if necessary.
Assignee: mstoltz → rpotts
Severity: blocker → normal
Keywords: nsdogfood
Whiteboard: [nsbeta1+] fix in hand - critical for 0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Triaging on behalf of rpotts/judson. Re-targeting to Mozilla 1.0. 
Target Milestone: mozilla0.9.2 → mozilla1.0


17 years ago
Blocks: 104166

Comment 86

17 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
Target Milestone: mozilla1.0 → mozilla1.0.1
(I am not seeing this bug (in v1.3a by now), but I +/- read it while searching
for another one.)

After comment 79, should this bug be maintained opened yet ?

Making a (really) big guess, but I could be lucky:
Could this be somehow related to bug 169777 ?
(Don't blame me if irrelevent :-<)

Comment 88

15 years ago
No response from reporters to comment 87, and I have never seen this problem 
since starting to use Mozilla for my mail, back around 1.0.   =>WFM
Last Resolved: 18 years ago15 years ago
Resolution: --- → WORKSFORME
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.