Closed Bug 1582921 Opened 5 years ago Closed 4 years ago

[10.15] With latest Firefox 69.0.1 on latest Catalina Beta 8 (19A558d)-macOS, Adobe Acrobat Extension for Firefox fails to communicate with target application (Acrobat) as one time Permission dialogue is not coming.

Categories

(WebExtensions :: General, defect, P2)

69 Branch
defect

Tracking

(firefox69 affected)

RESOLVED WORKSFORME
Tracking Status
firefox69 --- affected

People

(Reporter: sandees, Assigned: haik, NeedInfo)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36

Steps to reproduce:

install Firefox 69.0.1 on Catalina(macOs) 10.15 Beta 8 (19A558d) - (this bug is specific to the Catalina and Firefox 69.0.1)
Install and Sign In to Adobe Acrobat.
Clear all permission settings using terminal command "tccutil reset All", this is to clear permission entry if it already exists in System Preferences->Privacy->Automation

Open Firefox
Enable Acrobat extension
Open any webpage (eg. www.apple.com)
Click on acrobat extension
Click on Convert webpage to PDF

Actual results:

First time permission dialogue is not being shown which says "Firefox would like to control application Acrobat", as a result since not permission entry is getting created apple events are not being sent from extension native host launched as child process of Firefox to Acrobat and hence html to pdf conversion fails.

Expected results:

First time permission dialogue should come which says "Firefox would like to control application Acrobat" and if clicked OK, extension (native host) should be able to send apple event to Acrobat.
Another related issue that appeared in past and has been fixed : https://bugzilla.mozilla.org/show_bug.cgi?id=1570581

Attached image before.png (deleted) —
Attached image after.png (deleted) —

Please refer the attached images, ideally an entry for firefox and acrobat should be created when the permission dialogue is shown and user clicks OK(see after snap), but since the dialogue is not shown, entry remains blank (see before snap).

Attached image permission _dialogue.png (deleted) —

Moving this out of untriaged and hopefully to a better component. Also making it clear that it is 10.15 specific.

Component: Untriaged → General
Product: Firefox → WebExtensions
Summary: With latest Firefox 69.0.1 on latest Catalina Beta 8 (19A558d)-macOS, Adobe Acrobat Extension for Firefox fails to communicate with target application (Acrobat) as one time Permission dialogue is not coming. → [10.15] With latest Firefox 69.0.1 on latest Catalina Beta 8 (19A558d)-macOS, Adobe Acrobat Extension for Firefox fails to communicate with target application (Acrobat) as one time Permission dialogue is not coming.
Version: 69 Branch → Firefox 69

Hi Haik,
do you know if this is an issue due to something we should do when Firefox is running inside the "macOS Notarization/Hardened Runtime" and we are not doing yet?

Flags: needinfo?(haftandilian)

Hi, Yes, I think so. It is probably occurring because Firefox launches the extension's native messaging helper application and that uses Apple Events to talk to Adobe Acrobat and the use of Apple Events there is triggering the dialog. With the fix for bug 1576733 (which is in progress), I suspect this dialog will go away. You can assign this bug to me for now.

Edit: in a way, the dialog is accurate or at least useful to the user because Firefox is invoking the web extension's helper application which is controlling Acrobat, but the helper is Adobe's code so I think it would be better to not have the dialog attribute Adobe Acrobat behavior to Firefox.

Edit 2: I realize now that the bug was filed because the dialog is not shown the first time the user runs "Convert to PDF", but it is shown on subsequent times. This needs more investigation and may still be addressed by 1576733.

Flags: needinfo?(haftandilian)
Blocks: catalina

Thanks Haik,
I've assigned this issue to you as you suggested in comment 7 (and I marked it as P2 in the meantime, as it is likely something you are going to look into after Bug 1576733, which is marked as P1).

Assignee: nobody → haftandilian
Priority: -- → P2
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Version: Firefox 69 → 69 Branch

I'm not able to reproduce this with Firefox 70.0.1 on Catalina 10.15.1. @Acrobat, are you still able to reproduce the bug?

Flags: needinfo?(sandees)
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: