Convert menu bindings to a Custom Element

ASSIGNED
Assigned to

Status

()

P3
normal
ASSIGNED
2 months ago
12 days ago

People

(Reporter: timdream, Assigned: bgrins)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [xbl-available])

Attachments

(1 attachment)

Similar to menuitem (bug 1519495) the bindings bound to <menu> can be converted to multiple custom elements via prepending/appending children upon CE connection.

  • menu-base
  • menu
  • menu-menubar
  • toolbarbutton-dropdown
  • menu-iconic
  • menu-menubar-iconic

Noted that the toolbarbutton.xml#menu binding is unrelated to this group. We have a problem with our XBL Component Tree page that should be corrected.

raw note (with menu missing from the list since it was copied from the page):

menu-base
We could first move the menu selector from xul.css to menu-base binding. Then all other non-menucaption bindings below this could potentially be collapsed into a single CE, or multiple with [is] attribute
menu-menubar
menu-iconic
Three of these: bookmarksToolbarFolderMenu, menu_unsortedBookmarks, menu_mobileBookmarks
toolbarbutton-dropdown
menu-menubar-iconic

Unfortunately, they inherit menuitem-base.

Depends on: 1519495

The menucaption binding is doable without all the <children> maneuver when menu-base and menuitem-base are implemented.

raw note:

menucaption
This is only used for <optgroup>s on select: https://searchfox.org/mozilla-central/rev/b4ebbe90ae4d0468fe6232bb4ce90699738c8125/toolkit/modules/SelectParentHelper.jsm#340
Should actually be doable now, since all parent bindings just use inherits, properties, methods

Summary: Convert "menu-*" bindings to custom elements → Convert menu bindings to custom elements
Priority: -- → P3

Updated

2 months ago
Depends on: 1522290

I made a mistake in bug 1518932 — The MenuBaseControl here is also useful in this bug.

https://hg.mozilla.org/integration/autoland/rev/c1032d34b5e0#l13.26

We will want to move it somewhere that can be shared between menulist.js and menu.js here yet somehow only construct it lazily.

(Assignee)

Comment 4

2 months ago

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #3)

I made a mistake in bug 1518932 — The MenuBaseControl here is also useful in this bug.

https://hg.mozilla.org/integration/autoland/rev/c1032d34b5e0#l13.26

We will want to move it somewhere that can be shared between menulist.js and menu.js here yet somehow only construct it lazily.

Why does it need to be lazy? Is there a perf issue with attaching it as a base class into MozElements object like these: https://searchfox.org/mozilla-central/rev/5c8ea961d04767db723a0a15e3a8f7fbca154129/toolkit/content/customElements.js#288?

Creating a class definition on every document that is only useful for the <menu> and <menulist> usage may not be slow. I was thinking about memory usage, but perhaps that's tiny as well.

Anyway, a lazily Object.defineProperty could do the job, if we really want to.

(Assignee)

Comment 6

2 months ago

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #5)

Creating a class definition on every document that is only useful for the <menu> and <menulist> usage may not be slow. I was thinking about memory usage, but perhaps that's tiny as well.

Anyway, a lazily Object.defineProperty could do the job, if we really want to.

Oh yeah, it wouldn't hurt to use XPCOMUtils.defineLazyGetter. Don't think we'd need to do anything more fancy than that.

Right. We may want to move the namespace of these mixin methods and defined classes also. There will be many!

(Assignee)

Updated

a month ago
Depends on: 1527105
(Assignee)

Updated

a month ago
Depends on: 1527680
(Assignee)

Updated

12 days ago
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
Summary: Convert menu bindings to custom elements → Convert menu bindings to a Custom Element
Attachment #9043454 - Attachment description: Bug 1519502 - Convert menu bindings to custom elements → Bug 1519502 - Convert menu bindings to a Custom Element
You need to log in before you can comment on or make changes to this bug.