Re: Apple Notary Service and Debugging Impact
FWIW, I tend to debug local builds of these individual branches to make my life easier, for example by turning optimization off etc. It has only been a handful of times that I had to debug an official build. Having to disable SIP to debug isn't ideal, but tolerable given how infrequently this would be necessary. I'd be interested to hear if others have had to debug official builds more frequently. -spohl On 1/11/19 6:36 PM, Haik Aftandilian wrote: Please take a look if you debug Firefox on macOS. Apple's notary service[1] is a new way to sign macOS applications that has some security benefits[2] and provides a slight user experience improvement[3] when users download the application and run it for the first time. Specifically, the dialog users have to click through to start the application is less of a warning. We are working on adopting the service on bug 1470607, but I wanted to share how this will affect debugging and get some feedback. If an application is "notarized", starting with macOS 10.14, the OS will prevent debuggers from attaching to the application unless the user has disabled macOS system integrity protection (SIP)[4] which requires a reboot. This prevents debugging of the application with a debugger like lldb or gdb on a default system. Assuming the debugging restriction will _not_ apply to the Nightly channel, local builds, or automation builds, will this debugging restriction+workaround on official builds (Release, Beta, DevEd) be a problem for your workflow or in any way you can envision? Apple has stated that signing with the notary service will be required in a future macOS version. I think we can assume that this means an application that is not notarized will require special steps for first launch where the user may also have to click through dire security warnings. Today, launching Firefox for the first time on Mac already requires clicking through one warning. The bug includes a screenshot[3] showing how it will change with notarized builds. Thanks, Haik 1. https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution 2. Using the service A) submits the application to Apple to run malware checks on the binaries and B) requires setting some executable security flags known as Hardened Runtime. At present, Firefox mostly does not benefit from enabling Hardened Runtime for various reasons. Another benefit relates to how a single version of the application can be revoked, without having to revoke all versions signed with the same key. 3. https://bug1470607.bmoattachments.org/attachment.cgi?id=9036014 4. https://support.apple.com/en-us/HT204899 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What are your use cases for the Touch Bar on the new MacBook Pro?
Thank you to everyone who has shared ideas so far. I've compiled a project plan for this feature here: https://docs.google.com/document/u/0/d/1hX5IVeFRdLyBCcMu9F_6rQi4wdmLv46UWmJ5muRpwcw/pub tl;dr: The proposed path forward is to build a WebExtensions API that can be used by both system addons and third-party addons. This allows for individual teams to develop their own WebExtensions for specific use cases without requiring dedicated widget:cocoa work. Additional input and comments always welcome. -spohl ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What are your use cases for the Touch Bar on the new MacBook Pro?
I can see the advantage of addons exploring and iterating on this, but making the first version of this API addon-accessible might unnecessarily delay it. If there is enough interest in this, we might want to start this effort in parallel and release it in a subsequent version. On 1/3/17 4:31 PM, Ryan VanderMeulen wrote: > Will this API be accessible to addons? Seems like this would be a good > place for people to explore and iterate. > > On 1/3/2017 12:17 PM, Stephen A Pohl wrote: >> We will develop[1] a solid 1.0 API around the top features to get the >> ball rolling and will iterate on these going forward. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
What are your use cases for the Touch Bar on the new MacBook Pro?
We are gathering ideas for possible use cases of the Touch Bar on the new MacBookPro and would like to hear from you! What would improve your workflow? What would help our users? We will develop[1] a solid 1.0 API around the top features to get the ball rolling and will iterate on these going forward. Apple has outlined guidelines and best practices[1] for the Touch Bar that are good to keep in mind. Here are some of the most important points to consider: 1. Design a contextual experience. Make the Touch Bar relevant to the current context on the main screen. 2. Use the Touch Bar as an extension of the keyboard and trackpad, not as a display. 3. **Don’t expose functionality solely in the Touch Bar. 4. Avoid using the Touch Bar for tasks associated with well-known keyboard shortcuts. -Stephen [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1313455 [2] https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/AbouttheTouchBar.html#//apple_ref/doc/uid/2957-CH104-SW1 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How an application should be bundled with Xulrunner 34+ on MacOS?
Hi Laurent, The problem that you seem to be running into is the fact that application bundles (Firefox) and framework bundles (xulrunner) differ in their file organization [1]. They used to be identical prior to Firefox 34, but as you can see in the bugs that you referenced, a change to the structure of the Firefox application bundle became necessary to support Apple's v2 signatures. Prior to Firefox 34, all files were expected to be in Firefox.app/Contents/MacOS. This flat structure (all files in the same directory) is the structure that is still expected by framework bundles. In Firefox 34, the structure changed to the following: 1. Firefox.app/Contents/MacOS: Compiled code such as executables (firefox), dynamic libraries (*.dylib), additional .app bundles (crashreporter.app) 2. Firefox.app/Contents/Resources: Any non-compiled code (dependentlibs.list, any scripts etc.) If running SlimerJS via xulrunner is a mode that you want to keep supporting (running it via the firefox binary seems to be working fine), it may be necessary to write a patch to support both flat structures (for framework bundles) and the more complex structure (for application bundles). -Stephen [1] https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/1123i-CH101-SW1 On 2/22/15 9:52 AM, laurentj wrote: > Hi, > > Since Gecko 34, there are some changes in how Firefox is bundled for > MacOS: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1046906 > http://hearsum.ca/blog/upcoming-changes-to-mac-package-layout-signing.html > > https://bugzilla.mozilla.org/show_bug.cgi?id=1047584 > https://bugzilla.mozilla.org/show_bug.cgi?id=1050944 > > The result is that XulRunner does not work anymore on MacosX, we have > an error "Couldn't load XPCOM": > > https://bugzilla.mozilla.org/show_bug.cgi?id=1105044 > > And so my project, SlimerJS, doesn't work anymore. > > This bug has been closed as "Invalid" (???). It seems that I should > reorganize my files (or perhaps patch XulRunner). I tried several > organizations but it doesn't work. > > I would like to understand what should be the files structure (the app > + xulrunner), at least in theory. Then I could provide a patch for > XulRunner if needed. > > thanks > > Laurent > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
