Enable built-in macOS touch bar customization support

ASSIGNED
Assigned to

Status

()

enhancement
P3
normal
ASSIGNED
5 months ago
4 days ago

People

(Reporter: ntim, Assigned: harry)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Reporter

Description

5 months 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

5 months ago

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

Flags: needinfo?(htwyford97)
Assignee

Comment 2

5 months ago

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
Assignee

Comment 3

4 days ago

This patch also fixes the Home and Sidebar Touch Bar buttons, since using them after customizing showed that they no longer worked.

Assignee

Comment 4

4 days ago

I decided to remove the ui.touchbar.layout pref, since it was originally introduced as a workaround for not having proper customization. Furthermore, I think keeping it would introduce confusing behaviour: it would no longer set the layout but rather just the default layout. Any users that use this new native customization window would find that ui.touchbar.layout no longer did anything, since they have a custom layout that overrides the default.

Removing the pref will cause a one-time reset to the default for users' Touch Bars. I don't foresee this being a major issue, since telemetry shows that virtually nobody uses any Touch Bar inputs but the defaults (i.e., they do not customize).

I've attached a diff that re-introduces the ui.touchbar.layout pref, so we have it if there's strong disagreement with removing ui.touchbar.layout.

Assignee: nobody → htwyford
Status: NEW → ASSIGNED
Assignee

Comment 5

4 days ago

To be clear, if we kept ui.touchbar.layout, we would retain the ability to modify the Default Set in this screenshot via pref experiments. I don't see huge value in that, but I thought I'd post here to see if anyone disagrees.

You need to log in before you can comment on or make changes to this bug.