Closed Bug 1570581 Opened 6 months ago Closed 5 months ago

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

Categories

(WebExtensions :: General, defect, P1)

68 Branch
defect

Tracking

(firefox-esr60 verified, firefox-esr68 verified, firefox69 verified, firefox70 verified)

VERIFIED FIXED
mozilla70
Tracking Status
firefox-esr60 --- verified
firefox-esr68 --- verified
firefox69 --- verified
firefox70 --- verified

People

(Reporter: sandees, Assigned: haik)

References

Details

Attachments

(3 files)

Attached image 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.

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

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

Component: Untriaged → General
Flags: needinfo?(sandees)
Product: Firefox → WebExtensions
Version: 68 Branch → Firefox 68

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?

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

Flags: needinfo?(sandees)

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.

AESendMessage API return noErr

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

Flags: needinfo?(sandees)

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

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 .

Not sure who else to help on this without aswan.

Aki, how easy is it to add an entitlement?

Flags: needinfo?(aki)

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
Assignee: nobody → haftandilian
Flags: needinfo?(aki)
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

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)

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

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

Flags: needinfo?(sandees)

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

Priority: -- → P1

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?

Thanks Haik, we will share validation results with you for the shared build.
Yes, please share those builds @sandees@adobe.com

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

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

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.

Pushed by haftandilian@mozilla.com:
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
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Summary: Strarting Firefox 68.0.1, Adobe Acrobat Extension for Firefox fails to send apple events to target application (Acrobat) → Starting Firefox 68.0.1, Adobe Acrobat Extension for Firefox fails to send apple events to target application (Acrobat)

Please make sure this goes on the ESR as well.

Blocks: 1471004

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:
Attachment #9087164 - Flags: approval-mozilla-esr68?
Attachment #9087164 - Flags: approval-mozilla-esr60?
Attachment #9087164 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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

Attachment #9087164 - Flags: approval-mozilla-esr68?
Attachment #9087164 - Flags: approval-mozilla-esr68+
Attachment #9087164 - Flags: approval-mozilla-esr60?
Attachment #9087164 - Flags: approval-mozilla-esr60+
Attachment #9087164 - Flags: approval-mozilla-beta?
Attachment #9087164 - Flags: approval-mozilla-beta+
QA Whiteboard: [qa-triaged]
See Also: → 1576733

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Version: Firefox 68 → 68 Branch
You need to log in before you can comment on or make changes to this bug.