Closed Bug 1871447 Opened 10 months ago Closed 9 months ago

On MacOS Firefox no longer starts when called via Firefox.app/Contents/Mac/firefox-bin

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Platform:
All
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox121 --- wontfix
firefox122 --- wontfix

People

(Reporter: whimboo, Assigned: spohl)

References

(Regression,
URL
)

Details

(Keywords: regression)

Attachments

(1 obsolete file)

We have been informed that automation tools using Selenium are no longer able to start Firefox on MacOS since version 121.0 has been released. Further investigation has shown that the problem is that both Selenium and geckodriver default to Contents/MacOS/firefox-bin instead of Contents/MacOS/firefox for the default binary.

The problem can be reproduced even without these tools by just trying to start Firefox 121.0 via:

/Applications/Firefox.app/Contents/MacOS/firefox-bin

In such a case the Firefox process gets immediately killed:

✗ /Applications/Firefox.app/Contents/MacOS/firefox-bin
[1]    32539 killed     /Applications/Firefox.app/Contents/MacOS/firefox-bin

This can also be reproduced with Firefox Beta and Firefox Nightly build. By running a bisect for Nightly builds between the 120 and 121 release the regression started on November 15th. Related changesets between the last Nightly from November 14th and the first Nightly from November 15th are:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cee24679e2a2e085bdefdbd66106fa1a805db56d&tochange=d12a09b7c773efc37f5d0e37cc52339e25f07b6c

Further bisecting with builds from autoland or with local artifact builds doesn't work yet given that I'm not able to reproduce the problem with those builds.

There is also an issue with firefox headless not working when a user is not logged onto the console (true headless)

See https://github.com/mozilla/geckodriver/issues/2144#issuecomment-1866544045

My regression range was slightly wrong and after a discussion on #macdev in Matrix the regressing bug is actually bug 1853230. The log output that can be seen in the Console application is:

default	13:09:08.920685-0500	kernel	Checking in with amfid for DER firefox-bin
default	13:09:08.921056-0500	kernel	AMFI: /Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin doesn't have DER entitlements and will not work in a future release
default	13:09:08.929200-0500	amfid	/Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Applications/Firefox%20Nightly.app/Contents/MacOS/firefox-bin, NSLocalizedDescription=No matching profile found}
error	13:09:08.927766-0500	taskgated-helper	Disallowing firefox-bin because no eligible provisioning profiles found
default	13:09:08.929409-0500	kernel	mac_vnode_check_signature: /Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin: code signature validation failed fatally: When validating /Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin:
  Code has restricted entitlements, but the validation of its code signature failed.
Unsatisfied Entitlements:
default	13:09:08.929424-0500	kernel	AMFI: Releasing transmuted blob for firefox-bin - <private> 474x
default	13:09:08.929477-0500	kernel	proc 82930: load code signature error 4 for file "firefox-bin"
default	13:09:08.930013-0500	kernel	ASP: Security policy would not allow process: 82930, /Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin
URL: https://github.com/mozilla/geckodrive...
Keywords: regressionwindow-wanted
Regressed by: 1853230

Set release status flags based on info from the regressing bug 1853230

:keeler, since you are the author of the regressor, bug 1853230, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

status-firefox-esr115: --- → unaffected
Flags: needinfo?(dkeeler)

Looks like pass keys could the the culprit in the headless regression as well. Can passkeys be disabled when run in headless mode?
This is probably causing the regression as well

Seems like the solution is to use firefox instead of firefox-bin?

Severity: -- → S4
Flags: needinfo?(dkeeler)

I would say no, because that would break most Selenium environments by forcing them to reconfigure.
Also, that wouldn't fix the headless issue, nor is it ok (IMHO) to ship with a non-working binary

That sounds like it might be a separate issue. I'd file a new bug for that.

In any case, Haik, any ideas?

Flags: needinfo?(haftandilian)

Maybe it is, but my gut feeling is telling me that these are (very) connected

Duplicate of this bug: 1871426

More debugging is needed here, but from the log in comment 2, it seems clear that the problem is caused by the restricted entitlement.

Bug 1853230 added the passkey restricted entitlement and bug 1856067 added the necessary provisioning profile which is shipped in the bundle. Use of restricted entitlements requires a provisioning profile.

