Closed Bug 79775 Opened 23 years ago Closed 21 years ago

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

Categories

(MailNews Core :: Composition, defect, P1)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.0.1

People

(Reporter: mscott, Assigned: rpotts)

References

Details

(Keywords: regression)

Attachments

(5 files)

screenshot
33.82 KB, image/jpeg
Details
printf added through msgcompose and mime
9.45 KB, patch
Details | Diff | Splinter Review
Possible hack-ish fix. Jean-Francois, can you test this?
1.54 KB, patch
Details | Diff | Splinter Review
New patch - fixed the nits
1.56 KB, patch
Details | Diff | Splinter Review
Patch that doesn't crash
1.42 KB, patch
Details | Diff | Splinter Review 
Using a windows build from yesterday night: 2001050812, hitting forward doesn't
bring up a compose window. Nothing seems to happen.
re-assigning to varada.
Assignee: ducarroz → varada
Keywords: nsbeta1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.1
Severity: normal → major
QA Contact: esther → sheelar
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
*** Bug 79783 has been marked as a duplicate of this bug. ***
Even I start mail with -mail from the command prompt, forward is still not 
working....
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.
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.
Status: NEW → ASSIGNED
sheela. Try using argument "-mail -console" to see if you get any JS error on
the console when you press the forward button.
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.
i don't see this either.  I wonder if this is related to 79768?
Priority: -- → P1
varada,
I am using today's build on win98 buildid: 2001050906 commercial build.
actually it happens only if your default is set to Forward inline, forwarding as
an attachment works fine
maybe the summary should be changed to "forward as an attachment doesn't work"
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
Status: ASSIGNED → NEW
*** Bug 79768 has been marked as a duplicate of this bug. ***
I see the same problem - able to reproduce in Release build WinNT 2001050904 but
not in the debug build.
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!!!
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?
I haven't tried a debug build.
reassign to varada
Assignee: ducarroz → varada
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.
Oops, I meant forwarding inline does not work, as attachment does.
Attached image screenshot — 

    
    

    
  
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.

    
    

    
  
Marking Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
Varada closed the bug by accident! Reopen
Status: RESOLVED → REOPENED
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...

    
    

    
  
checked in the patch above.

    
    

    
  
I grabbed this morning first build, installed it on my PC and gess what? Forward
worked.

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_:

printf("___TRACE___BUG_79775___CP#024___\n");
  nsCOMPtr<nsIDOMWindow> newWindow;
  rv = wwatch->OpenWindow(0, chrome && *chrome ? chrome : DEFAULT_CHROME,
                 "_blank", "chrome,dialog=no,all", msgParamsWrapper,
                 getter_AddRefs(newWindow));

if (NS_FAILED(rv))
printf("___TRACE___BUG_79775___CP#025___\n");
else
printf("___TRACE___BUG_79775___CP#026___\n");
  return rv;


    
    

    
  
cc'ing damn as he change nsMsgComposeService.cpp on April 10th to use
nsIWindowWatcher::OpenWindow.

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
failed!

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
Status: REOPENED → NEW

    
    

    
  
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...
Status: NEW → ASSIGNED

    
    

    
  
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 = 
            NS_REINTERPRET_CAST(nsIScriptContext*,JS_GetContextPrivate(cx));
        if (scriptContext)
        {
            nsCOMPtr<nsIScriptGlobalObject> global =
scriptContext->GetGlobalObject();
            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 mstoltz@netscape.com, r=jst@netscape.com

adding mstoltz to cc list. mstoltz, any idea?

    
    

    
  
At this point, I gave up :-(
Reassign to mstoltz@netscape.com
Assignee: ducarroz → mstoltz
Status: ASSIGNED → NEW

    
    

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

___TRACE___BUG_79775___CP#001___
___TRACE___BUG_79775___CP#022___
___TRACE___BUG_79775___CP#023___
___TRACE___BUG_79775___CP#024___
___TRACE___BUG_79775___CP#026___
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.


    
    

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

    
    

    
  
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.  

    
    

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

    
    

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



    
    

    
  
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

    
    

    
  
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. 

    
    

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

    
    

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

    
    

    
  
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?

    
    

    
  
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

    
    

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

    
    

    
  
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. ***

    
    

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

    
    

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

    
    

    
  
*** Bug 80344 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 80828 has been marked as a duplicate of this bug. ***

    
  
Keywords: mostfreq, 
          
            nsdogfood

    
    

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

    
    

    
  
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

    
    

    
  
*** Bug 81058 has been marked as a duplicate of this bug. ***

    
    

    
  
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?
Status: NEW → ASSIGNED
Whiteboard: [nsbeta1+] → [nsbeta1+] fix in hand

    
    

    
  
R=ducarroz

    
    

    
  
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
file.

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!).


    
    

    
  
Mike,
  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.

    
    

    
  
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?


    
    

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

    
    

    
  
*** 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.

    
    

    
  
r=vidur.

    
  
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
Status: ASSIGNED → NEW
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

    
  
Blocks: 104166

    
    

    
  
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 
moved)
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 :-<)


    
    

    
  
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
Status: NEW → RESOLVED
Closed: 23 years ago → 21 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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: