Closed Bug 1701324 Opened 3 years ago Closed 3 years ago

Consider reverting access key of new "Copy Link" context menuitem from L to A (as before; maybe "Copy Link Address" like Chrome): Easier motor access for right-handers with common keyboard/touchpad/mouse layout

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Version:
Firefox 88
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: qznebula, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Chrome uses "Copy link address", not "Copy link"
2.83 KB, image/png
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

When opening a context menu on a hyperlink (<a> element), the menu option for copying the link address (URL) is labeled "Copy Link". Its shortcut key, which may be pressed on the keyboard to activate the option (rather than moving the mouse), is L. Using a QWERTY keyboard, this is far on the right-hand side of the keyboard.

Actual results:

Because the shortcut is L, and I use my touchpad with my right hand, I must move my hand from the touchpad, adjust it to position over the keyboard, and press L. Then I move my hand back to the tablet, its normal position, to continue navigation. This is a complex motor movement, and is difficult on the wrist, especially in repetitive circumstances.

Alternatively, I can choose to click the "Copy Link" option. But this involves moving my cursor over the menu option and pressing to click it. This is especially impractical under repetitive circumstances, where I now have to move my cursor back to the idle position, where the next link will show up (e.g. from opening a new tab or scrolling the page).

Expected results:

Until recently, the shortcut was A (as in the label "Copy Link Location"). With QWERTY layout, this is on the left-hand side of my keyboard; I virtually never lift my left hand from the keyboard, so this is always accessible.

Addendum—some related issues:

  • Bug 1690561, introduced very recently (2 months ago), is where this change was introduced.
  • Bug 758639, created several years back (9 years ago), had the same initial proposal. It was argued against, since it "makes unclear whether the target content is copied (e.g. the website it links to) or just the URL" and "may be mixed with "Save link as" option." These aren't directly related to the issue I'm bringing up here, but may be additional reason to consider reverting this particular string and shortcut change.

Another related issue: bug 1700418. This is very recent discussion (two days ago), and was closed WONTFIX, per feedback from the design team: https://bugzilla.mozilla.org/show_bug.cgi?id=1700418#c4

Personally, I feel the accessibility impacts outweigh a general a design decision. (This is my first time writing a bug report—let me know if the subject of accessibility is discussed better there!)

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Disability Access APIs
Product: Firefox → Core

Copy-pasting comment 22 from bug 423905 which I feel is relevant:

I know people using the keys in the context menu are minority, but those keys are there only for this minority group. So if you change it, it will affect 100% of those users (probably power-users / programmers, just like you are).

With an addendum that this additionally (and especially) impacts people whose wrists are weak and generally avoid unnecessary movement, thus making good use of features like context menu shortcuts.

Component: Disability Access APIs → Disability Access
Product: Core → Firefox

This doesn't seem to be an isolated issue: https://addons.mozilla.org/en-US/firefox/addon/copy-link-address-a/

I think it's difficult to make an accessibility argument here because any change will disadvantage one group in favour of another. For example, right now, "l" is difficult for users who use the mouse with their right hand. But if we change it to "a" or similar, we now disadvantage users who use the mouse with their left hand. Furthermore, changing it back to "a" would require changing the link text to include "Location" or "Address" or some other word with "a" (so it can be displayed as an accelerator), which as per bug 1700418 comment 4 was found to be confusing for some users... and of course bug 1700418 was filed in the first place because the recent change confused another set of users.

Asa, thoughts?

Flags: needinfo?(asa)

Must the accelerator key actually be a letter from the menu item label? The "Inspect" context menu item has the accelerator "q" and that's not in the word "inspect" so they simply add it after the word like this: "Inspect (Q)". Maybe we can return to using "A" as the accelerator and have the menu item simply say "Copy Link (A)".

Flags: needinfo?(asa)

(In reply to Asa Dotzler [:asa] from comment #6)

Must the accelerator key actually be a letter from the menu item label? The "Inspect" context menu item has the accelerator "q" and that's not in the word "inspect" so they simply add it after the word like this: "Inspect (Q)". Maybe we can return to using "A" as the accelerator and have the menu item simply say "Copy Link (A)".

Ah, I was wondering how the Inspect item worked visually. That might be possible, but it's certainly pretty awkward. It might be okay for a "developer" item, but it feels pretty ugly for a pretty common item like this. Also, we arguably create additional cognitive load in doing something like this (for new users, that is).

I'm more curious as to your thoughts on whether this is really an a11y argument, given my thoughts above regarding tradeoffs for left vs right handed mouse users, etc.

Flags: needinfo?(asa)

(In reply to Asa Dotzler [:asa] from comment #6)

Must the accelerator key actually be a letter from the menu item label?

No, the accelerator key, if missing in the label, is attached to the label between parentheses at the end of the label. That''s what happens for some locales (e.g. Japanese), and there are a couple of advanced settings controlling details of that behavior.

Having said that, Inspect has that because we ran out of available letters, it's not really something we should be doing on purpose.

(In reply to James Teh [:Jamie] from comment #7)

I'm more curious as to your thoughts on whether this is really an a11y argument, given my thoughts above regarding tradeoffs for left vs right handed mouse users, etc.

This is an important point—given a situation where any one circumstance isn't outright better for everyone than another, where should accessibility lines be drawn? Can accessibility lines be drawn?

A simple counterargument is to provide two shortcut keys—e.g, both "A" and "L" for "Copy Link"—but as far as I know this is unprecedented in the UI, and would quickly bring up questions of, "what about all the other shortcuts, which are left only accessible on one side of the keyboard?" Plus, keyboards are unpredictable; probably, most use QWERTY, but many don't, or have alternate devices they usually prefer instead (e.g. numpad or non-keyboard devices).

I personally believe the only way to reject placing one group (e.g. right-hand mouse users) above another is to make the interface customizable. That way, users can specify which shortcuts they like, without any limitations of arbitrary (though generally well-meaning) decisions by devs and designers. (One example of customizable shortcuts is in Krita, which I've used to bind commands like "undo" to the J key, rather than the default ctrl-Z; this is crucial as I draw with my left hand!)

I haven't gone searching, but there are almost certainly previous discussions on this matter—questions like, "how much customizability is too overwhelming?", "how do we make the UI presentable?", "is this better as an addon?", "how do we make users aware they can customize as they like?", etc. Probably best to search for those rather than presume this particular conversation is happening in a vacuum!

(In reply to James Teh [:Jamie] from comment #7)

I'm more curious as to your thoughts on whether this is really an a11y argument, given my thoughts above regarding tradeoffs for left vs right handed mouse users, etc.

I don't think this is an accessibility issue as much as a general keyboard usability issue and one that affects accelerators and shortcuts across our whole product, including several other items in our context menu.

Flags: needinfo?(asa)

In that case, moving this out of disability access.

Component: Disability Access → Menus

Setting this Enhancement as New to gain more visibility.

Status: UNCONFIRMED → NEW
Ever confirmed: true

I second this.

Yes, clarity for menu is (very) important but is it enough reason to change the accelerator key?

There is even a Firefox extension to address this "problem" (by adding new context menu with accelerator key 'A') I installed btw:
https://addons.mozilla.org/en-US/firefox/addon/copy-link-address-a/

But... I think extension here is NOT a good idea to resolve/close this.

Regressed by: 1690561
Has Regression Range: --- → yes
Keywords: regression

(In reply to Tsukasa OI from comment #13)

There is even a Firefox extension to address this "problem" (by adding new context menu with accelerator key 'A') I installed btw:
https://addons.mozilla.org/en-US/firefox/addon/copy-link-address-a/

nice. thanks. also lol

thanks @aryx @:aryx

The 10+ years of muscle memory of having this menu accelerator on the "A" is literally one of the main reasons I've continued to use Firefox over Chrome [which uses "E" for some unknown reason] or Vivaldi.

The item I am copying is the HREF location set in the selected anchor tag [ https://www.w3.org/MarkUp/1995-archive/Elements/A.html ] whomever made this change has mislabeled the context menu with a colloquialism. If you want to create a new context menu entry for link tags with the "L" menu accelerator, by all means feel free to do so. But given no one really uses "links" outside of external resources [i.e. style sheets, Javascript, etc.] it probably won't be very useful addition...

But jokes aside, this change is very annoying: as highlighted above the interaction is with an anchor, so the "A" menu accelerator is technically correct. If you want to rename the context menu entry to "Copy Anchor Link Location [RTFM, lolz]" I would be all for it. I just want my precious menu accelerator back. :'-(

Thanks for the tip about the add-on, NesteaZen. Very glad to have this reverted. Tbh this change annoys me a lot and I really hope it will be undone asap.

(In reply to Tsukasa OI from comment #13)

There is even a Firefox extension to address this "problem" (by adding new context menu with accelerator key 'A') I installed btw:
https://addons.mozilla.org/en-US/firefox/addon/copy-link-address-a/

Unfortunately, on Linux: the add-on doesn't write to the "primary selection" [i.e. clipboard], but rather send the data to the actual "clipboard selection" which makes it a lot less useful. Normally, things are sent to both "selections" or only the "primary selection"; as is the case with normal context menu option. [Confused still? See: https://specifications.freedesktop.org/clipboards-spec/clipboards-latest.txt ]

Thanks for reporting this. I also reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1707252

I use this key every day. "a" is a much better hotkey and inline with every other browser.... using "l" is worse than using the mouse 😭

This thread has been getting a fair bit of attention, which hopefully points to the wider impact it might have than some earlier comments (admittedly reasonably) suspected! I'd like to paste a comment from bug 1707134 corroborating, with a link to a reddit thread on the topic:

There's a thread about this change posted on reddit's /r/firefox which, at the time of writing, has over 600 upvotes and 180 comments. Most are similarly critical of this change:

https://old.reddit.com/r/firefox/comments/mwhtas/dear_firefox_developers_stop_changing_shortcuts/

I think this demonstrates community support for restoring the old functionality and wider concern about Firefox's constantly-changing nature.

The numbers on this thread (which, created 20 hours ago, links to this report) have grown to over 750 upvotes and nearly 300 comments, now. I won't update those numbers here again since that doesn't contribute to discussion, but I do think it's worth recognizing the wider impact of this change. A pinned comment on the reddit thread links to the extension, which is a useful workaround, but many likely have no idea of its existence, either by not accessing English internet regularly or not thinking to search online for a fix. A revision returning the "A" keybinding (whether or not in addition to "L") would be valuable to those people, too.

Addendum: I've read some comments which propose changing the shortcut from (current) "L" not to (previous) "A" but to "C", to match the shortcut used in Thunderbird. This would still take some getting used to, but on the presumption that the majority of those affected by this are users of QWERTY keyboards, it would be similarly accessible (for them) as previously. Consistency with other Mozilla products is a nice cherry on top!

The C would also make sense because it's also used to copy URL from the address-bar.
(it actually used to be C 14 years ago bug 410973)

So being consistent across menus and products sounds like an ultimate achievement that future generations will thank us for. Maybe even more software will use it then. (I'm still gonna be pressing "a" a lot instead of "c" but it's for sure 100% better than "l")

I'd be happy with "C", for reasons of:

• Sensible semantics ('"C"opy link')
• Consistency with Thunderbird etc.
• Reachability from the left-hand's position on the QWERTY home row

I'd be a lot happier if keys were fully customisable via a GUI keymap (à la Eclipse/Netbeans/PHPStorm/Photoshop etc.) and I think everyone else would as well. However I appreciate that would be a much wider challenge to implement.

I could probably learn to deal with "C" as a default, especially with the knowledge that this brings things into line with other Mozilla software.

Historical aside: I'll note that there used to be extensions (especially back during the XUL days) that allowed all the context-menus to be customized readily, including the underlined-letter shortcuts. Originally that was Menu Editor, then later Menu Wizard, both of which I believe are now broken/gone as of Firefox 45 or later API changes which made them incompatible. There are now just some guides for how to remove/reorder these things yourself via the userChrome CSS. Unfortunately, it appears it's stickier to simply change the underlined letters to whatever's preferred without yet deeper hacking. Having an underline accelerator/shortcut go to the totally-opposite side of the keyboard like this makes one regret that the aforementioned extensions are things of the past.

If accessibility is a concern for folks who mouse with their left hand, why not just have two underlines, or allow natively allow customization?

@qznebula In case you'd like to reflect this in the title, the term used to describe shortcuts associated with underlined letters in a menu is either 'mnemonic shortcut' or sometimes 'access key' or 'access-key shortcut'.

(In reply to Quasar Nebula from comment #30)

Addendum: I've read some comments which propose changing the shortcut from (current) "L" not to (previous) "A" but to "C", to match the shortcut used in Thunderbird.

Using 'C' would conflict with the Copy menu item. That's why it was changed from 'C' in bug 410973, and that reasoning still applies.

May we consider why Ctrl+D is used for bookmarking? Is it because 'bookmarks' contains a D? Rather, it is because 1) It's an easily-accessible key for the majority of users 2) It is well-established and familiar. I stand by this logic.

I also contend the logic that 10% of left-handed users are to be considered 'equally important' to 90% of right-handed users. While all users should have access to software, when it comes to minor concessions having to be made in the user experience, priority should obviously go to large majorities. I fully accept this as a member of several minorities myself, including being one of only 15% who use Win 7.

(In reply to CronoCat from comment #34)

@qznebula In case you'd like to reflect this in the title, the term used to describe shortcuts associated with underlined letters in a menu is either 'mnemonic shortcut' or sometimes 'access key' or 'access-key shortcut'.

Ah, thank you.

Summary: New "Copy Link" context menu shortcut key is motor-inaccessible in common keyboard/mouse layout → New "Copy Link" context menu access key is motor-inaccessible in common keyboard/mouse layout

(Oops, accidentally sent the above incomplete comment as part of renaming the bug. Here's the complete comment.)

*Ah, thank you. I've adjusted it to 'access key' now. (It might be redundant to have 'context menu' in the title as well, but I've left it there so the issue is more clearly visible to users unfamiliar with the term.)

(In reply to CronoCat from comment #33)

(snip)

If accessibility is a concern for folks who mouse with their left hand, why not just have two underlines, or allow natively allow customization?

Thank you for the historical context! I thought I'd seen two underlines recommended earlier, though I can't find the comment now. I'm not sure whether or not this has technical precedence, but if so, it's an option.

Native customization I discussed earlier in comment 9. I'm in agreement that it is the best option if accessibility is a concern, which, gauging by the impact-reach of this change (for QWERTY/right-hand mouse users, anyhow), it probably ought to be. However, I don't feel it's as 'on the table' as other solutions, since a feature of that scale would probably have to go through much design time Mozilla / the Firefox devs would be more interested in spending elsewhere. If it is of interest to them, I'm all for it! I'm only doubtful of this as a prompt fix for those currently affected.

Similar goes for foundational support for addons which customize access keys, ala the XUL days, as you brought up. Leaving design up to the community allows users to choose which UI they are most comfortable with, and propose improvements amongst themselves -- but it would likely be contrary to the current direction of addons, or otherwise difficult to integrate cleanly. Again, this would be a long ways off for those currently affected, but it's still a nice goal, and could well be part of a grander response to the community's concern with Firefox lacking customizability it had in past. (Ditto for native customization options.)

(In reply to Mathew Hodson from comment #35)

Using 'C' would conflict with the Copy menu item. That's why it was changed from 'C' in bug 410973, and that reasoning still applies.

Ah, got it. I'd assumed 'Copy' and 'Copy Link' would never show up simultaneously, but this is apparently still possible (drag to create a selection, then right-click a link). I suppose dynamically disabling that shortcut (leaving the only remaining one, such as current 'L') if the 'Copy' option is present is off the table?

It may be counterintuitive to have shortcut 'C' refer to both copying text, i.e. what is visible on-screen, as well as links, i.e. something not immediately visible. This gives some additional strength to using an altogether unique access key, even if it isn't a character visible in the 'Copy Link' label.

(In reply to L. James from comment #36)

May we consider why Ctrl+D is used for bookmarking? Is it because 'bookmarks' contains a D? Rather, it is because 1) It's an easily-accessible key for the majority of users 2) It is well-established and familiar. I stand by this logic.

Similar goes for Copy/Paste, which are Ctrl+C/V rather than Ctrl+C/P. (I'm actually not not sure if either of these were originally made with QWERTY-accessibility in mind, but they've certainly took on that role over time—as you mentioned, familiarity.)

Context menus are a somewhat different scope, but I'm in agreement that we can still learn from these arguments. Familiarity can get in the way of progress towards otherwise better solutions; however, here, the concern is a very minor feature which has notable impact on a significant group of people. In order to reasonably set aside familiarity, I feel a solution which does not leave the familiar group under the bus is due—or else you'll bring difficulty and upset to that group. Since all-out native customizability, while a powerful feature to aim for, is probably too much to design and implement as a prompt fix for one inconvenience, I feel keeping with what's familiar may reasonably take priority.

Please revert link copying accessor from 'L' to 'A' or change to 'C' if you feel you must change it. Others above have made the arguments well.

For me, it's mainly about having it under a key close at hand. I have to look down at my keyboard to move my left hand across to 'L' which slows me down. Isn't the point of those accessors to allow users to speed up their workflows?

If you're trying to cater to left-handed people, allow both 'A' (or 'C') and 'L' as accessors.

(In reply to Mathew Hodson from comment #35)

Using 'C' would conflict with the Copy menu item. That's why it was changed from 'C' in bug 410973, and that reasoning still applies.

(In reply to Quasar Nebula from comment #38)

This gives some additional strength to using an altogether unique access key, even if it isn't a character visible in the 'Copy Link' label.

I checked the behavior in Thunderbird, which – just to restate – uses 'C' as the access-key for both copying links in e-mails via the context-menu AND to copy selected text from e-mails via the context-menu. Thunderbird simply keeps both menu-items as 'C', and implements the typical behavior of jumping between menu-items that share a given access-key when that key is pressed with the appropriate menu open.

So in Thunderbird, if a link which is also selected has the context-menu raised on it, the key-combination to copy the text becomes C Enter whereas the input for copying the link becomes C C Enter. This case should be sufficiently uncommon that the extra keypress is worth the improved ease of use the other 95%+ of the time, no?

In the Italian localization is even worse: in Firefox88 the same key is used for 2 command, therefore when you press it, it only highlights the commands! On Firefox87 it worked perfectly.

Why aren't we talking about the elephant in the room aka Inspect Element (Q).

So obviously this is possible and very much so welcomed by the
community. I personally dont give af about aesthetics. It's one of those
"as long as bit brings me from point A to be B" type of things.
Obviously if access keys can be implemented seamlessly preferably using
only the right side of the keyboard then even better.

As for this issue, I don't care too much about A vs. C. The conservative
side in me would prefer for it to be reverted back, but I'll be happy
with the C as it's more in line with when text is selected and the
normal Copy.

(In reply to tonurics from comment #22)

The item I am copying is the HREF location set in the selected
anchor tag [ https://www.w3.org/MarkUp/1995-archive/Elements/A.html
] whomever ma [...] u accelerator back. :'-(

seems plausible and couldn't agree more

Why not just secretly keep the the "A" accessor key in addition to the new "L" accessor key? That way the people who have been using that key everyday for years will not be upset, and people who care more about aesthetics than useful accessor keys (or the hypothetical minority of left-handed people who want the accessor key to change) are also satisfied.

As an aside, the "E" accessor key for the same functionality in Chrome isn't even advertised with an underlined letter. This change does mean Chrome will gain a distinct advantage over Firefox.

A lot of focus on 'A' but the key to open a link in a new window 'W' was also changed, to 'D'. 'W' mapped nicely with opening because you could close the window with ctrl-w. It made sense. Looks like I am not the only one annoyed enough to file a bug and track what is happening here. This change seems totally arbitrary especially because we have no option to remap the keys ourselves.

BTW, the same change happend with "Copy Emai(l) Address" on "mailto:..." links - there is "L" access key too. Please, change this access key back to "A" as well. Thank you very much!

"Highlight All" in the "Find in Page" bar spent a few years as Alt+L https://bugzilla.mozilla.org/show_bug.cgi?id=435326. It was later moved back to Alt+A https://bugzilla.mozilla.org/show_bug.cgi?id=1498522.

Is "enhancement" the right type for this? Given that this was previously not a problem and only became so recently, it seems like a regression.

Chrome and older versions of Firefox consistently use "Copy link address" to refer to copying a URL. It is both technically correct and consistent with other menu items.

In both browsers, "Save link as..." saves the target resource to a file, not the link URL.

Given that behavior, to a novice user, it might be entirely unclear why "copying a link" and "saving a link" invoke entirely different behavior. If the target resource is an image, "copy link" will not copy the image, but "save link" will save the image. Why?

To be consistent, "link" should refer to the resource, while "link address" should refer to the URL.

Firefox now uses "link" inconsistently to refer to the target resource and the link URL as though they were interchangeable, which they are not.

The current naming is both less accessible and less consistent.

Correction: Firefox used to use "Copy link location", not "Copy link address". If we're going for consistency, adopting "address", along with "a" for address or "c" for copy as the accelerator key would resolve the problem.

I've filed a separate issue against Thunderbird for matching whatever Firefox does: https://bugzilla.mozilla.org/show_bug.cgi?id=1710399. I'm personally on the side of using A everywhere, since I copy far more links on Firefox compared to Thunderbird, with the additional advantage of it matching Chrome as well.

See Also: → 1710399
Summary: New "Copy Link" context menu access key is motor-inaccessible in common keyboard/mouse layout → Consider reverting access key of new "Copy Link" context menuitem from L to A (as before; maybe "Copy Link Address" like Chrome): Easier motor access for right-handers with common keyboard/touchpad/mouse layout

Hi, everyone -

We’ve reviewed all of the feedback on the label and access key change and discussed the options at length internally. Ultimately, we believe we're making the right decision for this, in terms of clarity and discoverability. This is part of a larger effort to redesign and modernized the core experience of Firefox to be cleaner, more inviting and easier to use, though we recognize this change is frustrating for some of longtime users.

Starting with the most user-visible part of this interaction, label itself, we believe “copy link” is more understandable than “copy link location” for almost everyone (most people see the Web in terms of links, not link-targets, A-HREFs or URLs) and we further believe that this label change commits us to an access key change that makes sense with it. Our options are somewhat constrained here; selection of access keys must take into account availability of letters and avoid potential conflicts with other menu items (for example, “C” is already in use for “Copy”) - and avoid the new-user hostility of seeming completely unrelated. The great majority of users do not use access keys, and even for those who do, we don't believe “Copy Link (A)” makes intuitive or discoverable sense.

We considered retaining the previous access key invisibly as well as the new one, but we quickly discarded that option; the in-product architectural changes we'd need to support multiple or invisible access keys would be a huge, uncertain engineering project in an internationalized codebase of the size and complexity of Firefox, one we can't realistically even consider. To give you as sense of the scope of such a project, access keys are assigned to menu items via the localization layer to the markup and DOM elements for each menu item. Then the C++ layer that manages the menu is what actually determines which item(s) are matched by a given access key the user pressed, by inspecting the DOM layer. The C++ layout layer is also what displays the access key in parentheses after the label, if it does not form part of the label. To add a "hidden" access key just for this item would require updating all 3 layers to support this, so adding support to our localization layer, the custom element DOM layer, and the C++ layers, and then trying to clarify to localizers when (not) to use it, hope that all our volunteer localizers understand and know how to check for conflicts with the hidden access key, and add automated tests to support this behaviour in the future. It still wouldn't be discoverable for new users, and would lead to surprising behaviour ("I pressed A and the menu closed - why, and what action just got taken?").

Without going into the same depth, the suggestion to support context menu customization would be at least that complex, and likely far more so; months of design and engineering work, to create a safe new UI to manage all the different menus, planning for all the later Firefox-offered options changing as Firefox evolves, without breaking user configuration, addons, themeing support...

If we did nothing but build these two changes maybe - maybe - we could get that done in two or three years. And when we were done we'd have nothing to show for it but menus and shortcut keys you could customize in a three-year-old browser while the world moved on.

Instead, we've made this decision, a small part of a set of design and structural decisions we believe will when you add them all up make Firefox a better, easier to navigate browser and user agent for almost everyone who's been using it for years or just trying it out for the first time.

But, yes: not everyone. If you're in this bug reading this at all, you're probably one of the people unhappy with this decision. But we think it's the right one.

If you want a left-hand-side keyboard shortcut for this or other reasons, please consider Microsoft PowerToys on Windows or Karabiner-Elements on a Mac, both of which offer powerful customization tools that let you customize your keyboard inputs to support personal workflows across any number of tools and applications. I use them both a ton, and they work great.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX

really unfortunate this change will not be reverted. in the meantime I have resorted to using this extension https://github.com/lilydjwg/copy-link-address

(In reply to Mike Hoye [:mhoye] from comment #52)

[...] Our options are somewhat constrained here; selection of access keys must take into account availability of letters and avoid potential conflicts with other menu items (for example, “C” is already in use for “Copy”) - and avoid the new-user hostility of seeming completely unrelated. The great majority of users do not use access keys, and even for those who do, we don't believe “Copy Link (A)” makes intuitive or discoverable sense.

there doesn't seem to be much good will by the devs here.
Access keys held by right-clicking a link: t w d p b k o l s
Access keys held by right-click text selected: c a r s t e
We can see two keys overlap (T, S). So I don't understand what's up with that C key
argument. ? hence to my layman understanding I guess both context menus are
independent of each other in the code. ?

I see. Maybe the problem arises when both text and a link is selected. But then again,
you'd have to get out of your way to right-click that link in order for both Copy and
Copy Link to appear. Who would do that? As opposed to right-clicking the link without
selecting anything.

If you want a left-hand-side keyboard shortcut for this or other reasons, please consider Microsoft PowerToys on Windows or Karabiner-Elements on a Mac, both of which offer powerful customization tools that let you customize your keyboard inputs to support personal workflows across any number of tools and applications. I use them both a ton, and they work great.

If you are talking about Keyboard Manager, I don't think they can change
access keys for applications. It simply changes/establishes shortcuts.

(In reply to Robert Wolf from comment #59)

Oh God! It's so simple! For everyone who wants the "A" key back:

Great catch. I'd assumed it was baked into compiled code but, with that, maybe I can find a way to hang an auto-patch-on-update script off the APT install triggers mechanism used for stuff like updating manpage and ld caches.

(In reply to Stephan Sokolow from comment #60)

(In reply to Robert Wolf from comment #59)

Oh God! It's so simple! For everyone who wants the "A" key back:

Great catch. I'd assumed it was baked into compiled code but, with that, maybe I can find a way to hang an auto-patch-on-update script off the APT install triggers mechanism used for stuff like updating manpage and ld caches.

just use the extension there already is for it.

(In reply to NesteaZen from comment #61)

(In reply to Stephan Sokolow from comment #60)

(In reply to Robert Wolf from comment #59)

Oh God! It's so simple! For everyone who wants the "A" key back:

Great catch. I'd assumed it was baked into compiled code but, with that, maybe I can find a way to hang an auto-patch-on-update script off the APT install triggers mechanism used for stuff like updating manpage and ld caches.

just use the extension there already is for it.

My browser is already bogged-down enough as-is without patching in yet more code when I could just alter the behaviour of the code that already exists. (e.g. I'm very hopeful for the bug about adding an option to have sidebar tabs without Tree Style Tab.)

@NesteaZen I have installed the extension and it's great. But on Linux it just stores the URL to clipboard X selection. On Linux, there are total three X selections: clipboard (used with ctrl-c, ctrl-x and ctrl-v), primary (just selecting text in terminal, gvim or Firefox stores the selected text in primary, and pasting the text from primary using mouse middle button click - this is really fast copy/paste operation) and secondary (I have never used this). The copy-link-address extension can copy only to clipboard, it means, in programms, which supports clipboard, I have to press ctrl-v to paste (or some other keyboard action, e.g. in gvim). Native Firefox's "Copy Link Address" copies the URL in both - clipboard and primary, and then I can just simply use middle button click to paste URL somewhere, mostly Xterm (which does not support ctrl-v, AFAIK), or gvim or even Firefox. Usually I work this way: in firefox right click on the link, press "A" to copy link, move mouse to other programm (xterm or gvim), middle button click to paste URL, repeat. In this case my right hand stays on mouse and I can paste with single middle button click, and my left hand stays on the left side of keyboard for "A" key press. And I don't need to press ctrl-v (using any left-hand gesture).

(In reply to Stephan Sokolow from comment #60)

Great catch. I'd assumed it was baked into compiled code but,

Yes, I thought the same thing. Then, I have searched FF source code and found this code in browser/locales/en-US/browser/browserContext.ftl - the ftl means Fluent Translation List. Then it was luck - I have looked through firefox installation directory and found omni.ja, then found it's zip, extracted and grepped for the "Copy Link" text. And found it with access key definition, then tried and it worked. Just luck.

with that, maybe I can find a way to hang an auto-patch-on-update script off the APT install triggers mechanism used for stuff like updating manpage and ld caches.

I have already made my patch script (nothing special, but it works) :-) Now I will try to integrate it in DEB postinstall script :-) I know, There Is More Then One Way To Do It so if you don't like some part of the script, just make it yourself as you like :-)

#!/usr/bin/env bash

omnija="browser/omni.ja"

if [ $# -eq 0 ] || [ -z "$1" ] ; then
	printf 'Usage: %s FirefoxInstallationDirectory\n' "$0" >&2
	exit 1
elif ! [ -d "$1" ] ; then
	printf 'Firefox installation directory "%s" does not exist\n' "$1" >&2
	exit 2
elif ! [ -f "$1/$omnija" ] ; then
	printf 'File %s/%s does not exist\n' "$1/$omnija" >&2
	exit 3
elif ! which zip &>/dev/null ; then
	printf 'Please, install zip\n' >&2
	exit 4
elif ! which unzip &>/dev/null ; then
	printf 'Please, install unzip\n' >&2
	exit 4
else
	omnijadir="${omnija%/*}"
	omnijafile="${omnija##*/}"
	(
		cd "$1/$omnijadir"
		unzip -qq -d "$omnijafile.dir" "$omnijafile"
		mv "$omnijafile" "$omnijafile.$( date +%Y%m%d-%H%M%S )"
		cd "$omnijafile.dir"
		perl -i -pe '$k="A" if /\.label\s+=\s+Copy\s+Email\s+Address/i; $k="a" if s/\.label\s+=\s+Copy\s+Link$/$& (URL Address)/i; s/(\.accesskey\s+=\s+)\S/$1$k/,undef($k) if /\.accesskey\s+=\s+/ and defined($k) and $k ne "";' localization/en-US/browser/browserContext.ftl
		zip -q0DXr ../"$omnijafile" .
		cd ..
		rm -rf "$omnijafile.dir"
	)
fi

For Linux users editing the omni.ja file is really the only option to restore this functionality. Sadly, the omni.ja archive is replaced with each Firefox update. So it's not a permanent solution. Someone could create a patching utility and brand it as: a tool to remove Mozilla developer "A Holes" from Firefox [by restoring the A shortcut key].

Since the development team has already spoken and closed the ticket. The best we can do is raise awareness. Mozilla was a magical place and is a force for good; it's had some recent struggles. But I remain hopeful someone over there will return to this in the future and make the populist decision against having "A Holes" that upset the existing user base.

(In reply to tonurics from comment #65)

For Linux users editing the omni.ja file is really the only option to restore this functionality. Sadly, the omni.ja archive is replaced with each Firefox update. So it's not a permanent solution. Someone could create a patching utility and brand it as: a tool to remove Mozilla developer "A Holes" from Firefox [by restoring the A shortcut key].

You are right. Using the Firefox'es update feature remove the "A" key every update. But, it's really simple to patch the omni.ja back to "A" key. And most Linux distros does use package management, where can be configured some postinstall script to patch firefox. And even if not, the user finds really fast after update, that the "A" disappeared and can just once patch the omni.ja. I prefer patching after every update to get back this key :-) Now I hope, Mozilla will not remove this plain text definitions from ftl and omni.ja files in next releases.

Since the development team has already spoken and closed the ticket. The best we can do is raise awareness. Mozilla was a magical place and is a force for good; it's had some recent struggles. But I remain hopeful someone over there will return to this in the future and make the populist decision against having "A Holes" that upset the existing user base.

It's sad, that Mozilla ignores our request. Normal user does not care about these access keys and we really need them. But at least, they could say us, that we can change simply access key in omni.ja. I am power user, I can unpack files, update text files and pack it again, probably like most of us can. So for us it's no problem to patch omni.ja.

(In reply to Robert Wolf from comment #64)

You can auto detect the installation path using:

echo $(dirname `grep -m 1 -Po "(?<=Exec=)([^[:space:]]*)" /usr/share/applications/firefox.desktop`)

I believe /usr/share/applications/ is common across distributions, but you might want to couple check and add support for others like iceweasel.

(In reply to tonurics from comment #67)

(In reply to Robert Wolf from comment #64)
You can auto detect the installation path using:
I believe /usr/share/applications/ is common across distributions, but you might want to couple check and add support for others like iceweasel.

Yes, if someone installs really firefox as a debian package, there will be sure some desktop file. So you can extend my script, if there is no param on cmdline and there is firefox.desktop, it can take path from desktop file.

But on my system, there is no desktop file. Maybe I am too much freaky or advanced, call it as you wish :-) I have DEB package, but this package has only postinstall script, which downloads firefox (and thunderbird) from mozilla as tar and unpack to /opt/firefox. I install this package of course on debian but also on gentoo :-) (don't ask the details :-) ) I made this DEB package to have one package system for software, which I want to install myself and which I want to be updated on debian with apt-get and I didn't want to maintain ebuild for gentoo. And I use windowmaker, so I don't care about .desktop files :-) I have just menu with shortcuts in my windowmaker config :-)

Major thanks to Robert Wolf for wading in and discovering that.

One hiccup I encountered though when applying that tweak though, that I figure I should mention in case anyone else runs into the same problem: I've got a number of different firefox profiles set up, and for some mysterious reason the browserContext.ftl hack only seemed to take effect on some of them -- on the others the context menu unfortunately still had L as the copy-link shortcut key. However, I found that if I started the problematic profiles with the -safe-mode flag whatever little bit of profile state was getting in the way there apparently got reset, and I could then quit and restart them back in normal mode with the change in effect.

It is of course quite irritating to have to resort to hacks like this, but I'm very grateful to those who discover them -- thanks Robert!

(In reply to Zev Weiss from comment #69)

Maybe the startupCache needs to be deleted? See https://superuser.com/a/1559926 (posted after a previous change which forced clickSelectsAll behaviour in url bar).

(In reply to Zev Weiss from comment #69)

I've got a number of different firefox profiles set up, and for some mysterious reason the browserContext.ftl hack only seemed to take effect on some of them

Do you have any Firefox with "L" key still running? I use for my new task new firefox with fresh profile (copy of template profile). I have still running some FFs with "L" and new FF runs with "L" too. FF under root and FF on other host with patched omni.ja and no running FF starts correctly with "A" key. I hope, after I stop all L-FFs and start new FF, then it will run with "A" key. Or we can solve it using purgecaches :)

(In reply to a111y from comment #70)

Maybe the startupCache needs to be deleted? See https://superuser.com/a/1559926

I can confirm, that using export MOZ_PURGE_CACHES=1 or option -purgecaches or --purgecaches starts FF with "A" key even if there are any FFs with "L" key running. But it deletes cache only for this starting FF. If I start new FF without MOZ_PURGE_CACHES or purgecaches later, it shows again "L" key. The third possibility is to create .purgecaches file. Strace shows that FF look for this file in firefox/browser (the same directory, where the omni.js is). Creating empty firefox/browser/.purgecaches file ensures starting FF with patched omni.ja and now every new FF has "A" access key.

Thank you!

Bugzilla is not a discussion forum, referring to users as "brain free" is insulting, and manually changing omni.ja will break whenever the relevant files change. I'm going to restrict comments on this bug as the decision here has been made and the bug is veering off-topic.

Restrict Comments: true
Type: enhancement → defect
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: