In Bug 1387624 we originally fixed this issue, but the fix wasn't covered by any automated test and it regressed in the HTML about:addons view (it can be verified using the same extension used to QA verify that bug in Bug 1387624 comment 26: https://addons.mozilla.org/en-US/firefox/addon/notification-sound/).

For other similar feature we opted for:

• embedding a XUL element into an HTML webcomponent (for the inline options' select drop down)
• or using an HTML webcomponent to forward a call to a XUL element available in the browser UI (for the inline options' context menu popup)

And to fix this regression we should do likely something similar for the PopupAutocomplete as well (and possibly cover it with an automated test this time, to reduce the chance to regress it again, e.g. once we will move the HTML about:addons view to the top level).

Currently AutoCompleteParent receives a "FormAutoComplete:MaybeOpenPopup" message when the autocomplete popup should be opened, but it bails out because browser.autoCompletePopup is null.

From a quick look to AutoCompleteParent, it looks that another option may be to special case browser#addon-inline-options and make it use the tab browser's autocomplete popup (instead of creating another one into the HTML about:addons page).

I didn't run a mozregression to bisect the exact patch that has regressed it, but I'm pretty sure it did stopped to work when we moved the inline options into the HTML about:addons subframe (well, and enabled the HTML about:addons views by default), because there isn't a panel with the expected PopupAutocomplete id and so it couldn't work.

Marking P3 since we haven't gotten any bug reports on this, so it probably isn't used much.