Closed
Bug 1505507
Opened 6 years ago
Closed 6 years ago
"View in Mac App Store" button from online App Store has no functionality on Mac OS X 10.10 and below
Categories
(Core :: Security: Process Sandboxing, defect, P1)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox63 | --- | unaffected |
firefox64 | --- | unaffected |
firefox65 | --- | affected |
People
(Reporter: danibodea, Assigned: haik)
References
Details
[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.
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → haftandilian
Priority: -- → P1
Assignee | ||
Comment 1•6 years ago
|
||
(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.
Assignee | ||
Comment 2•6 years ago
|
||
The problem is reproducible for me on 10.10.
Reporter | ||
Comment 3•6 years ago
|
||
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.
Assignee | ||
Comment 5•6 years ago
|
||
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
Flags: needinfo?(daniel.bodea)
See Also: → 1506776
Assignee | ||
Comment 6•6 years ago
|
||
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.
See Also: → 1452278
Reporter | ||
Comment 7•6 years ago
|
||
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!
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(daniel.bodea)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•