374292 - Remove F7 keyboard shortcut for switching caret browsing on

Status: NEW

(Toolkit :: UI Widgets, defect)

Description

[Jeff Walden [:Waldo]]

Attachment: Remove the binding

Is there a legitimate use case for dynamic toggling of caret browsing?  Furthermore, does this use case provide sufficient utility to override the disutility the shortcut provides to the thousands of users who accidentally enable it this way and can't figure out how to disable it?  The warning dialog is not enough, as I'm sure MozillaZine support forum people could testify.

I think the answer to these questions is no, and I've recently become motivated enough to actually do something about it.

Comment 1

[Mardeg]

Not disagreeing with you, just curious about the motivation. Juicy details?

Comment 2

[:Gavin Sharp [email: [e-mail]]]

 (In reply to comment #0)
> Is there a legitimate use case for dynamic toggling of caret browsing?

I'm sure some people would argue that an accessibility feature that isn't easily accessible isn't of much use.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(note also bug 334169)

Comment 4

[Jeff Walden [:Waldo]]

Easily accessible == in the preference window of whatever application is using the toolkit; if there isn't such a setting, then that's the application's problem, not the browser widget's problem.

> (note also bug 334169)

Options are useful when there's a genuine choice; I don't think there is one here.

Comment 5

[Aaron Leventhal]

It's used quite a bit. Keyboard-only users need to be able to select. I think the more important thing here is that the F7 setting is temporary and isn't remembered between sessions.

See bug 194937. Mark Pilgrim was very close to getting that fixed, but he doesn't work on Mozilla anymore.

The dialog pref would still persist, but F7 wouldn't. At least that takes care of the concern that people get it stuck on without realizing it, and it never gets turned off.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #4)
> Easily accessible == in the preference window of whatever application is using
> the toolkit; if there isn't such a setting, then that's the application's
> problem, not the browser widget's problem.

That's not quite as easily accessible as a keyboard shortcut, of course. Perhaps instead of removing it entirely, we should just make it harder to hit accidentally. Requiring a modifier like Shift would do that, right?

> > (note also bug 334169)
> 
> Options are useful when there's a genuine choice; I don't think there is one
> here.

I wasn't suggesting we should fix that bug as it is currently summarized. I wanted to record the number in case we do end up fixing this bug, because then we could close that one. It also is an attempt at a solution to the same problem.

Comment 7

[Jesse Ruderman]

Are people accidentally enabling Caret Browsing because of the F7 keyboard shortcut, because of the vaguely worded pref, or some other way?

If it's the keyboard shortcut, possible solutions other than removing the shortcut include making the change temporary (bug 194937) and making the dialog clearer (starting with bug 358970).  Or maybe a different keyboard shortcut could be used that's harder to hit accidentally.

If it's the pref, the pref should be reworded (bug 271420).

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

In my experienceat the various conferences I've attended over the years, I've had around 10 or so people show me a browser with caret mode on and wondering how to "fix it".  In each case, the conclusion was they accidentally hit F7.  They'd admitted to remembering a random dialog pop up around when it happened but hadn't bothered to read it.

Comment 9

[Benjamin Smedberg]

There are editing systems like mozile that explicitly ask you to turn caret browsing on with F7. I think that if we remove the access key we should provide a way for web script to turn it on/off.

Comment 10

[Aaron Leventhal]

Christopher, I agree. I've found people with that mode on as well. That's why bug 194937 is so important.

Comment 11

[quazgar]

Making the binding configurable with addons like keyconfig should work for most use cases as well, I think.  Here it's a buggy window manager (KDE4...) that wrongly sends the F7 to firefox when switching sessions via Ctrl-Alt-F7.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Note that bug 476897 added a pref that allows disabling the shortcut.

Comment 14

[Mike Connor [:mconnor]]

Comment on attachment 258871 [details] [diff] [review]
Remove the binding

From discussion, this isn't sufficient (and is probably bitrotted severely, but that's beside the point ;))

Comment 19

[:Gijs (he/him)]

Jamie, what do you think the ideal state is here? This (esp. the shortcut) continues to bite people who don't want this feature, so it'd be nice if we could come up with a UX that was less footgunny. :-)

Comment 20

[James Teh [:Jamie]]

For the users that need this (which is anyone who can't/doesn't want to use a mouse and doesn't use a Windows/Mac screen reader), requiring them to trawl through our massive Options dialog to find this setting is a pretty huge access barrier. Sure, you can search the dialog, but that's not particularly intuitive. Also, it's worth noting that Microsoft are implementing this in Chromium-based Edge, which gives at least an anecdotal indication that this is still considered necessary enough for them to invest in it.

Joanie, I believe Orca relies on caret navigation in Firefox to some extent? I know you have to work around Gecko bugs, but I assume it still has to be enabled in order for Orca users to use Firefox? Does it get enabled by default for orca users or do Orca users have to press f7? I vaguely recall it being auto enabled, but I can't find any code anywhere that would do that.

Comment 21

[James Teh [:Jamie]]

Asa, NI for the Product perspective on this.

Comment 22

[Joanmarie Diggs]

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

Joanie, I believe Orca relies on caret navigation in Firefox to some extent?

For text selection. While Orca controls the caret via AT-SPI2/ATK for caret browsing, this works regardless of whether or not Gecko's native navigation support is enabled. HOWEVER, there is currently no good way to control text selection spanning multiple objects via AT-SPI2/ATK. And Orca does not have any virtual buffer or equivalent. Therefore Orca users rely upon native caret navigation for this purpose.

I know you have to work around Gecko bugs, but I assume it still has to be enabled in order for Orca users to use Firefox?

If they don't need text selection no, it doesn't need to be enabled.

Does it get enabled by default for orca users or do Orca users have to press f7?

The latter. But at the present time, once they enable it, it stays enabled. I don't think most Orca users are repeatedly toggling it on off. So, yes, it would be a drag to have to find the option in some menu or dialog the first time, but after that not much of a big deal. Though it would potentially be an inconsistency as Gecko and WebKit and GNOME's PDF reader and Gtk+ all support F7 for enabling caret navigation.

I vaguely recall it being auto enabled, but I can't find any code anywhere that would do that.

I remember asking for some sort of autoenabling -- and not just for Gecko. But no one seemed to bite. I'm on holiday at the moment, but if it really matters I can try to find those ancient RFEs I filed.

Comment 23

[Asa Dotzler [:asa]]

Let's not break the current behavior for those who need it. Instead, let's look at ameliorating the unintended enabling with q fix at bug 194937.

Comment 24

[James Teh [:Jamie]]

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

Let's not break the current behavior for those who need it. Instead, let's look at ameliorating the unintended enabling with q fix at bug 194937.

One potential issue here is that as per comment 22, Orca requires this for text selection, and other browsers support this (even Chrome now) and it stays enabled once enabled. So, this would make Firefox inconsistent with other browsers, potentially to the detriment of some users.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:mstriemer, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 27

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.