Closed Bug 1543379 Opened 5 years ago Closed 2 years ago

Make accesskey work in MozMenuPopup custom elements

Categories

(Toolkit :: UI Widgets, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: pmorris, Unassigned)

References

(Regression)

Details

(Keywords: access, regression)

When using the MozMenuPopup class (introduced recently in bug 1531870) the accesskey functionality for menu items is not working. For example, see bug 1531296. I looked into where and how to fix this, but I was not able to figure it out.

Edit: The accesskey is rendered correctly (there are underlines under the accesskey characters in the menu items), but pressing those keys has no effect.

Flags: needinfo?(surkov.alexander)
Flags: needinfo?(bgrinstead)

I'm not familiar with accesskey handling code, all I know it all lives in c++ (afaik). One suspect I can see in code (bug 1531870) is you change the hierarchy: menuitems are now children of explicit arrowscrollbox (which was used to be an anonymous child of menupoup), and thus menuitems were direct children of a menupopup. My guess would be that accesskey handling code might have a dependency on DOM hierarchy. Cc'ing masayuki and neil for ideas.

Flags: needinfo?(surkov.alexander)

It it only not working when you press the key, or is the accesskey also not rendering in the label within the menuitems?

Flags: needinfo?(bgrinstead)

The accesskey is rendered correctly (there are underlines under the accesskey characters in the menu items), but pressing those keys has no effect.

Component: General → XUL Widgets
Priority: -- → P1
Keywords: access

So if we go with Shadow DOM will the accesskey start working again? This is the approach being taken in Bug 1539651. Before we can use it more generally I think we'll need to get Shadow Parts (bug 1505489), but if that does fix it that's probably our best bet.

(In reply to Paul Morris [:pmorris] from comment #0)

When using the MozMenuPopup class (introduced recently in bug 1531870) the accesskey functionality for menu items is not working. For example, see bug 1531296. I looked into where and how to fix this, but I was not able to figure it out.

Please don't insert bugs as links. That's not necessary since BMO will linkify "bug 1531870". It's even harmful since the link tooltip doesn't show the bug summary where the link from "bug 1531870" does. Oh, and the links don't have strike-though either.

No longer blocks: war-on-xbl
Regressed by: 1555497

So I just poked around at a few menupopups on Windows, and they appear to work with accesskeys. Brian, do you know if this was fixed by something else?

Flags: needinfo?(bgrinstead)
Priority: P1 → P3

(In reply to Mark Striemer [:mstriemer] from comment #6)

So I just poked around at a few menupopups on Windows, and they appear to work with accesskeys. Brian, do you know if this was fixed by something else?

I have no idea, but I'm not seeing specific STR here or in i.e. bug 1531296. I'd be fine to close this as worksforme and then we can reopen if it can still be reproduced somewhere. Magnus, are you aware of this still being an issue in TB?

Flags: needinfo?(bgrinstead) → needinfo?(mkmelin+mozilla)

AFAICT, it's working.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → WORKSFORME
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.