It appears that the provisioning profile is not applied/recognized when launching via firefox-bin. Both firefox and firefox-bin are signed with the same entitlements, but firefox is the CFBundleExecutable associated with the bundle. At this time, I don't know if we can alter the provisioning profile or make a change to the bundle's Info.plist to allow firefox-bin to also work.

One workaround might be to make firefox-bin be a symlink to firefox. That appears to work in some quick testing where I replaced firefox-bin in a bundle I had already executed locally (and hence had already passed Gatekeeper.) We'll have to make sure that doesn't run afoul of macOS's codesigning, Gatekeeper, and Notarization policies/restrictions.

Flags: needinfo?(haftandilian)
Assignee: nobody → haftandilian
Priority: -- → P1

bug 552864 attempted to make firefox-bin a symbolic link, but the updater didn't handle that back then. I don't know if it does today. See bug 658850 for the constraints.

One workaround might be to make firefox-bin be a symlink to firefox

This will not fix the headless issue which is also affecting Selenium tests.

Should I open a separate bug? This is the issue with Chrome and they haven't touched it for 3 years...
Should we be braced for complete breakage of Selenium on Mac? Firefox is the only "true" browser left that can be tested under Selenium / Mac without having to be logged into the console.

Selenium bindings need to fix that problem by using the info.plist to actually retrieve the real executable. I've created https://github.com/SeleniumHQ/selenium/issues/13350 for them. Beside that we will try to ship a new geckodriver before Christmas, but that will sadly not solve the problem if Selenium sends us the wrong binary.

