1827356 - Hp scan to email fails for 64bit

Status: REOPENED

(Thunderbird :: OS Integration, defect)

Description

[Vincent Felsch]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36

Steps to reproduce:

the HP scan to email application no longer works since the last 64-bit thunderbird update 102.9.1

Actual results:

The 32-bit version works perfectly

Expected results:

the Thunderbird setting is the default client

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug is invalid.
If you think the bot is wrong, please reopen the bug and move it back to its prior component.
If your bug description is written in a non-English language, please use Google Translate or a similar service to translate it.

Please note that this is a production bug database used by the Mozilla community to develop Firefox, Thunderbird and other products.
Filing test bugs here will waste the time of our contributors, volunteers and employees.
Accounts that abuse bugzilla.mozilla.org will be disabled.

Comment 2

[Wayne Mery (:wsmwk)]

I don't see an obvious bug in https://hg.mozilla.org/releases/comm-esr102/pushloghtml to have caused this in 102.9.1, do you ?

Comment 3

[Mike Kaganski]

I use TB 102.9.1 (64-bit) on Windows 10. I can say that sending email from LibreOffice with TB being the OS default mail program works fine, so the SimpleMAPI in TB at least works fine. However, I have no idea which protocol is used by HP scan to email.

My first idea would be to double-check TB integration. (I hope that the trivial "has the system been restarted" was completed.)

the Thunderbird setting is the default client

This needs checking. Windows "default email client" is a complex, multipart setting, including setting up several different protocols like 'mailto:' URI handling, SimpleMAPI registration, etc. Windows may report an application as set as default, when only part of the registrations are set up. I know of cases when manually setting an app as default again, ignoring the existing "default" status, fixed problems.

The details are missing here (or I don't see them): Windows specific version; HP software version (and if possible, an URL to download it - unless it was installed automatically by system as part of standard driver); the HP scanner model (which could allow people to see if they have similar HW and SW to try to repro).

Then, if this was LibreOffice bug tracker (disclosure: I'm a LibreOffice developer :-D), and if I couldn't repro, I's close it as NOTOURBUG, asking to file it to HP, who could check what exactly fails. In case when they analyze and pinpoint it to TB, then this would be reopened with some additional data.

But I'm not sure this is how things are done here :-D

Comment 4

[Richard Marti (:Paenglab)]

It can be that TB was installed as 32bit app and MAPI was registerd as 32bit. Then the 64bit TB was later installed there is still the 32bit MAPI registered which fails with TB 64bit. We had already bugs with MAPI issues when moving to 64bit.

Comment 5

[Alfred Peters [:infofrommozilla]]

Following Bug 1530820 Comment #30, uninstalling and reinstalling the 64bit version should help.

Comment 6

[MM]

The HP software is 32bit or 64bit? In general, you can't mix 3rd party 32bit software with 64bit TB.

Comment 7

[Mike Kaganski]

(In reply to MM from comment #6)

But you can :-)
It is important that TB registers correctly, because OS needs to know how to communicate with the SimplaMAPI provider (so the comment 4 is important). But after that, OS takes responsibility to use whatever interprocess communication means it needs to connect any client to the provider. If needed, it uses a shim.

Only if the SimpleMAPI provider DLL would work inside the calling process, your comment would be important. This is the case in e.g. shell extensions (and then the application that provides the extension should install two copies, one for each architecture). But happily not in this case.

Comment 8

[Worcester12345]

(In reply to Richard Marti (:Paenglab) from comment #4)

It can be that TB was installed as 32bit app and MAPI was registerd as 32bit. Then the 64bit TB was later installed there is still the 32bit MAPI registered which fails with TB 64bit. We had already bugs with MAPI issues when moving to 64bit.

32 to 64 bit transition has been a long and difficult road for Thunderbird.

(In reply to Mike Kaganski from comment #7)

It is important that TB registers correctly, because OS needs to know how to communicate with the SimplaMAPI provider (so the comment 4 is important). But after that, OS takes responsibility to use whatever interprocess communication means it needs to connect any client to the provider. If needed, it uses a shim.

What I might try in this situation:
Try running CCleaner to clean up the registry. Then uninstall all Thunderbird installations, reboot, then download and install a fresh new Thunderbird, making sure to set it as default. The other thing you could do is to set a different program as default before installing the fresh new Thunderbird, so it will get changed back upon installation.

Comment 9

[Rob Lemley [:rjl]]

I suspect that this is the same as bug 1879717. The reporter there did the work showing that DLLs from a 32-bit build were able to work with 64-bit Thunderbird.
That said, it looks like there are 64-bit HP drivers now that may work.