Closed Bug 913493 Opened 11 years ago Closed 11 years ago

MAPI stopped working with SAGE 50 and other mailto: (Need to link MAPI support into xul.dll)

Categories

(MailNews Core :: Build Config, defect)

x86
Windows 7
defect
Not set
normal

Tracking

(thunderbird26 fixed, thunderbird27 fixed, seamonkey2.22? affected, seamonkey2.23 fixed, seamonkey2.24 fixed, thunderbird_esr24- unaffected)

RESOLVED FIXED
Thunderbird 28.0
Tracking Status
thunderbird26 --- fixed
thunderbird27 --- fixed
seamonkey2.22 ? affected
seamonkey2.23 --- fixed
seamonkey2.24 --- fixed
thunderbird_esr24 - unaffected

People

(Reporter: jill, Assigned: neil)

References

Details

(Keywords: verifyme)

Attachments

(1 file)

User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BOIE9;ENCA) Actual results: When working with Sage 50, I would like to email direct deposit slips and invoices and I get error message stating" Sage 50 cannot communicate with your email program. Please ensure that your e-mail program is MAPI-compatible and that is the default MAPI client"
Group: core-security
This is a problem with all newer Thunderbird releases. Not certain at which version it stopped working.
Confirmed fixed in 24.1, broken again in 27.0a1 (2013-10-22).
Since confvars.sh is read before the local configure.in we don't have the value of MOZ_MAPI_SUPPORT early enough. After compiling with this I got as far as COM creating the remote component, however it then errored out with a E_NOINTERFACE for some reason.
Attachment #825651 - Flags: review?(Pidgeot18)
Attachment #825651 - Flags: review?(Pidgeot18) → review+
Comment on attachment 825651 [details] [diff] [review] Actually link mapi support into xul.dll http://hg.mozilla.org/comm-central/rev/9c812d89f8c9 [Approval Request Comment] Regression caused by (bug #): 789787 User impact if declined: Can't send attachments from external applications Testing completed (on c-c, etc.): Landed on c-c Risk to taking this patch (and alternatives if risky): Low, build config only.
Attachment #825651 - Flags: approval-comm-beta?
Attachment #825651 - Flags: approval-comm-aurora?
Summary: MAPI configuration with 2013 SAGE 50 not working → MAPI stopped working with SAGE 50 and other mailto: (Need to link MAPI support into xul.dll)
Blocks: 789787
Status: UNCONFIRMED → ASSIGNED
Component: Untriaged → Build Config
Ever confirmed: true
Product: Thunderbird → MailNews Core
Version: 17 → 25
Comment on attachment 825651 [details] [diff] [review] Actually link mapi support into xul.dll [Triage Comment] a=Standard8 I guess we also want this on ESR 24.
Attachment #825651 - Flags: approval-comm-esr24+
Attachment #825651 - Flags: approval-comm-beta?
Attachment #825651 - Flags: approval-comm-beta+
Attachment #825651 - Flags: approval-comm-aurora?
Attachment #825651 - Flags: approval-comm-aurora+
Keywords: checkin-needed
Whiteboard: [checkin-needed for comm-esr24 Comment 16]
Needs an esr24-specific patch.
Keywords: checkin-needed
Whiteboard: [checkin-needed for comm-esr24 Comment 16]
The 24.x branch shouldn't be affected as bug 789787 checked in for 25.0 only, and all reports duped to this one refer to SeaMonkey 2.22 (coming from the 25.0 release branch) stating that 2.21 still worked. Double-checking in comm-esr24, neither mail/configure.in nor mail/confvars.sh use MOZ_MAPI_SUPPORT in any way or have any other reference to MAPI.
I do not want to be tough, but it is a two weeks after I reported the bug in SM 2.22 beta and it was a duplicate of a two month known problem (taken from the first reported date above 2013-09-06) and it has now 12 bug duplicates, so it seems it is sure quite important bug. I consider this error really major and it is unclear, why a solution is still not issued? Is it so complicated? For me the un-ability to use the MAPI is a very unpleasant and annoying thing, which degrades the SM strongly. I am willing to see any working update or I will soon personally do a rollback to 2.21.
(In reply to Mark Banner (:standard8) from comment #15) > I guess we also want this on ESR 24. This would rather need to land on comm-release if a SM 2.22.1 is planned.
(In reply to zetka from comment #21) > I do not want to be tough, but it is a two weeks after I reported the bug in > SM 2.22 beta and it was a duplicate of a two month known problem (taken from > the first reported date above 2013-09-06) and it has now 12 bug duplicates, > so it seems it is sure quite important bug. I consider this error really > major and it is unclear, why a solution is still not issued? Is it so > complicated? For me the un-ability to use the MAPI is a very unpleasant and > annoying thing, which degrades the SM strongly. I am willing to see any > working update or I will soon personally do a rollback to 2.21. The bug will be fixed in SeaMonkey 2.23 (which will be released in a few weeks). So if you want/need to, rollback to 2.21 and make sure to install the SeaMonkey 2.23 as soon as it is released.
any news on eta of this fix? having this issue on seamonkey 2.22, 2.21 worked fine. thanks for a quick fix if possible. is it possible to use some old .dll (win32) from seamonkey 2.21 as a workaround or is this in the main seamonkey binary (.exe)? thanks.
(In reply to abittner from comment #25) > any news on eta of this fix? having this issue on seamonkey 2.22, 2.21 > worked fine. thanks for a quick fix if possible. A new release happens approximately every six weeks. SeaMonkey 2.22 was released on 30 October so the 2.23 release date should be about mid-December. > is it possible to use some > old .dll (win32) from seamonkey 2.21 as a workaround or is this in the main > seamonkey binary (.exe)? thanks. If it isn't the seamonkey.exe it is probably the xul.dll, which contains the bulk of the code for that version. Using the libxul of one version with the executable, omni.ja, and other files of a different version is courting disaster, and inviting any kind of weird behaviour, including but not limited to crashes.
Sigh, this situation is very unpleasant. I suppose there are too many important vulnerabilities fixed in sm 2.22 compared to 2.21 or can we safely revert to 2.21 for time being? The people who are using this Seamonkey at my place are not very knowledgable and they have trouble attaching files via the paperclip button or via drag drop, and suddenly their simple way of doing attachments directly from their files is destroyed :( Thanks.
In a duplicate report I already indicated that reverting to version 2.21 solved the problem.
You have to decide this for yourself if you want to revert to SM 2.21 or not. If this issue is a major problem for you, then you probably need to downgrade. But can we please keep this down- or upgrade discussion out of this bug now? :) As the bug is only meant for fixing the issue, we can discuss in the newsgroups (mozilla.support.seamonkey, mozilla.dev.apps.seamonkey) about such things.
I voted for this bug and as previous posters have asked, why did this fix not make it into 2.22 and related versions of Thunderbird if this bug is as old as from early september :(
Because we are humans and make mistakes. The bug was not noticed soon enough by bug triagers and developers. Also, the initial bug report in Comment 0 talked about Thunderbird 17(!), but the bug that was fixed here was/is way newer (first visible in Thunderbird 25 beta builds). So the initial bug report probably meant another issue as Thunderbird 17 was not affected by the problem that was fixed by this patch here.
Assuming this is actually fixed on trunk, hence marking fixed as per standard practice.
Assignee: nobody → neil
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 28.0
Tried the downgrade to 2.21 a couple of times, but automatically get upgraded to 2.22 shortly after the downgrade. Guess I'll need to wait til 2.23 comes out and work through the bug during the interim.
(In reply to Dan from comment #33) > Tried the downgrade to 2.21 a couple of times, but automatically get > upgraded to 2.22 shortly after the downgrade. Guess I'll need to wait til > 2.23 comes out and work through the bug during the interim. Go to Preferences->Advanced->Software Installation->Seamonkey and uncheck Automatically check for updates, Automatically download and install the update
(In reply to Mark Banner from comment #32) > Assuming this is actually fixed on trunk, hence marking fixed as per > standard practice. Although I did discover the regression from bug 789787, I don't actually know whether my patch completely fixes this bug or not. As per my comment #3 my local build still doesn't work.
Keywords: verifyme
(In reply to rsx11m from comment #23) > This would rather need to land on comm-release if a SM 2.22.1 is planned. Per bug 938420 a SM 2.22.1 release is on the horizon but at this time wouldn't contain this fix unless attachment 825651 [details] [diff] [review] checks in for it. On the other hand, according to comment #35 it may not be entirely fixed. Thus, can it /hurt/ to check this in for comm-release if it resolves at least /some/ cases?
Flags: needinfo?(neil)
(In reply to rsx11m from comment #37) > (In reply to rsx11m from comment #23) > > This would rather need to land on comm-release if a SM 2.22.1 is planned. > > Per bug 938420 a SM 2.22.1 release is on the horizon but at this time > wouldn't contain this fix unless attachment 825651 [details] [diff] [review] > checks in for it. On the other hand, according to comment #35 it may not be > entirely fixed. Thus, can it /hurt/ to check this in for comm-release if it > resolves at least /some/ cases? I'm not a release driver or engineer. The correct way to do this is to request approval-comm-release, although I believe the build process has already started so you've missed the train. Sorry about that.
Flags: needinfo?(neil)
I've left a note the release bug. I don't think requesting branch approvals is my job to do, and I've pointed out early enough that it should land on comm-release as well, just in case.
verified that its not fixed yet with seamonkey 2.22.1 what a shame. if i understand it right, this is probably just a build tools bug or similar, and it could have been fixed for this tiny respin of the current sm and tb but again no fix :( how hard can it be if this stuff was working fine on sm 2.21 and suddenly broke with 2.22 then revert that part back or fix it again after all these reports and 2.22.1 still in bad state
It is known that the patch didn't make it into 2.22.1, otherwise you would have seen action here in this report. The upcoming 2.23 beta 1 should have the patch in it, thus any verification whether or not it's fixed would have to be done in that build.
Comment on attachment 825651 [details] [diff] [review] Actually link mapi support into xul.dll Cancelling for TB 24 as it isn't needed there.
Attachment #825651 - Flags: approval-comm-esr24+
I would like for hell to know, when will be the 2.23 beta 1 available? I thought that the advantage of the SM/Mozilla team is a fast reaction and flexibility, but after this three months (after first discovery of the problem) martyrdrom which seems that the new build takes soooo long I have the feeling, that it is same in Mozilla like in Microsoft... I am really really disappointed.
(In reply to zetka from comment #46) > I would like for hell to know, when will be the 2.23 beta 1 available? Sorry, if you want something "for hell", according to my research, you need to ask "the devil". The SeaMonkey project cannot help you dealing with "hell" knowledge.
Website changes for 2.23 beta 1 have been pushed a couple of minutes ago, thus you should see the announcement and download pages soon. It may be available for manual update already.
(In reply to zetka from comment #46) > I would like for hell to know, when will be the 2.23 beta 1 available? I > thought that the advantage of the SM/Mozilla team is a fast reaction and > flexibility, but after this three months (after first discovery of the > problem) martyrdrom which seems that the new build takes soooo long I have > the feeling, that it is same in Mozilla like in Microsoft... > I am really really disappointed. 2.23b1 should be out within the next hour or so. Sorry for the delay. This delay has nothing to do with Mozilla. The SeaMonkey project is a community project and I realize this may sound like an excuse, we are only volunteers doing our best with the time we have. Thank you for your patience. Really do appreciate it.
zetka, fwiw.. 2.23b1 is out. (sorry for the bugspam)
(In reply to zetka from comment #46) > I would like for hell to know, when will be the 2.23 beta 1 available? I > thought that the advantage of the SM/Mozilla team is a fast reaction and > flexibility, but after this three months (after first discovery of the > problem) martyrdrom which seems that the new build takes soooo long I have > the feeling, that it is same in Mozilla like in Microsoft... > I am really really disappointed. Hello Zetka, Firstly, bugzilla is not a good place to lay general complaints/comments it is where we (devs) do our primary day-to-day work, for feedback (like yours) I would suggest seamonkey-council@mozilla.org or any of our newsgroups/forums. Secondly, the team behind SeaMonkey are completely volunteer working in their free time on ensuring we have builds and releases out the door for you, our users. We do prioritize stability and security fixes above all else, so it is with apologies that it took so long for you to see a build/release with this fix. While it is only in our beta right now, we hope to have 2.23 final out soon. I advice we keep further conversation on your concerns out of this bug, please feel free to e-mail me directly at the above address
Sorry for being so hard, but it really made me angry every day, because the function of sending email through MAPI I use practically everyday. I can confirm, that after installing the Beta the mail could be send from other application normaly on my XPs. Thanks again, Zetka.
sorry, but in my case this patch is not fixed in a pleasant way: (windows 7, SM 2.23) the MAPI-support ist in function, true. If no SM-instance is running and I am using the MAPI-support within windows7, the mail client comes up with the attached file (ok), but at the same time the browser-part will also bed started. Is it possible to use the same starting point for MAPI as if i use seamonkey.exe -mail ? with kind reagards Gerd
My understanding is that's how it's always worked. I haven't looked but there's probably a bug filed on improving that behaviour, however it's not directly relevant to this bug, which was just about MAPI being completely broken.
I have been having this problem intermittently for years, and still am with TB 52.9.1 and Sage 50 Quantum 2018 build 25.2.00.0197 under Windows 10 (all versions, currently 1803 Pro). Sometimes it works, sometimes it doesn't. When it doesn't, closing TB and then sending email from Sage WILL start up TB and the composition window will open with the attachment. This is reliable. I've also experienced this when trying to send email from Excel and maybe other programs.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: