1570581 - Starting Firefox 68.0.1, Adobe Acrobat Extension for Firefox fails to send apple events to target application (Acrobat)

Status: VERIFIED FIXED

(WebExtensions :: General, defect, P1)

Description

[Acrobat]

Attachment: 1234.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

install Firefox 68.0.1 on Catalina(macOs) Beta version.
Install and Sign In to Adobe Acrobat.
Open Firefox
Enable Acrobat extension
Open any webpage (eg. www.apple.com)
Click on acrobat extension
Click on Convert webpage to PDF
OBSERVE

Actual results:

Acrobat is launched, but file is not converted and after ~3 minutes Conversion failed error is observed.
Extension is working fine with Firefox 68.0 build on multiple machines. Tested on 4 machines.
Seems like the issue is with Firefox version 68.0.1. which is getting installed automatically.

Expected results:

Acrobat is launched with created PDF file without any error.

Acrobat extension uses native host to launch acrobat and send the conversion data to acrobat via apple events.
Though acrobat is properly launched but the conversion data is not being sent to Acrobat resulting into extension showing conversion failure after a time-out.

Comment 1

[Acrobat]

Bug is not catalina specific, it is reproducible on both Mac OS 10.14 or Mac 10.15 latest public beta.
Details of the API name and its parameters that are called by native host to work with Acrobat:
https://developer.apple.com/documentation/coreservices/1442994-aesendmessage?language=objc

Comment 2

[Andrew Swan [:aswan]]

(In reply to Acrobat from comment #0)

Though acrobat is properly launched but the conversion data is not being sent to Acrobat resulting into extension showing conversion failure after a time-out.

This is going to be difficult for us to investigate without more information since the immediate failure is happening inside your native applications.
Can you either provide more information about how the native application is failing (eg do you get back a particular error from AESendMessage) or can you provide a simplified test case that we could use to reproduce this locally?

Comment 3

[Mike Kaply [:mkaply]]

Here's the list of things that went into 68.0.1.

https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=FIREFOX_68_0_RELEASE&tochange=FIREFOX_68_0_1_RELEASE

Nothing seems suspect.

Does it only happen on macOS?

Comment 4

[Acrobat]

Yes, this only happens on MacOS.
Issue only happens with Firefox 68.01, 68.0 and previous versions works fine.
Acrobat extension is side-loaded with acrobat, native host installation and Apple Event listener are all installed with acrobat, Can we share Acrobat build/installation setup with Firefox...?

Comment 5

[Acrobat]

Also, the Native host process is launched as a child process of Firefox, so in that sense, the native host application is native to Firefox application which sends event to Acrobat which is a separate process.

Comment 6

[Acrobat]

AESendMessage API return noErr

Comment 7

[Andrew Swan [:aswan]]

(In reply to Acrobat from comment #4)

Can we share Acrobat build/installation setup with Firefox...?

I'm sorry I don't understand what you're suggesting. The request in comment 2 was to provide a simplified test case that illustrates the problem.

Comment 8

[Mike Kaply [:mkaply]]

I just installed Acrobat Reader DC on macOS and with Firefox 68.0.1 I was able to create PDFs....

Comment 9

[sbean]

We have the same problem.
Our add-on calls a native messaging app (browser.runtime.connectNative). The app use Apple Events. It does not work anymore, since Firefox 68 on macOS, because entitlement has been added. It misses com.apple.security.automation.apple-events key .

Comment 10

[Mike Kaply [:mkaply]]

Not sure who else to help on this without aswan.

Aki, how easy is it to add an entitlement?

Comment 11

[Haik Aftandilian [:haik]]

I'll look into this. Adding the entitlement is just a small change to production.entitlements.xml[1] and developer.entitlements.xml in the tree. @sbean, thanks for the information on com.apple.security.automation.apple-events[2].

1. https://searchfox.org/mozilla-central/source/security/mac/hardenedruntime/production.entitlements.xml
2. https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_automation_apple-events

Comment 12

[Andrew Swan [:aswan]]

Does this mean that a helper application spawned with the extension native messaging api inherits the entitlements that Firefox has?
Under what conditions does the spawned program use its own entitlements? For instance, if we spawn something like Word or Acrobat as a helper application, I would assume that has its own set instead of inheriting from Firefox?

Having spawned native applications inherit from Firefox sounds like a recipe for trouble -- any time we change what Firefox has, that's a subtle change to this API for extension developers. And adding entitelements to Firefox in case a spawned native application might need them sounds like a poor security practice.

(to be clear, adding something temporarily to work around an unexpected breakage seems reasonable, but this could use some additional thought for the long term, I don't know enough about the underlying macos bits to have a fully informed opinion)

Comment 13

[Haik Aftandilian [:haik]]

(In reply to Andrew Swan [:aswan] from comment #12)

Does this mean that a helper application spawned with the extension native messaging api inherits the entitlements that Firefox has?
Under what conditions does the spawned program use its own entitlements? For instance, if we spawn something like Word or Acrobat as a helper application, I would assume that has its own set instead of inheriting from Firefox?

If we spawn a new process directly, our entitlements are inherited. If we launch something like Word to handle a document, we use the LaunchServices framework for that which launches the process on our behalf and does not result in our entitlements being inherited.

Having spawned native applications inherit from Firefox sounds like a recipe for trouble -- any time we change what Firefox has, that's a subtle change to this API for extension developers. And adding entitelements to Firefox in case a spawned native application might need them sounds like a poor security practice.

Good point and I agree. We might have to change how we launch the native messaging helper to provide a stable environment for the helper to run in. There may be other functionality that helper apps rely on that we will or are blocking with HR. And we might not want to turn on those entitlements.

(to be clear, adding something temporarily to work around an unexpected breakage seems reasonable, but this could use some additional thought for the long term, I don't know enough about the underlying macos bits to have a fully informed opinion)

This needs more investigation, but I agree, we should probably add this entitlement so that we don't regress these extensions already in use.

Comment 14

[Acrobat]

Hi Haik Aftandilian,

From the above discussions it seems that the problem will get fixed if the entitlements/com.apple.security.automation.apple-events key is added.
Is there any estimate by when the fix will be in Firefox mainline/release builds?

Thanks,
Sandeep

Comment 15

[Haik Aftandilian [:haik]]

(In reply to Acrobat from comment #14)

From the above discussions it seems that the problem will get fixed if the entitlements/com.apple.security.automation.apple-events key is added.
Is there any estimate by when the fix will be in Firefox mainline/release builds?

If it's just the entitlement issue, this will be a low risk fix that we can uplift to release builds and ship out pretty quickly. I hope we can get this in a 68 dot release update. I'll try to have a build available to test today.

Comment 16

[Haik Aftandilian [:haik]]

I've been able to reproduce the problem with Firefox Release 68.0.2 and Firefox Nightly. After adding the com.apple.security.automation.apple-events entitlement, the "Convert webpage to PDF" option works again.

With the fix, the first time that "Convert webpage to PDF" is selected, a dialog is displayed "Firefox wants access to control Adobe Acrobat..." and the user needs to click OK for the extension to work. Then, in the Security & Privacy macOS preferences, Firefox is listed as an application that can control Adobe Acrobat. See attached screenshot. This can be reset with $ tccutil reset AppleEvents. I couldn't get tccutil to just reset the Adobe Acrobat permissions using the Acrobat bundle ID "com.adobe.Acrobat.Pro".

Here's a developer build of Firefox Nightly codesigned to enable Hardened Runtime, but not Notarized. It's not signed with an official Mozilla identity and won't run by default. After downloading the target.dmg and before opening it, run $ xattr -d com.apple.quarantime target.dmg to allow it to be launched.
https://queue.taskcluster.net/v1/task/FoF-8JSORbyo2DTWhu9VJQ/runs/0/artifacts/public/build/target.dmg (Source code).

@Acrobat, could you confirm that the posted build addresses the problem? I also have builds for Firefox 68.0.2 and Nightly that are codesigned and Notarized using an unofficial Apple codesigning identity. Would it be OK to send you links to those by email to validate?

Comment 17

[Haik Aftandilian [:haik]]

Attachment: Permission Dialog and Privacy Settings Pane

Comment 18

[Acrobat]

Thanks Haik, we will share validation results with you for the shared build.
Yes, please share those builds @[e-mail]

Comment 19

[Acrobat]

Hi Haik,

We have validated the private build, all workflows of the Acrobat extension that require apple events are working fine with the private build.
By when can we expect the fix to be in Firefox release builds..?

Thanks,
Sandeep

Comment 20

[Haik Aftandilian [:haik]]

(In reply to Acrobat from comment #19)

We have validated the private build, all workflows of the Acrobat extension that require apple events are working fine with the private build.
By when can we expect the fix to be in Firefox release builds..?

Thanks for verifying the fix.

We should be able to get this in Firefox 69 which is scheduled to release on September 3rd. Shipping this in a 68 update might be possible, but we would need a strong justification and it might depend on a more serious bug in 68 dictating the need for an update.

Comment 21

[Haik Aftandilian [:haik]]

Attachment: Bug 1570581 - Starting with Firefox 68.0.1, Adobe Acrobat Extension for Firefox fails to send apple events to target application (Acrobat) r?handyman

Relax our Hardened Runtime settings to allow the com.apple.security.automation.apple-events entitlement so that native messaging webextension helper apps (which are launched by and are child processes of Firefox) can use Apple Events to signal other processes. This will apply to Firefox and all child processes.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c04a717e1b18
Starting with Firefox 68.0.1, Adobe Acrobat Extension for Firefox fails to send apple events to target application (Acrobat) r=handyman

Comment 23

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/c04a717e1b18

Comment 24

[Mike Kaply [:mkaply]]

Please make sure this goes on the ESR as well.

Comment 25

[Haik Aftandilian [:haik]]

Comment on attachment 9087164 [details]
Bug 1570581 - Starting with Firefox 68.0.1, Adobe Acrobat Extension for Firefox fails to send apple events to target application (Acrobat) r?handyman

Beta/Release Uplift Approval Request

• User impact if declined: On Mac, Adobe's Acrobat WebExtension (and possibly other WebExtensions) will not function properly. Specifically, the native message functionality that allows the WebExtension to interact with installed applications will fail. This breaks generating PDFs from the WebExtension. This is a regression introduced by macOS Notarization/Hardened Runtime.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: *Not verified in Nightly, but the submitter verified a try Nightly build with the fix.

See bug description for more information.

1. Install Adobe Acrobat (A 1-week free trial version is available).
2. Enable the Adobe Acrobat WebExtension in about:addons
3. Click on Convert webpage to PDF
4. Click OK to allow Firefox to control Adobe Acrobat if asked.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change only affects macOS and is a configuration change to our Hardened Runtime entitlements, allowing one additional entitlement making the configuration less restrictive.
• String changes made/needed:

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: We should include this in the ESRs to avoid regressing this native messaging WebExtension functionality affecting the Adobe Acrobat extension.
  For ESR60, we have not shipped a build with Notarization enabled yet so we should include this fix before doing so.
  For ESR68, we have already shipped a Notarized build which triggers this bug.
• User impact if declined: On Mac, Adobe's Acrobat WebExtension (and possibly other WebExtensions) will not function properly. Specifically, the native message functionality that allows the WebExtension to interact with installed applications will fail. This breaks generating PDFs from the WebExtension. This is a regression introduced by macOS Notarization/Hardened Runtime.
• Fix Landed on Version: 70
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change only affects macOS and is a configuration change to our Hardened Runtime entitlements, allowing one additional entitlement making the configuration less restrictive.
• String or UUID changes made by this patch:

Comment 26

[Haik Aftandilian [:haik]]

(In reply to Mike Kaply [:mkaply] from comment #24)

Please make sure this goes on the ESR as well.

Done. This problem should affect ESR68 because we've already shipped an update that includes Notarization which causes this bug.
ESR60 has not yet shipped with Notarization so we need the fix on ESR60, but shipped builds are not affected.

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9087164 [details]
Bug 1570581 - Starting with Firefox 68.0.1, Adobe Acrobat Extension for Firefox fails to send apple events to target application (Acrobat) r?handyman

Fixes a Notarization regression, approved for 69.0b16, 68.1esr, and 60.9esr.

Comment 28

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/e9ad2d210cd3

Comment 29

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/3074c5a47ad5037b19a52fca06c202add0169915
https://hg.mozilla.org/releases/mozilla-esr60/rev/d960c56b609c098e54537947ac406b7c11d64d3a

Comment 30

[Victor Carciu]

Verified as fixed on FF70, FF69, FF-esr60 and FF-esr68 on macOS 10.14+ . Also I can confirm that I was able to reproduce the issue on FF 68.0.1.