Closed Bug 1620181 Opened 5 years ago Closed 5 years ago

Alt + R cannot be used to reload page

Categories

(Firefox :: Keyboard Navigation, defect)

Product:
Firefox
Component:
Keyboard Navigation
Platform:
Desktop
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix

People

(Reporter: jmgonk, Unassigned)

Details

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

Steps to reproduce:

Attempting to make Firefox on Linux work with the (really) old-style Alt as the accelkey (so I can use Alt + R to reload, Alt + F to find, etc.).

  1. open about:config
  2. set ui.key.accelKey to 18
  3. set ui.key.menuAccessKey to 17
  4. restart Firefox
  5. go to any web page and attempt to reload page with Alt + R

I have experimented with various combinations of values for the ui.key settings. The only trigger to the problem seems to be setting accelKey to 18.

Actual results:

It will either go into Reader View or do nothing. Force reloading with Shift + Alt + R will reload the page.

This has been a problem ever since the addition of Reader View. Is it hardcoded to grab Alt + R?

Expected results:

Alt + R should do a normal reload, Shift + Alt + R should to a cache bypass reload.

Tested with Firefox 73.0.1 on MacOS, same behaviour.

Regardless of the other ui.key settings, if accelKey is set to 18, Alt + R enters Reader View instead of reloading the page, and regardless of the ui.key settings, to enter Reader View requires using Alt + R; possibly in combination with whatever key accelKey is set to.

So with what I have seen so far, perhaps a better way to phrase the problem would be that the ui.key settings are not being respected by all parts of Firefox.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core

Go home Bugbug, you're drunk.

Component: CSS Parsing and Computation → Untriaged
Product: Core → Firefox

Hello I have managed to reproduce the issue with the STR provided in the description. I will assign this issue to a component so one of our developers can look further on this issue. If the component is not the correct one please feel free to change it to the according one.

Status: UNCONFIRMED → NEW
status-firefox73: --- → affected
status-firefox74: --- → affected
status-firefox75: --- → affected
Component: Untriaged → DOM: UI Events & Focus Handling
Ever confirmed: true
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → Desktop
Version: 68 Branch → Trunk

Firefox/Keyboard navigation is probably the suitable component. (if the component is not the correct one please feel free to change it)

Component: DOM: UI Events & Focus Handling → Keyboard Navigation
Product: Core → Firefox

(In reply to jmgonk from comment #0)

This has been a problem ever since the addition of Reader View. Is it hardcoded to grab Alt + R?

Reader View uses Accel + Alt + R. Since you made Alt the accel key, you've effectively reduced the shortcut to just Alt + R. Seems like we're behaving correctly here.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID

When the choice was made to use Alt+R for Reader (on Linux), was any consideration given to the fact that would effectively make Control the only choice for accelkey?

(In reply to jmgonk from comment #7)

When the choice was made to use Alt+R for Reader (on Linux)

As I said it's Accel+Alt+R, not Alt+R. Only your configuration made it Alt+R.

was any consideration given to the fact that would effectively make Control the only choice for accelkey?

As far as I know users are not expected to change ui.key.accelKey. If you mess with hidden prefs, things can break.

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