Enable built-in macOS touch bar customization support

NEW
Unassigned

Status

()

P3
normal
25 days ago
22 days ago

People

(Reporter: ntim, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

25 days ago

So it's apparently a one-liner, but it crashes Firefox when :harry tested it a while ago. Might be different now, worth investigating here :)

(Reporter)

Comment 1

25 days ago

Hey Harry, do you think you could post what you tried ?

Flags: needinfo?(htwyford97)

Hi Tim, there's an attachment bug 1313429 that contained some WIP code for scrubbers and Apple's customization palette. Link: https://bug1313429.bmoattachments.org/attachment.cgi?id=8987983

The above patch mostly changed /widget/cocoa/nsMenuBarX.mm to add the "Customize Touch Bar..." menu item using [NSApp toggleTouchBarCustomizationPalette:sender]; Apple's one-liner put the "Customize Touch Bar..." menu item beneath "Quit Firefox" in the app menu, which was a bit weird, so I placed it manually. That patch also sets self.customizationIdentifier in nsTouchBar.mm, which is necessary to use the customization menu.

My best guess as to why the customization palette crashes Firefox (after enlisting some help from :mconley and :mstange) was that the palette was attaching itself to Firefox's hidden window. When one left the customization palette, there was some freakout in Gecko about the hidden window and the main window not having the same properties, causing the crash. Again, that's just a guess.

One more issue blocking using the use of the customization palette is how the Touch Bar patch ended up being designed after this roadblock. Currently, the Cocoa code initializes the Touch Bar. nsTouchBar.mm asks MacTouchBar.js for the layout, then fills out the Touch Bar using that layout. The Cocoa code has no idea what the full possible set of inputs is: only the front-end does.

In order to use Apple's customization palette, every input needs to be predefined in the Cocoa code, then the use of some magic variables dictates which ones are the default set, and which ones appear in the customization menu. If we got this customization palette to work, then get layout() in MacTouchBar.js would have to send back every available input, then nsTouchBar.mm would do the filtering on which ones appeared. This would make adding a new input slightly less trivial, since it would have to be added to kImplementedInputs in MacTouchBar.js, then specified in nsTouchBar.mm if is part of the default set or the customization set. Either that, or we take out the front-end part of the Touch Bar code entirely...

Apple's docs on Touch Bar customization are here: https://developer.apple.com/documentation/appkit/nstouchbar?language=objc#2587638

I was thinking that if the customization palette continues to be incompatible with Gecko, then we might be able to achieve in-house developed customization in the "Customize..." menu?

Flags: needinfo?(htwyford97)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.