Closed Bug 1709439 Opened 3 years ago Closed 3 years ago

XULPopupElement.activateItem native and non-native codepaths are inconsistent with how they allow descendants.

Categories

(Core :: XUL, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox90 --- fixed

People

(Reporter: enndeakin, Assigned: enndeakin)

Details

Attachments

(1 file)

The native OSX implementation of activateItem seems to allow any descendant to be supplied as the item:

parentMenu.activateItem(anyDescendantItem)

The non-native implementation however only allows direct children of 'parentMenu' to be supplied and throws an error otherwise.

mstange, I can fix this inconsistency, but which behaviour is intended here?

Flags: needinfo?(mstange.moz)

I don't have a strong opinion on which behavior is preferable. The discrepancy is probably because I was unsure myself. Which behavior would you prefer?

Flags: needinfo?(mstange.moz) → needinfo?(enndeakin)

This patch also fixes an issue where hidden native items could be activated, and makes the
error message consistent between both implementations in this case.

Assignee: nobody → enndeakin
Status: NEW → ASSIGNED

It looks like this is easier to allow all descendants for the native case, so I just implemented it that way.

Flags: needinfo?(enndeakin)
Pushed by neil@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/98b251a30b42
activateItem should allow any descendant of an open submenu to be used, r=mstange,emilio
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: