Closed
Bug 614479
Opened 14 years ago
Closed 13 years ago
[trunk] Send To Mail Recipient not working, MAPI broken
Categories
(MailNews Core :: Simple MAPI, defect)
Tracking
(status2.0 .1-fixed, blocking-thunderbird5.0 needed)
RESOLVED
FIXED
Thunderbird 5.0b1
People
(Reporter: rob, Assigned: neil)
References
Details
(Keywords: regression)
Attachments
(3 files, 2 obsolete files)
2.23 KB,
patch
|
khuey
:
review+
christian
:
approval2.0+
|
Details | Diff | Splinter Review |
7.93 KB,
patch
|
Callek
:
review+
|
Details | Diff | Splinter Review |
3.28 KB,
patch
|
Callek
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20101008 Firefox/4.0b7pre SeaMonkey/2.1b1 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20101008 Firefox/4.0b7pre SeaMonkey/2.1b1 Seamonkey open or closed Right-click a file in explorer or my documents, hit send to, mail recipient, and Seamonkey browser opens or get the focus. The compose window does not open with the file attached, as it used to do just fine in Seamonkey 2.0 This also happens when trying to email a pdf file from acrobat Reproducible: Always Steps to Reproduce: 1. Any right-click, send-to 2. 3. Actual Results: Compose window does not open Expected Results: Compose window should open I get same result in 2.1b1 and recent 2.1b2pre
Updated•14 years ago
|
Version: unspecified → Trunk
Updated•14 years ago
|
Component: General → OS Integration
QA Contact: general → os-integration
Comment 1•14 years ago
|
||
I think I see the same, but I'm on Win7 x64, so it might be a different issue. First I ran into http://support.microsoft.com/kb/813745/EN-US/ (after clicking the Mail button under Preferences/Mail & Newsgroups), which I filed bug 618678 for. Leaving as UNCO for now since I still need to check this on WinXP (which my laptop runs).
Comment 2•14 years ago
|
||
BTW this is similar to bug 499958 which was fixed for SM 1.1.x.
Comment 3•14 years ago
|
||
I should note that I'm starting SM trunk with -no-remote. Maybe if I wouldn't (cannot check right now), I would see what bug 612882 describes, in which case the two might be related.
Comment 4•14 years ago
|
||
OK, seeing this on WinXP, too, confirming. I can also reproduce this with TB trunk, so moving to MailNews Core.
Component: OS Integration → Simple MAPI
Product: SeaMonkey → MailNews Core
QA Contact: os-integration → simple-mapi
Updated•14 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Seamonkey 2.1 Send-to mail recipient not working Mapi broken → [trunk] Send To Mail Recipient not working, MAPI broken
Updated•14 years ago
|
Keywords: regression,
regressionwindow-wanted
Comment 6•14 years ago
|
||
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. :-( http://hg.mozilla.org/comm-central/pushloghtml?startdate=2010-09-14+00%3A00%3A00&enddate=2010-09-22+23%3A59%3A59 -> probably switch-to-libxul fallout If you test, mind bug 618678 (i.e. check that the registry key is correct), which has been present since before 2010-01-01.
Keywords: regressionwindow-wanted
Updated•14 years ago
|
blocking-thunderbird5.0: --- → ?
Updated•13 years ago
|
blocking-thunderbird5.0: ? → needed
Assignee | ||
Comment 7•13 years ago
|
||
(In reply to comment #6) > http://hg.mozilla.org/comm-central/pushloghtml?startdate=2010-09-14+00%3A00%3A00&enddate=2010-09-22+23%3A59%3A59 > -> probably switch-to-libxul fallout Indeed. Because switch-to-libxul forgot to link msgMapi into libxul. Oops. > If you test, mind bug 618678 (i.e. check that the registry key is correct), > which has been present since before 2010-01-01. I found that I also had to manually register MapiProxy.dll (not sure how this normally gets done, probably part of the installer or something.)
Assignee | ||
Comment 8•13 years ago
|
||
MOZ_APP_COMPONENT_INCLUDE simply isn't flexible enough. So I want to replace it with MOZ_APP_COMPONENT_MODULES. This patch currently permits one of the two to be used.
Assignee | ||
Comment 9•13 years ago
|
||
I guess I need to write the equivalent Thunderbird changes...
Attachment #524966 -
Flags: feedback?(bugspam.Callek)
Comment 10•13 years ago
|
||
Comment on attachment 524966 [details] [diff] [review] SeaMonkey changes You attached the wrong patch here (same as first one).
Assignee | ||
Comment 11•13 years ago
|
||
Attachment #524966 -
Attachment is obsolete: true
Attachment #524982 -
Flags: feedback?(bugspam.Callek)
Attachment #524966 -
Flags: feedback?(bugspam.Callek)
Assignee | ||
Comment 12•13 years ago
|
||
Comment on attachment 524982 [details] [diff] [review] Actual SeaMonkey changes >-#define APP_COMPONENT_MODULES MODULE(xpAutoComplete) MODULE(nsMailModule) MODULE(nsMsgSMIMEModule) MODULE(nsImportServiceModule) MODULE(nsLDAPProtocolModule) ... >+MOZ_APP_COMPONENT_MODULES="MODULE(nsMailModule) MODULE(nsMsgSMIMEModule) MODULE(nsImportServiceModules) MODULE(xpAutoComplete) $MAPI_MODULE $LDAP_MODULE" Dunno how I managed to typo this, but it should of course be nsImportServiceModule as per the line that I removed...
Comment 13•13 years ago
|
||
Comment on attachment 524982 [details] [diff] [review] Actual SeaMonkey changes I'm "ok" with this, but would actually be happier with either a pre-process or a an addition to DEFINES (of some sort) that lets us still use this header as is. Than having to embed the |MODULE()| into the makefile (too easy to miss/mistake that way)
Attachment #524982 -
Flags: feedback?(bugspam.Callek) → feedback+
Assignee | ||
Comment 14•13 years ago
|
||
(In reply to comment #13) > I'm "ok" with this, but would actually be happier with either a pre-process or > a an addition to DEFINES (of some sort) that lets us still use this header as > is. Than having to embed the |MODULE()| into the makefile (too easy to > miss/mistake that way) We can't do that because we can't get at our DEFINES when linking libxul, which is why we have our existing hacks to get extra components linked in.
Attachment #524964 -
Flags: review?(khuey) → review+
Comment 15•13 years ago
|
||
Comment on attachment 524964 [details] [diff] [review] Core changes, part 1 [Checked in: Comment 15 & 18] http://hg.mozilla.org/mozilla-central/rev/ead2b17ac3cc
Assignee | ||
Comment 16•13 years ago
|
||
Comment on attachment 524964 [details] [diff] [review] Core changes, part 1 [Checked in: Comment 15 & 18] So, under our current plans, we (SeaMonkey) are trying to build a release using 2.0 branch code, but this bug needs this build config change in order to achieve that. It doesn't have to land before Firefox 4.0.1, as long as it lands. It adds a new variable so it doesn't strictly affect Firefox, although I did run it through try before it landed on mozilla-central just in case.
Attachment #524964 -
Flags: approval2.0?
Comment 17•13 years ago
|
||
Comment on attachment 524964 [details] [diff] [review] Core changes, part 1 [Checked in: Comment 15 & 18] approving for releases/mozilla-2.0.
Attachment #524964 -
Flags: approval2.0? → approval2.0+
Comment 18•13 years ago
|
||
Comment on attachment 524964 [details] [diff] [review] Core changes, part 1 Check-In: http://hg.mozilla.org/releases/mozilla-2.0/rev/ad48178a0e9e
Assignee | ||
Comment 19•13 years ago
|
||
Last patch had a few bugs, because I had run stuff incrementally.
Attachment #524982 -
Attachment is obsolete: true
Attachment #525803 -
Flags: review?(bugspam.Callek)
Comment 20•13 years ago
|
||
Comment on attachment 525803 [details] [diff] [review] Tested SeaMonkey changes [Checked in: Comment 23] Not really a fan as I said above, but in the short-term this *does* fix us. Mark do you need a patch for your end for this that I can entice Neil to write; or should we avoid the effort and wait for comm-build-rework?
Attachment #525803 -
Flags: review?(bugspam.Callek) → review+
Assignee | ||
Comment 21•13 years ago
|
||
(In reply to comment #20) > or should we avoid the effort and wait for comm-build-rework? That's not going to help us release against mozilla2.0 ...
Comment 22•13 years ago
|
||
(In reply to comment #21) > (In reply to comment #20) > > or should we avoid the effort and wait for comm-build-rework? > That's not going to help us release against mozilla2.0 ... For the record, I do want you to put this patch in to comm-{central,2.0} for us (the latter only if the branch is ready before you push). I was merely commenting that Miramar is not going to be based on moz-2.0 so wasn't sure if Mark wanted a TB patch created/in yet.
Assignee | ||
Comment 23•13 years ago
|
||
Comment on attachment 525803 [details] [diff] [review] Tested SeaMonkey changes [Checked in: Comment 23] Pushed changeset 8efafcfd0b86 to comm-central.
Updated•13 years ago
|
Attachment #524964 -
Attachment description: Core changes, part 1 → Core changes, part 1
[Checked in: Comment 15 & 18]
Updated•13 years ago
|
Attachment #525803 -
Attachment description: Tested SeaMonkey changes → Tested SeaMonkey changes
[Checked in: Comment 23]
Comment 24•13 years ago
|
||
{ s: cb-seamonkey-win32-02 LINK : fatal error LNK1181: cannot open input file '../../staticlib/components/msgMapi.lib' } http://hg.mozilla.org/comm-central/rev/a3830df7c0f6 "MAPI isn't being compiled in time to be linked in"
Comment 25•13 years ago
|
||
This fixes the Thunderbird side of things.
Attachment #526711 -
Flags: review?(bugspam.Callek)
Updated•13 years ago
|
Whiteboard: [has TB patch for review][SM fixed]
Updated•13 years ago
|
Attachment #526711 -
Flags: review?(bugspam.Callek) → review+
Comment 26•13 years ago
|
||
Checked in the Thunderbird patch: http://hg.mozilla.org/comm-central/rev/f6cc1c26417b
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [has TB patch for review][SM fixed]
Target Milestone: --- → Thunderbird 3.3a4
Updated•13 years ago
|
Attachment #526711 -
Attachment description: Thunderbird fix → Thunderbird fix
[Checked in: Comment 26]
You need to log in
before you can comment on or make changes to this bug.
Description
•