This will solve bug 1717199 for the address book. It also has some other advantages such as being easier to use the devtools on, and drawbacks like not having a webProgress property or a message manager on the browser.

Overall I think it's worth it.

I know you're here to just fix a bug... but it's not the right direction. Having some system/about: pages being content and some chrome creates a mess.

And since the new ab UI is almost completely html and custom elements, it would be wrong to keep dragging xul <menu> along. Why, in this specific case, can't you use html <select> and get rid of xul dependency completely? It can be styled to look just like the button. If you want it too look like xul with icons for checkboxes or radio (single selection), it can also look like this:

<button id="menubutton"
        onclick="m=document.getElementById('menulist'); m.hidden = !m.hidden;"
        onblur="m=document.getElementById('menulist'); m.hidden = true;">Select</button>
<ul id="menulist" hidden="true"
    style="list-style: none;position: absolute; background-color: white;margin: 1px;padding: 4px;border: 1px solid;">
  <li>
    <input id="a" value="A" name="radiogroup" type="radio">
    <label for="a">A</label>
  </li>
  <li>
    <input id="b" value="B" name="radiogroup" type="radio">
    <label for="b">B</label>
  </li>
  <hr>
  <li>
    <input id="c" type="checkbox">
    <label for="c">C</label>
  </li>
  <li>
    <input id="d" type="checkbox">
    <label for="d">D</label>
  </li>
</ul>

Edit: example that actually works.

It's unclear if the widget is done but, for the record, losing the tabular pickable column sortable view of an ab's fields is a giant usability regression.

Even if that one widget could be replaced with an HTML select, we also need context menus, and they need to look right.

And no, we're not done. Far from it.

Reuses the contentTab type without doing the things that cause errors. Also fixes the mailing list dialog to not dump variables into the top frame.

(In reply to Geoff Lankow (:darktrojan) from comment #2)

Even if that one widget could be replaced with an HTML select, we also need context menus, and they need to look right.

Not sure what "even if" means; there isn't much question that it can be done via <select> for simple cases or a custom element implementing something like the example above. And contextmenus are a separate thing that doesn't even exist in aboutAddressBook.xhtml yet. Why html <dialog> isn't used is really puzzling too.

Sorry but I don't see any difficulty in the complete de-xul of aboutAddressBook.xhtml that would favor implementing this pretty gross hack instead..

Going with bug 1727872 instead. It's not ideal, but neither is this option.