alt-I install extension accelerator key does not work in extension manager / add-ons

VERIFIED FIXED in mozilla1.9beta2

Status

()

VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: wsmwk, Assigned: philor)

Tracking

({access})

Trunk
mozilla1.9beta2
access
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
steps
1. add-ons
2. alt-I

expected: open "select an extension to install"
actual: no response

alt-F, find updates, works
(Assignee)

Comment 1

11 years ago
More than usual, I want a Toolkit: EM component; putting a bug that only affects non-Firefox toolkit consumers in the Firefox product grates.

It doesn't work because "I" is the accesskey for both the non-browser "Install..." button and the (hidden) "Install Updates" button, so your alt+I is trying to trigger a hidden and disabled button.
Status: UNCONFIRMED → NEW
Component: General → Extension/Theme Manager
Ever confirmed: true
Product: Thunderbird → Firefox
QA Contact: general → extension.manager
(Assignee)

Updated

11 years ago
Severity: trivial → normal
(In reply to comment #1)
> More than usual, I want a Toolkit: EM component; putting a bug that only
> affects non-Firefox toolkit consumers in the Firefox product grates.

You get this when bug 271978 will be fixed.

> It doesn't work because "I" is the accesskey for both the non-browser
> "Install..." button and the (hidden) "Install Updates" button, so your alt+I is
> trying to trigger a hidden and disabled button.
 
It is even used three times in this dialog. You forgot the "Install Update" button:

24 <!ENTITY cmd.installLocalFile.label       "Install...">
28 <!ENTITY cmd.installUpdatesAll.label      "Install Updates">
70 <!ENTITY cmd.installUpdate.label          "Install Update">

When this will be fixed we should also rename the first entity to cmd.installFile.label to get in sync.
I cannot find anything about the handling of accesskeys for hidden elements. Shouldn't the accesskey be ignored for them until they are visible? Aaron, you know something about?
Keywords: access

Comment 4

11 years ago
It's best to ignore it -- hidden elements cannot receive focus.
This is handled in bug 136041. Adding dependency.
Depends on: 136041
(Assignee)

Updated

11 years ago
Duplicate of this bug: 404667
(Assignee)

Updated

11 years ago
OS: Windows Vista → All
Hardware: PC → All
Summary: alt-I install extension accellerator key does not work in extension manager / add-ons → alt-I install extension accelerator key does not work in extension manager / add-ons
(Assignee)

Comment 7

11 years ago
Created attachment 289630 [details] [diff] [review]
Fix v.1 - with name change

Axel: I'll get toolkit peer review, but I wanted to start with you for the "should this entity's name change?" question: looking at 1.8 l10n, a few locales spotted the trap and are already using different letters, but most are either using "I" in both places, or some other letter in both places.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Attachment #289630 - Flags: review?(l10n)
(Assignee)

Comment 8

11 years ago
(In reply to comment #2)
> It is even used three times in this dialog. You forgot the "Install Update"
> button:

I didn't forget it, I just don't see that context menuitem interfering. Do you have STR for it getting in the way?

Comment 9

11 years ago
Comment on attachment 289630 [details] [diff] [review]
Fix v.1 - with name change

There are two answers to the question:

- an accesskey change does not require a key name change.
- accesskeys and labels of one UI element should have the same basename.

So, instead of saying that we're exposing the change to localizers, I'd rather say that we're taking the opportunity to fix one translate-toolkit-bustage as we go :-)

r=me for a patch with a key name change.
Attachment #289630 - Flags: review?(l10n) → review+
(Assignee)

Updated

11 years ago
Attachment #289630 - Flags: approval1.9?

Updated

11 years ago
Attachment #289630 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 10

11 years ago
toolkit/mozapps/extensions/content/extensions.xul 1.66
toolkit/locales/en-US/chrome/mozapps/extensions/extensions.dtd 1.27
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 M10
(Assignee)

Updated

11 years ago
Duplicate of this bug: 421377
I filed bug 421377 for Thunderbird.

I checked it in Firefox, to see if it was a more general problem, but my FF2 doesn't show an Install button.

Having this fixed in toolkit will make it available for Thunderbird as well?
(In reply to comment #12)
> Having this fixed in toolkit will make it available for Thunderbird as well?

Yes
Verified with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008030804 Thunderbird/3.0a1pre ID:2008030804. For Firefox 3 this button doesn't exist anymore.
Status: RESOLVED → VERIFIED
(In reply to comment #14)
> Verified with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre)
> Gecko/2008030804 Thunderbird/3.0a1pre ID:2008030804. For Firefox 3 this button
> doesn't exist anymore.

It is supposed to still exist. I presume you are forgetting that it is hidden on Firefox and not Thunderbird?
Indeed. I saw it a minute ago after I installed an extension. The button is still there but normally hidden (see attachment 308115 [details]). Thanks Dave.
Product: Firefox → Toolkit
(Assignee)

Updated

10 years ago
Duplicate of this bug: 361879
You need to log in before you can comment on or make changes to this bug.