Convert <richlistitem> to Custom Element

NEW
Unassigned

Status

()

defect
P3
normal
6 months ago
23 hours ago

People

(Reporter: bgrins, Unassigned)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

6 months ago
The binding itself looks pretty easy: https://bgrins.github.io/xbl-analysis/tree/#richlistitem.

I assume the tricky part will be covering inherited bindings at the same time. That might have to happen all at once, and there may be some flattening there that could happen as well (like the autocomplete-profile-* bindings).
Reporter

Comment 1

6 months ago
It doesn't look like the base richlistitem does much on connection so I don't anticipate perf problems on that. But some of the inherited bindings set <content>, so if there are hidden instances of those there could be potential regressions.

Updated

6 months ago
Priority: -- → P3
Reporter

Updated

4 months ago
Depends on: 1519486
Reporter

Updated

4 months ago
Depends on: 1519533

Updated

4 months ago
Depends on: 1521306, 1520924

(In reply to Brian Grinstead [:bgrins] from comment #0)

The binding itself looks pretty easy:
https://bgrins.github.io/xbl-analysis/tree/#richlistitem.

I assume the tricky part will be covering inherited bindings at the same
time. That might have to happen all at once, and there may be some
flattening there that could happen as well (like the autocomplete-profile-*
bindings).

All (currently) dependent bindings will go away when new about:addons is landed, the codebase already has MozRichlistitem, so the bug fix is rather trivial:

  • add customElements.define("richlistitem", MozRichlistitem); into richlistbox.js
  • remove richlistitem binding in xul.css

Brian, does anything prevent us from replacing richlistitem binding on CE now (leaving all dependent bindings untouched for sure)?

Reporter

Comment 4

2 months ago

(In reply to alexander :surkov (:asurkov) from comment #3)

(In reply to Brian Grinstead [:bgrins] from comment #0)

The binding itself looks pretty easy:
https://bgrins.github.io/xbl-analysis/tree/#richlistitem.

I assume the tricky part will be covering inherited bindings at the same
time. That might have to happen all at once, and there may be some
flattening there that could happen as well (like the autocomplete-profile-*
bindings).

All (currently) dependent bindings will go away when new about:addons is landed, the codebase already has MozRichlistitem, so the bug fix is rather trivial:

  • add customElements.define("richlistitem", MozRichlistitem); into richlistbox.js
  • remove richlistitem binding in xul.css

Brian, does anything prevent us from replacing richlistitem binding on CE now (leaving all dependent bindings untouched for sure)?

The problem is that then about:addons would have both a CE and XBL attached to richlistitem. I suppose we could skip that document before doing customElements.define() (perhaps based on an attribute on the root node or something so that we don't have to hardcode the URL), but we still couldn't remove the XBL implementation. Might be a good idea anyway to get that flipped and catch any issues early so when about:addons goes away we can delete it.

tweak the summary, leaving bug 1505924 for inherited bindings

Summary: Convert <richlistitem> (and inherited bindings) to Custom Elements → Convert <richlistitem> to Custom Elements
Summary: Convert <richlistitem> to Custom Elements → Convert <richlistitem> to Custom Element
You need to log in before you can comment on or make changes to this bug.