1505507 - "View in Mac App Store" button from online App Store has no functionality on Mac OS X 10.10 and below

Status: RESOLVED WORKSFORME

(Core :: Security: Process Sandboxing, defect, P1)

Description

[Daniel Bodea [:danibodea]]

[Note]:
- The "View in Mac App Store" button from the online App Store has no functionality on Mac OS X 10.10 and below when the "security.sandbox.content.mac.earlyinit" pref is "true".

[Affected versions]:
- Nightly v64.0a1

[Affected platforms]:
- Mac OS X 10.9.5 -> affected
- Mac OS X 10.10.5 -> affected
- Mac OS X 10.11.5 -> unaffected
- Mac OS X 10.12.6 -> unaffected
- Mac OS X 10.13.6 -> unaffected
- Mac OS X 10.14 -> unaffected

[Steps to reproduce]:
1. Open browser.
2. Go to about:config and make pref "security.sandbox.content.mac.earlyinit" as "true".
3. Restart browser.
4. Reach the following page:
https://itunes.apple.com/us/app/world-of-tanks-blitz/id1068932208?mt=12
5. Click on the "View in Mac App Store" button.

[Expected result]:
- "Launch Application" pop-up is displayed to choose which app to open the link with OR the App Store application is opened.

[Actual result]:
- The button has no functionality.

[Additional notes]:
- While having tested on 5 different Apple devices, this issue does not seem to be related to the device itself, but only to the OS running on it.

Comment 1

[Haik Aftandilian [:haik]]

(In reply to Bodea Daniel [:danibodea] from comment #0)
> [Note]:
> - The "View in Mac App Store" button from the online App Store has no
> functionality on Mac OS X 10.10 and below when the
> "security.sandbox.content.mac.earlyinit" pref is "true".
> 
> [Affected versions]:
> - Nightly v64.0a1

Could you confirm this occurs on Nightly 65? (We should only use Nightly 65 for this testing.)

> [Affected platforms]:
> - Mac OS X 10.9.5 -> affected
> - Mac OS X 10.10.5 -> affected
> - Mac OS X 10.11.5 -> unaffected
> - Mac OS X 10.12.6 -> unaffected
> - Mac OS X 10.13.6 -> unaffected
> - Mac OS X 10.14 -> unaffected

I tested on 10.9.5 on a 2008 MacBook (Unibody) and could not reproduce the problem. I'll try on 10.10.

Comment 2

[Haik Aftandilian [:haik]]

The problem is reproducible for me on 10.10.

Comment 3

[Daniel Bodea [:danibodea]]

I meant to write v65.0a1, sorry for the typo. I am aware that the feature is only in Fx65.
Furthermore, after testing on different machines with different OS versions, this is the only rule that could be deducted. It occurred on every one of my machines that had Mac OS X 10.10 and 10.9 and it did not occur on any of the other OS versions.

Comment 5

[Haik Aftandilian [:haik]]

Bodea, with the fix for bug 1506776 I can't reproduce this problem anymore. Could you confirm that is the case for you too? Bug 1506776 just got fixed in Nightly 2018-11-21.

The build I tested was a 2018-11-21 build. From about:buildconfig,

  Built from https://hg.mozilla.org/mozilla-central/rev/7488645b27ac9b273d6785db04204684673b3657

Comment 6

[Haik Aftandilian [:haik]]

With the debugging of this problem done so far, prior to the landing of bug 150776, the problem is that nsOSHelperAppService::OSProtocolHandlerExists() returns aHandlerExists=false causing the App Store button to not work.

The change in bug 1506776 added back access to CoreServices to the content sandbox. I've noticed that on 10.10 without CoreServices, during startup, Apple library code in the content process attempts to read-metadata/stat programs in /Applications including the App Store and each of these generates sandbox violations being reported. With CoreServices added back, those violations are not reported. It seems likely that without CoreServices, the process gets its own database of locally installed applications. However, due to the sandbox filesystem restrictions the database ends up being empty because stat'ing of the installed applications is blocked and that causes nsOSHelperAppService::OSProtocolHandlerExists() to return aHandlerExists=false causing the App Store button to not work.

The fix for bug 1452278 (which I plan to work on again) is related to this problem. It moves the work done in nsOSHelperAppService::OSProtocolHandlerExists() to the parent process. Testing with those development changes, I couldn't reproduce this problem either.

Comment 7

[Daniel Bodea [:danibodea]]

Haik, you are right, it does not reproduce and it's the same with bug 1506103. I will mark this one as RESOLVED WORKSFORME and we'll keep an eye out in case it returns. Thanks!