Open Bug 374292 Opened 15 years ago Updated 6 months ago

Remove F7 keyboard shortcut for switching caret browsing on

Categories

(Toolkit :: XUL Widgets, defect)

defect
Not set
normal

Tracking

()

ASSIGNED

People

(Reporter: Waldo, Assigned: Waldo)

References

Details

Attachments

(1 file)

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.
Attachment #258871 - Flags: first-review?(mconnor)
Not disagreeing with you, just curious about the motivation. Juicy details?
 (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.
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.
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.
(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.
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).
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.
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.
Christopher, I agree. I've found people with that mode on as well. That's why bug 194937 is so important.
Attachment #258871 - Flags: first-review?(mconnor) → review?(mconnor)
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.
Duplicate of this bug: 478572
Note that bug 476897 added a pref that allows disabling the shortcut.
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 ;))
Attachment #258871 - Flags: review?(mconnor) → review-
Duplicate of this bug: 492227
Duplicate of this bug: 657205
Duplicate of this bug: 1400749
Duplicate of this bug: 1598798

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. :-)

Flags: needinfo?(jteh)

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.

Flags: needinfo?(jteh)
Flags: needinfo?(jdiggs)
Flags: needinfo?(asa)

Asa, NI for the Product perspective on this.

(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.

Flags: needinfo?(jdiggs)

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.

Flags: needinfo?(asa)

(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.

See Also: → 1703633
You need to log in before you can comment on or make changes to this bug.