Use case: Extensions might want to have a button "adjust shortcuts/hot keys", which opens this page. (preferably scrolled to their own extension)

Solution 1: The UI introduced in bug 1303384 should be linkable, i.e. one should e.g. be able to get to about:addons#shortcuts to manage the shortcuts.

Or
Solution 2: introduce a new WebExtension API that opens this page. (preferably scrolled to their own extension)

This idea came up in https://github.com/keepassxreboot/keepassxc-browser/issues/389#issuecomment-475847006.

Great, now what is the solution you want to pursue: 1 or 2 (as explained in the OP)?

This is a good first bug, and relevant for the currently active Outreachy project because this task shows how one can extend a new extension API AND make changes to about:addons.

To get started, see https://wiki.mozilla.org/WebExtensions/Contribution_Onramp

The browser.runtime.openOptionsPage API method can be extended to take a parameter to open the extension shortcuts management page.

The method is implemented at https://searchfox.org/mozilla-central/rev/919607a3610222099fbfb0113c98b77888ebcbfb/toolkit/components/extensions/parent/ext-runtime.js#131-140 .

The desktop version of the API is at https://searchfox.org/mozilla-central/rev/919607a3610222099fbfb0113c98b77888ebcbfb/browser/components/extensions/parent/ext-browser.js#112-130 ,
the mobile version of the API is at https://searchfox.org/mozilla-central/rev/919607a3610222099fbfb0113c98b77888ebcbfb/mobile/android/components/extensions/ext-android.js#640-669 .
Since shortcuts are uncommon on mobile, the new API method only needs to be supported on desktop. When the new property is passed on mobile, an error should be thrown.

When about:addons is opened, an internal URL (addons://...) is used. This internal URL can be viewed through the devtools by executing history.state in the console. Currently, the URL is just addons://shortcuts/shortcuts. To support the ability to jump to a specific extension, the extension ID can be set as the last parameter, e.g. addons://shortcuts/<extension ID here>. This parameter would then become available as the param value in the show method in aboutaddons.js - see https://searchfox.org/mozilla-central/rev/919607a3610222099fbfb0113c98b77888ebcbfb/toolkit/mozapps/extensions/content/aboutaddons.js#4615-4620,4639-4647 .

(In reply to Rob Wu [:robwu] from comment #2)

This is a good first bug, and relevant for the currently active Outreachy project because this task shows how one can extend a new extension API AND make changes to about:addons.

To get started, see https://wiki.mozilla.org/WebExtensions/Contribution_Onramp

The browser.runtime.openOptionsPage API method can be extended to take a parameter to open the extension shortcuts management page.

The method is implemented at https://searchfox.org/mozilla-central/rev/919607a3610222099fbfb0113c98b77888ebcbfb/toolkit/components/extensions/parent/ext-runtime.js#131-140 .

The desktop version of the API is at https://searchfox.org/mozilla-central/rev/919607a3610222099fbfb0113c98b77888ebcbfb/browser/components/extensions/parent/ext-browser.js#112-130 ,
the mobile version of the API is at https://searchfox.org/mozilla-central/rev/919607a3610222099fbfb0113c98b77888ebcbfb/mobile/android/components/extensions/ext-android.js#640-669 .
Since shortcuts are uncommon on mobile, the new API method only needs to be supported on desktop. When the new property is passed on mobile, an error should be thrown.

When about:addons is opened, an internal URL (addons://...) is used. This internal URL can be viewed through the devtools by executing history.state in the console. Currently, the URL is just addons://shortcuts/shortcuts. To support the ability to jump to a specific extension, the extension ID can be set as the last parameter, e.g. addons://shortcuts/<extension ID here>. This parameter would then become available as the param value in the show method in aboutaddons.js - see https://searchfox.org/mozilla-central/rev/919607a3610222099fbfb0113c98b77888ebcbfb/toolkit/mozapps/extensions/content/aboutaddons.js#4615-4620,4639-4647 .

Hello Rob Wu,
I am on the Outreachy Internship program and I will like to work on this bug.

Hi Rob Wu, I am an Outreachy applicant and I'd like to work on this

Thanks for signaling interest in this bug. Given the scarcity of good-first-bugs, we consider bugs open for patches until a patch is attached.

In the unexpected case that two people independently made much progress on a patch, we will still provide feedback on the patches to help you with familiarizing yourself with the project. Good-first-bugs exist to help newcomers to start with contributing to this project (setting up the environment, running tests, etc.). The following step is to work on a more challenging bug, to demonstrate enough proficiency to succeed in the "Improve Firefox to give users more control over add-ons in Container tabs" project on Outreachy.

Hi Rob Wu, I recently submitted a patch for this bug. Please kindly review and provide me with feedback.

Hey Kuthumi, do you need help with anything? Please feel free to ask Rob or me.

Hi Kumuthi, since we haven't heard from you in awhile, we're going to open this bug up to other contributors. If you'd like to come back and finish it, leave a comment and we'll reassign it to you. Thanks!

Yes I'd like to come to finish it. I was away for a while, I apologize for not staying in touch.

Is this bug still open? If so, I would love to work on it.

Thanks

Hi Rayvan, go for it! If you haven't already done so, please check out comment #2 for help getting started. :) We'll assign you to the issue once you submit a PR.

Hi, I'm Garima, an Outreachy participant. If no one is working on this bug, I'd love to! :)

Hi Garima! It looks like Rayyan expressed interest in this bug -- let's give them a few more days to submit a patch for review before you start working on it. :)

What Outreachy project are you interested in applying for? I want to make sure that we can connect you to some issues that will put you in contact with the project mentors.

(In reply to Caitlin Neiman [:caitmuenster] from comment #15)

Hi Garima! It looks like Rayyan expressed interest in this bug -- let's give them a few more days to submit a patch for review before you start working on it. :)

What Outreachy project are you interested in applying for? I want to make sure that we can connect you to some issues that will put you in contact with the project mentors.

Hi Caitlin! Yeah sure, I'll wait for Rayyan to submit his patch. I'm interested in the project "Improve the Firefox site data manager UI". :)

Hi
I am actively working on the issue. However, I am a full-time student, so I am working at a slower pace.
Thank you for being patient with me.

some news on this ?

It would be great to have something like this; I've found that extension users are often confused about how to manage their shortcuts, and walking them through the menu dive is poor UX, and an error-prone process.

That said, it's not clear to me that extending openOptionsPage to take a "shortcuts" option is the way to go. Might this not cause future issues if other browsers elect to extend openOptionsPage in a different way?

It seems to me that a simpler method might be to allow tabs.create to open a page like about:addons/shortcuts. Chrome allows a similar approach, like chrome.tabs.create({ url: "chrome://extensions/shortcuts" }). This would seem to relate to https://bugzilla.mozilla.org/show_bug.cgi?id=1269456

If someone from Mozilla could provide some guidance as to what approach makes the most sense, I'd be happy to work on a patch for this.