(In reply to Lenny Primak from comment #12)

One workaround might be to make firefox-bin be a symlink to firefox

This will not fix the headless issue which is also affecting Selenium tests.

Should I open a separate bug? This is the issue with Chrome and they haven't touched it for 3 years...
Should we be braced for complete breakage of Selenium on Mac? Firefox is the only "true" browser left that can be tested under Selenium / Mac without having to be logged into the console.

Lenny, could you provide more details about the Selenium issue? Does the problem happen with the firefox executable as well? A link to the chromium issue would help too.

Thanks for the reply Haik,

Does the problem happen with the firefox executable as well

Yes :( I reconfigured Selenium to look for firefox instead of firefox-bin.
Sadly, it works with 120.0.1, but with 121, firefox 'hangs' while starting. This is not the same as firefox-bin which gets killed by the system.

Here's the chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1296344

I tried to reproduce the headless mode without automation in place just by running Firefox with the --screenshot argument, and starting with Firefox 121 I can see a perma crash on startup. Not sure yet if it is related to the problem Lenny mentioned but I filed bug 1871527 for it. I'll try to check with geckodriver soon as well.

Thank you!

Looks like the bug has been fixed. How can I test it to see if that was indeed the cause of the headless issue?

Also, if firefox-bin no longer works, would it make sense to actually remove it from distribution? It's better than shipping non-working file IMHO

Lenny, can you successfully run /Applications/Firefox Nightly.app/Contents/MacOS/firefox --screenshot http://example.com? Does it capture a screenshot of the web page to screenshot.png and then exits the browser? If not and it hangs please be aware of bug 1563725 as well, so you need to specify a profile via --profile <path>.

Nope.

software@nova firefox % ./123.dec23/Firefox_Nightly.app/Contents/MacOS/firefox -headless --screenshot http://example.com
*** You are running in headless mode.
2023-12-23 11:43:20.071 firefox[7221:1637013] XType: Using static font registry.
^C<hangs>

software@nova firefox % ./120.0.1_old/Firefox.app/Contents/MacOS/firefox -headless --screenshot http://example.com
*** You are running in headless mode.
2023-12-23 11:43:42.576 firefox[7228:1637344] XType: Using static font registry.
2023-12-23 11:43:42.853 plugin-container[7233:1637400] XType: Using static font registry.
2023-12-23 11:43:42.904 plugin-container[7234:1637436] XType: Using static font registry.
2023-12-23 11:43:43.055 plugin-container[7235:1637500] XType: Using static font registry.
software@nova firefox %

I encountered this because my AppleScript(?) automation stopped working after the update to 121. That automation runs a bash script that does

/Applications/Firefox.app/Contents/MacOS/firefox-bin -no-remote -p SecureProfile >/dev/null 2>&1 &

so please focus on fixing the Firefox bug rather than making workarounds in Selenium and geckodriver.

There is no indication of a problem. Nothing happens when I click on the automation shortcut. I don't know where to look for Firefox logs. When trying to run firefox-bin directly I get the same "killed(9)" reported here after I ran through the macOS rigmarole necessary to run the unsigned "firefox-bin".

(In reply to github from comment #21)

I encountered this because my AppleScript(?) automation stopped working after the update to 121. That automation runs a bash script that does

/Applications/Firefox.app/Contents/MacOS/firefox-bin -no-remote -p SecureProfile >/dev/null 2>&1 &

so please focus on fixing the Firefox bug rather than making workarounds in Selenium and geckodriver.

No, firefox-bin is not the right executable for the app bundle. See the entry in the Info.plist file:

	<key>CFBundleExecutable</key>
	<string>firefox</string>

You should really update your automation script.

(In reply to Lenny Primak from comment #20)

software@nova firefox % ./123.dec23/Firefox_Nightly.app/Contents/MacOS/firefox -headless --screenshot http://example.com
*** You are running in headless mode.
2023-12-23 11:43:20.071 firefox[7221:1637013] XType: Using static font registry.
^C<hangs>

Lenny would you mind using mozregression to find out when exactly the problem started for you? A first good check would be to have a look at the Nightly build before bug 1853230 landed. Does that one work for you? If not I would suggest to file a new bug to not collide with the conversation on this bug. Thanks.

Status: NEW → ASSIGNED
OS: Unspecified → macOS
Hardware: Unspecified → All

You should really update your automation script.

I created the script many years ago and was working fine up until FF 121. I'm sure at the time I must have found some document that told me to use firefox-bin for such automation but it is in the too distant past to recall. What is the simplest was for a bash script to extract the CFBundleExecutable from Info.plist?

I'm fairly sure that you can find some tutorial on the web to read the data from Info.plist. Otherwise just pipe the output from /Applications/Firefox.app/Contents/Info.plist through some grep etc commands. Note that firefox always worked and you can for now also just hardcode that binary.

I'm fairly sure that you can find some tutorial on the web to read the data from Info.plist

I found you can do this:

defaults read /Applications/Firefox.app/Contents/Info CFBundleExecutable
firefox

I don't know what the difference is between firefox-bin and firefox but I'm pretty sure that years ago when I create the automation script the information I found said you needed to use firefox-bin for reasons that I can no longer recall. I'll try using the bundle executable and see how it goes.

No, that nightly doesn't work either. I really don't want to file a new bug. I have a feeling it'll just go to the backlog and be forgotten.

(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #23)

(In reply to Lenny Primak from comment #20)

software@nova firefox % ./123.dec23/Firefox_Nightly.app/Contents/MacOS/firefox -headless --screenshot http://example.com
*** You are running in headless mode.
2023-12-23 11:43:20.071 firefox[7221:1637013] XType: Using static font registry.
^C<hangs>

Lenny would you mind using mozregression to find out when exactly the problem started for you? A first good check would be to have a look at the Nightly build before bug 1853230 landed. Does that one work for you? If not I would suggest to file a new bug to not collide with the conversation on this bug. Thanks.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: General → Widget: Cocoa
Product: Firefox → Core
Priority: P1 → P3

(In reply to Lenny Primak from comment #27)

No, that nightly doesn't work either. I really don't want to file a new bug. I have a feeling it'll just go to the backlog and be forgotten.

Ok, then the problem is not directly related to this regression and needs a separate investigation. As of now it's unclear how many users might be affected as well and therefore I would really appreciate if you could help nailing down the regression range and especially file a new bug about this problem. I'm happy to help with that in case there are problems with mozregression. I would do myself but sadly I cannot reproduce the issue. Thanks!

Flags: needinfo?(lenny)

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component

I don't think this has anything to do with Cocoa. Based on the Killed: 9 I think it is something to do with code signing. I don't have permissions to edit that part of the bug so can't change it back. I don't know what the difference is between firefox and firefox-bin`. They have identical sizes but they are not hardlinked. Therefore it is hard to make any guesses as to the problem.

But I have seen a couple of references to a problem described thus:

"If you replace a signed macOS binary by using cp instead of mv then macOS caches the signature, doesn't like the look of it because the file changed and kills your process when you try and start the new binary."

I would do myself but sadly I cannot reproduce the issue. Thanks!

Which issue, the original one or Lenny's headless issue?

Are you using an x86_64 Mac or an arm64 Mac? It is possible the problem only occurs on arm64.

I just thought to look in my mac's console log. I found this:

Translated Report (Full Report Below)
-------------------------------------

Incident Identifier: 7E86C6A0-2E62-460D-90D5-E77BF8F00CCB
CrashReporter Key:   EACC68E0-4776-242F-00C8-9DAF08AB57D5
Hardware Model:      Mac14,6
Process:             firefox-bin [38091]
Path:                /Applications/Firefox.app/Contents/MacOS/firefox-bin
Identifier:          firefox-bin
Version:             ???
Code Type:           X86-64 (Native)
Role:                Unspecified
Parent Process:      launchd [1]
Coalition:           com.apple.automator.Firefox Secure [2001]
Responsible Process:  [38087]

Date/Time:           2023-12-28 10:29:47.7321 +0900
Launch Time:         2023-12-28 10:29:47.6535 +0900
OS Version:          macOS 13.6.3 (22G436)
Release Type:        User
Report Version:      104

Exception Type:  EXC_CRASH (SIGKILL (Code Signature Invalid))
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: CODESIGNING 1 Taskgated Invalid Signature

Triggered by Thread:  0

Looking further down the log at the "full report" I see

  "codeSigningID" : "",
  "codeSigningTeamID" : "",
  "codeSigningFlags" : 16777216,
  "codeSigningValidationCategory" : 0,
  "codeSigningTrustLevel" : 0,

So it is definitely a code signature problem and nothing to do with Cocoa. Somebody with the relevant permissions please change the component of this bug to an appropriate component.

(In reply to github from comment #31)

So it is definitely a code signature problem and nothing to do with Cocoa. Somebody with the relevant permissions please change the component of this bug to an appropriate component.

As mentioned in comment 10, we are aware that code signing is at issue here. This can be tracked in Widget:Cocoa.

I have attached a patch that removes firefox-bin on macOS in case this is the route that we want to pursue. Previously, we have hesitated to pursue this (see bug 658850) out of concern that we might break some use cases and scripts. However, with restricted entitlements (bug 1853230) effectively having broken these use cases now, we might choose to bite the bullet now and prevent similar problems in the future.

(In reply to github from comment #30)

Are you using an x86_64 Mac or an arm64 Mac? It is possible the problem only occurs on arm64.

Maybe... The issue happens on arm64 mac (Sonoma) but doesn't happen on my Intel mac (Monterey).
Not sure if it's related to the MacOS version or the CPU architecture though.

Flags: needinfo?(lenny)

(In reply to Lenny Primak from comment #35)

(In reply to github from comment #30)

Are you using an x86_64 Mac or an arm64 Mac? It is possible the problem only occurs on arm64.

Maybe... The issue happens on arm64 mac (Sonoma) but doesn't happen on my Intel mac (Monterey).
Not sure if it's related to the MacOS version or the CPU architecture though.

I asked because I learned that on arm64 all executables have to be signed when the test programs for my project failed with the same Killed: 9 after I moved to an arm64 Mac. They were previously unsigned because they are not distributed. FWIW I'm running macOS Ventura on arm64.

However, according to codesign -d -vvvvv, firefox-bin does have a signature. The difference c/f firefox is that the former has no "Sealed Resources", whatever those are.

I ran mozregression. Took me about 2 hours. Here is the offending build:

https://phabricator.services.mozilla.com/D184524

I think if if(!headless) is added there it should be fixed

Flags: needinfo?(hskupin)

mozregression reveals the offending changeset:
/Users/lprimak/Downloads/screenshot.png

Added separate bug, as requested: https://bugzilla.mozilla.org/show_bug.cgi?id=1872516

Flags: needinfo?(hskupin)

Note that a new geckodriver has been released yesterday which uses the correct executable now:
https://github.com/mozilla/geckodriver/releases/tag/v0.34.0

I have seen this issue reported at https://github.com/mozilla/web-ext/issues/2975 and can reproduce independently of web-ext:

$ /Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin' --no-remote -profile /tmp/profd/  --version
Killed: 9

(note: I am using --version to make the test case no-op; in case it succeeds it should print the version and exit instead of launching Firefox)

According to the logs (fuller version below), the code signature validation of firefox-bin failed:

  • kernel: (AppleMobileFileIntegrity) AMFI: /Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin doesn't have DER entitlements and will not work in a future release
  • amfid: (AppleMobileFileIntegrity) [com.apple.MobileFileIntegrity.framework:default] Restricted entitlements not validated, bailing out. Error: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=<private>, NSLocalizedDescription=No matching profile found}

Excerpts of log output:

$ log show --last 1m
...
2024-01-06 23:27:30.585602+0100 0xb942d4   Default     0x0                  0      0    kernel: (AppleMobileFileIntegrity) Checking in with amfid for DER firefox-bin
2024-01-06 23:27:30.586056+0100 0xb942d4   Default     0x0                  0      0    kernel: (AppleMobileFileIntegrity) AMFI: /Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin doesn't have DER entitlements and will not work in a future release
...
2024-01-06 23:27:30.660185+0100 0xb942dd   Error       0x0                  5707   0    taskgated-helper: (ConfigurationProfiles) [com.apple.ManagedClient:ProvisioningProfiles] Disallowing firefox-bin because no eligible provisioning profiles found
2024-01-06 23:27:30.660525+0100 0xb937d5   Error       0x0                  52781  0    amfid: (AppleMobileFileIntegrity) [com.apple.MobileFileIntegrity.framework:default] Failure validating against provisioning profiles: <private>
2024-01-06 23:27:30.660564+0100 0xb937d5   Error       0x0                  52781  0    amfid: (AppleMobileFileIntegrity) [com.apple.MobileFileIntegrity.framework:default] Restricted entitlements not validated, bailing out. Error: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=<private>, NSLocalizedDescription=No matching profile found}
2024-01-06 23:27:30.660895+0100 0xb937d5   Default     0x0                  52781  0    amfid: /Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Applications/Firefox%20Nightly.app/Contents/MacOS/firefox-bin, NSLocalizedDescription=No matching profile found}
2024-01-06 23:27:30.661037+0100 0xb942d4   Default     0x0                  0      0    kernel: (AppleMobileFileIntegrity) AMFI: code signature validation failed.
2024-01-06 23:27:30.661045+0100 0xb942d4   Default     0x0                  0      0    kernel: (AppleMobileFileIntegrity) AMFI: bailing out because of restricted entitlements.
2024-01-06 23:27:30.661061+0100 0xb942d4   Default     0x0                  0      0    kernel: <compose failure [illegible log arguments]>
2024-01-06 23:27:30.661071+0100 0xb942d4   Default     0x0                  0      0    kernel: validation of code signature failed through MACF policy: 1
2024-01-06 23:27:30.661073+0100 0xb942d4   Default     0x0                  0      0    kernel: check_signature[pid: 5706]: error = 1
2024-01-06 23:27:30.661076+0100 0xb942d4   Default     0x0                  0      0    kernel: (AppleMobileFileIntegrity) AMFI: Releasing transmuted blob for firefox-bin - <private> 474x
2024-01-06 23:27:30.661146+0100 0xb942d4   Default     0x0                  0      0    kernel: proc 5706: load code signature error 4 for file "firefox-bin"
2024-01-06 23:27:30.661581+0100 0xb942d6   Default     0x0                  0      0    kernel: (AppleSystemPolicy) ASP: Sleep interrupted, signal 0x100
2024-01-06 23:27:30.661583+0100 0xb942d6   Default     0x0                  0      0    kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 5706, /Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin
2024-01-06 23:27:30.661632+0100 0xb942d6   Default     0x0                  0      0    kernel: firefox-bin[5706] Corpse allowed 1 of 5
2024-01-06 23:27:30.662550+0100 0xb93b86   Default     0x0                  86475  0    ReportCrash: Parsing corpse data for pid 5706
2024-01-06 23:27:30.662597+0100 0xb93b86   Default     0x0                  86475  0    ReportCrash: proc_name(386) = [6] <private>
...
2024-01-06 23:27:30.715447+0100 0xb93b86   Default     0x0                  86475  0    ReportCrash: (OSAnalytics) client log create type 309 result success: /Users/rob/Library/Logs/DiagnosticReports/firefox-bin-2024-01-06-232730.ips

Excerpts from ~/Library/Logs/DiagnosticReports/firefox-bin-2024-01-06-232730.ips :

...
  "bug_type" : "309",
  "procLaunch" : "2024-01-06 23:27:30.6373 +0100",
  "procStartAbsTime" : 1630258418454190,
  "procExitAbsTime" : 1630258501959571,
  "procName" : "firefox-bin",
  "procPath" : "\/Applications\/Firefox Nightly.app\/Contents\/MacOS\/firefox-bin",
  "parentProc" : "bash",
...
 "codeSigningID" : "",
  "codeSigningTeamID" : "",
  "codeSigningFlags" : 16777216,
  "codeSigningValidationCategory" : 0,
  "codeSigningTrustLevel" : 0,
...
  "sip" : "enabled",
  "exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGKILL (Code Signature Invalid)"},
  "termination" : {"flags":66,"code":1,"namespace":"CODESIGNING","indicator":"Taskgated Invalid Signature"},

See comment 10. We need to determine if we can adjust our provisioning profile to address this. If not, we should remove firefox-bin. I'll be looking into this more next week.

Flags: needinfo?(haftandilian)
Attachment #9370501 - Attachment description: WIP: Bug 1871447: Remove firefox-bin on macOS. → Bug 1871447: Remove firefox-bin on macOS. r=#mac-reviewers!

I spoke with Haik and we agreed that we would go ahead with the removal of firefox-bin at this time.

Assignee: haftandilian → spohl.mozilla.bugs
Severity: S4 → S3
See Also: → 1873442
Pushed by spohl@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d88982ef09c8 Remove firefox-bin on macOS. r=mac-reviewers,bradwerth,glandium

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

Status: ASSIGNED → RESOLVED
Closed: 9 months ago
status-firefox123: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch

:spohl is this safe for you to add a beta uplift request?
We are in the final week of beta for Fx122

Flags: needinfo?(spohl.mozilla.bugs)

Landing this patch in this bug was probably not a good idea. It's not fixing the bug as originally reported. It would have been better to land it in a separate bug and mark this bug as wontfix.

Blocks: 1873782

(In reply to Markus Stange [:mstange] from comment #47)

Landing this patch in this bug was probably not a good idea. It's not fixing the bug as originally reported. It would have been better to land it in a separate bug and mark this bug as wontfix.

Agreed. I requested a backout of the patch here and have filed bug 1873782 to land it there instead. Leaving n-i set for Haik in case we can conclusively determine what our options would have been regarding the provisioning profile.

Flags: needinfo?(spohl.mozilla.bugs)

Backed out as requested for landing under the wrong bug number and for better understanding of the changes made in the future.

Status: RESOLVED → REOPENED
status-firefox123: fixed → ---
Resolution: FIXED → ---
Target Milestone: 123 Branch → ---

Comment on attachment 9370501 [details]
Bug 1871447: Remove firefox-bin on macOS. r=#mac-reviewers!

Revision D197419 was moved to bug 1873782. Setting attachment 9370501 [details] to obsolete.

Attachment #9370501 - Attachment is obsolete: true

Closing as WONTFIX since we have decided to remove firefox-bin instead (bug 1873782).

Status: REOPENED → RESOLVED
Closed: 9 months ago → 9 months ago
Resolution: --- → WONTFIX

It is unlikely to be supported, but we've asked Apple for clarification about this case--where a helper executable that is not the CFBundleExecutable uses a restricted entitlement and is invoked directly via command line.

I haven't got an answer on this from Apple and at this point we've already shipped removal of firefox-bin making it a moot point.

Flags: needinfo?(haftandilian)
See Also: → 1891167
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: