Closed Bug 631524 Opened 13 years ago Closed 13 years ago

Send to ...E-Mail Recipient opens browser window instead Mail Editor

Categories

(SeaMonkey :: OS Integration, defect)

x86
Windows 7
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: otto.koehn, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [fixed by Bug 614479])

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110131 Firefox/4.0b11pre SeaMonkey/2.1b2pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110131 Firefox/4.0b11pre SeaMonkey/2.1b2pre

Right-Klick on a document or picture opens pulldown menue.  Klick on option "send to ...E-Mail-Recipient" should open the Mail Editor. It opens the browser window instad.

Reproducible: Always

Steps to Reproduce:
1.Right klick on a document  or picture
2.select "send to"
3.select "E-Mail-recipient"
Actual Results:  
Browser StartUp window opens

Expected Results:  
E-Mail Editor-window should open
I am assuming you are talking about the Send to menu in windows explorer. I can and have confirmed this bug.

However, I have no idea what causes it or how to fix it.

Never the less, this is confirmed.
Might be fallout from Bug 627999 (Some -compose command line options won't work if they are the first or only argument)

Matt can you check with a build from 31 January or before?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110129 Firefox/4.0b11pre SeaMonkey/2.1b2pre

Same result. Browser window opens as if I opened SM normally.
Checked with latest SM 2.0. It does indeed work. I will try and narrow down the point of the regression and report back.
(In reply to comment #2)
> Might be fallout from Bug 627999 (Some -compose command line options won't work
> if they are the first or only argument)

It's unlikely related to this specific part as at the time when we get there, it's already established that a "compose" window should be opened. The patch wasn't effective before the 20110202 SM nightly, and that part of the code hasn't been touched for ages before it was extended by bug 627999. It's not a SimpleMAPI problem either = SeaMonkey is accepted as default e-mail client.

Further testing with yesterday's nightly on Windows XP shows correct behavior for "seamonkey -compose mailto:test@example.com"; whereas the short version that MAPI may use, "seamonkey mailto:test@example.com" opens *both* the compose window with correct "To:" address, but also an empty browser tab for me, and the browser window is in the foreground and has focus. Thus, it appears to that the browser somehow tries to interpret the URL as well, so the problem may be hiding in that code.
Apparently http://mxr.mozilla.org/comm-central/ident?i=getURLToLoad takes care of handling plain URLs (where I'm not sure which type of arguments are actually passed to the mail application using MAPI, but I'd assume a minimal "mailto:" URI with "?attachment=" for the file, hence triggering the issue). It may also make a difference if SeaMonkey is running already (in which case a "remote" call should be performed) or if it's started from scratch (in which case the process invoked handles the arguments itself).

http://hg.mozilla.org/comm-central/log/e1c66e0e8ce3/suite/browser/nsBrowserContentHandler.js
where the respective code is located shows that the last change has been made in July of last year, but at a quick look, those don't look suspicious either.
Component: General → OS Integration
QA Contact: general → os-integration
Version: unspecified → Trunk
Regression range:

2010-12-17 works
2010-12-22 broken

(there were no intervening SeaMonkey builds that i see)

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d1da1005b6d6&tochange=d37e24f10e8d
Matt/Otto/therube: do you see a open compose window behind the blank browser window like rsx11m?

And previous to 2010-12-17 did a browser window open behind the compose window? if so this might be a race condition.
(In reply to comment #9)
> Matt/Otto/therube: do you see a open compose window behind the blank browser
> window like rsx11m?
> 

No compose window behind browser window in
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20101008 Firefox/4.0b7pre SeaMonkey/2.1b1.
In Windows menue "Set Standard-Programs" (?, German Version:"Standardprogramme festlegen") SM-Mail is set "Standard" and shows details as follows:

Name               Description            Actual Standard
.eml             SM (Mail) Document             SM, 
protocol MAIL TO  SM (Mail) URL                 SM  
MAPI send E-Mail  Command "send E-Mail"         SM

On my laptop SM 2.0.11 with same settings "Send to-> Mail-recipient" correctly opens the composer window, however the Windows setting details are as follows:

Name               Description            Actual Standard
.eml             SM (Mail) Document             SM, 
protocol MAIL TO  SM (Mail) URL             unknown Application
MAPI send E-Mail  Command "send E-Mail"          SM

If on that computer additionally Thunderbird 3.1.7 is installed, "send to ->E-Mail recipient" opens THB-Composer, whatever the settings are, even if THB is deactivated in the settings menue as far as possible (.wdseml cannot be deactivated).
Neil, is this a suiteGlue problem or a contentHandler problem or something else?
Explorer's Send to E-Mail Recipient actually uses Simple MAPI.

Does the bug occur when SeaMonkey is open or only when it is closed?
When I did my tests it was with SM closed. I Just now tested with it open. It seems to behave just as if I opened seamonkey.exe normally. Just a new window.
(In reply to comment #13)
> When I did my tests it was with SM closed. I Just now tested with it open. It
> seems to behave just as if I opened seamonkey.exe normally. Just a new window.

confirmed, additional window.
Can confirm this with my  Gecko/20110203 SeaMonkey/2.1b2pre, in all 2.1 versions I saw this problem until now.
Same problem occurs in 2.1b3 - Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0pre) Gecko/20110408 Firefox/4.0pre SeaMonkey/2.1b3
blocking-seamonkey2.1: --- → ?
Severity: normal → major
> Regression range:

> 2010-12-17 works
> 2010-12-22 broken

The STR are the same as Bug 614479 but the regression range is different:
> Used both TB and SM nightlies for the following:
> Last known good: 2010-09-15
> Broken since: 2010-09-22
> No win32 nightly builds in between available.

Do nightly 2.1pre builds since 2011-04-15 still have this problem?
blocking-seamonkey2.1: ? → ---
(In reply to comment #18)
> > Regression range:
> 
> > 2010-12-17 works
> 
> 
> Do nightly 2.1pre builds since 2011-04-15 still have this problem?

Just installed 
 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110420 Firefox/6.0a1 SeaMonkey/2.2a1pre;

It works fine! 
Tested via Win7-rightclick - send-to-menue, OpenOffice - send as E-Mail.

Settings as described in comment #10 are all "Seamonkey".
Fixed by Bug 614479.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by Bug 614479]
I see this issue was resolved in 2011. Is there a fix for the same issue in Nov 2013?
See bug 913493 = different issue.
You need to log in before you can comment on or make changes to this bug.