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

Status: RESOLVED FIXED

(MailNews Core :: Build Config, defect)

Description

[jill]

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"

Comment 1

[Herm]

This is a problem with all newer Thunderbird releases.  Not certain at which version it stopped working.

Comment 2

[Herm]

Confirmed fixed in 24.1, broken again in 27.0a1 (2013-10-22).

Comment 3

[[e-mail]]

Attachment: Actually link mapi support into xul.dll

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.

Comment 4

[[e-mail]]

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.

Comment 15

[Mark Banner (:standard8)]

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.

Comment 16

[[e-mail]]

https://hg.mozilla.org/releases/comm-aurora/rev/6e0a8ef98bf8
https://hg.mozilla.org/releases/comm-beta/rev/d77b568ed330

(I don't have an ESR tree.)

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Needs an esr24-specific patch.

Comment 19

[rsx11m]

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.

Comment 21

[zetka]

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.

Comment 23

[rsx11m]

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

Comment 24

[Frank Wein [:mcsmurf]]

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

Comment 25

[abittner]

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.

Comment 26

[Tony Mechelynck [:tonymec]]

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

Comment 27

[abittner]

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.

Comment 28

[hhgygy]

In a duplicate report I already indicated that reverting to version 2.21 solved the problem.

Comment 29

[Frank Wein [:mcsmurf]]

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.

Comment 30

[abittner]

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

Comment 31

[Frank Wein [:mcsmurf]]

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.

Comment 32

[Mark Banner (:standard8)]

Assuming this is actually fixed on trunk, hence marking fixed as per standard practice.

Comment 33

[Dan]

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.

Comment 34

[hhgygy]

(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

Comment 35

[[e-mail]]

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

Comment 37

[rsx11m]

(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?

Comment 38

[[e-mail]]

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

Comment 39

[rsx11m]

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.

Comment 42

[abittner]

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

Comment 43

[rsx11m]

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 45

[Mark Banner (:standard8)]

Comment on attachment 825651 [details] [diff] [review]
Actually link mapi support into xul.dll

Cancelling for TB 24 as it isn't needed there.

Comment 46

[zetka]

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.

Comment 47

[Robert Kaiser]

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

Comment 48

[rsx11m]

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.

Comment 49

[Edmund Wong (:ewong)]

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

Comment 50

[Edmund Wong (:ewong)]

zetka, fwiw..  2.23b1 is out.

(sorry for the bugspam)

Comment 51

[Justin Wood (:Callek)]

(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 [e-mail] 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

Comment 52

[zetka]

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.

Comment 54

[Gerd Steffens]

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

Comment 55

[[e-mail]]

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.

Comment 56

[marty]

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.