Okay, the change mentioned in comment 5 was added since the
<toolbarbutton> custom element now injects DOM content directly (as opposed to the anonymous content previously used by the XBL binding). Of course, to mimic XBL's behavior, it only does this if the
<toolbarbutton> doesn't have its own inner content (https://searchfox.org/mozilla-central/rev/38c88cbf4be87dfa0636d15a5d3599a8ea0d1a72/toolkit/content/widgets/toolbarbutton.js#121-125)
This affects the appmenu since it has descriptionheighworkaround=true and it has a bunch of toolbarbuttons that got new
<label> children that
descriptionHeighWorkaround() now wants to call
getBoundingClientRect() on. This fails browser_appmenu.js due to a bunch of unexpected synchronous reflows.
Back to this bug, the issue is the toolbarbuttons here (they've apparently moved recently so they're in a different place in 69 but the issue remains the same):
I'm not really sure why those elements are using
<toolbarbutton> in the first place? But I suspect rewriting them would be too big/risky to uplift to 69 at this point.
Anyway, it looks like if we set
wrap="true" on the toolbarbuttons, then descriptionHeightWorkaround would run on the buttons themselves (but not on the inner
<label>s. Would that solve this problem? (its a little hard to tell, but the wrap attribute is mostly used to affect the visibility of the content created by the element/binding. These buttons don't use that content so I don't think it would break anything else).
If that isn't doable, then I guess we really just want descriptionHeightWorkaround to be able to tell these toolbarbuttons apart from "regular" ones. Since these buttons don't use the
toolbarbutton-* classes, we could explicitly check for those but that feels awfully hacky. Another option would be to add another attribute to these buttons (or to the actual labels) to tell descriptionHeightWorkaround "no, really look at these even if they are inside a <toolbarbutton>".
Leaving the ni to myself while I try the wrap idea from above.