1556566 - Remove `moz-input-box`

Status: RESOLVED DUPLICATE of bug 1586591

(Toolkit :: UI Widgets, task)

Description

[Tim Nguyen :ntim]

Once this and bug 1556561 are fixed, the autocomplete binding will essentially be an HTML input with an extra popupset, making it very easy for bug 1534455 to convert <textbox type="autocomplete"/> to a simple customized input element <html:input is="autocomplete"/>.

In order to fix this, it's possible to add textbox[type="autocomplete"] to https://searchfox.org/mozilla-central/source/toolkit/content/editMenuOverlay.js#66-69 . However, the more tricky part is that legacy-urlbar in urlbarBindings.xml and searchbar-textbox, which are both based on autocomplete, both add their own context menu items to their edit menu.

Comment 1

[Tim Nguyen :ntim]

Brian, would it be possible to add some kind of API to editMenuOverlay.js that would allow adding context menu items in there ?

We probably don't need to worry about the old urlbar, but the searchbar will need this for "Paste & Search", "Clear Search History" and "Show Search Suggestions".

Maybe this could be done in a nicer way than an API in editMenuOverlay.js though ? The goal is to be able to get rid of any child markup including moz-input-box from the autocomplete binding, so we can simply have <html:input is="autocomplete-input" />.

Comment 2

[Brian Grinstead [:bgrins]]

(In reply to Tim Nguyen :ntim from comment #1)

Brian, would it be possible to add some kind of API to editMenuOverlay.js that would allow adding context menu items in there ?

We probably don't need to worry about the old urlbar, but the searchbar will need this for "Paste & Search", "Clear Search History" and "Show Search Suggestions".

Maybe this could be done in a nicer way than an API in editMenuOverlay.js though ? The goal is to be able to get rid of any child markup including moz-input-box from the autocomplete binding, so we can simply have <html:input is="autocomplete-input" />.

Yeah, I'd ultimately like moz-input-box to go away. Perhaps we could either:

1. implement a method on the input itself that editMenuOverlay.js would call to receive an alternative menupopup instead of https://searchfox.org/mozilla-central/rev/fe7dbedf223c0fc4b37d5bd72293438dfbca6cec/toolkit/content/editMenuOverlay.js#75 if it's implemented - like e.target.getContextMenu()
2. have the element listen to the contextmenu event itself and create it's own popup & preventDefault(). This will already cause editMenuOverlay to bail out due to https://searchfox.org/mozilla-central/rev/fe7dbedf223c0fc4b37d5bd72293438dfbca6cec/toolkit/content/editMenuOverlay.js#66.

I sort of just lean towards (2) since it seems each consumer will have pretty specific needs (the search input items integrated throughout the rest of the menu, for instance). The amount of duplication is relatively small (https://searchfox.org/mozilla-central/rev/fe7dbedf223c0fc4b37d5bd72293438dfbca6cec/toolkit/content/editMenuOverlay.js#75-94) and would need to be partly duplicated anyway even in (1).

FWIW I'm guessing TB may want some kind of hook here too to enable spellcheck menuitems on inputs (as in https://bugzilla.mozilla.org/show_bug.cgi?id=1556203).

Comment 3

[Tim Nguyen :ntim]

Looks like Andrew might be doing it all in one go for autocomplete in bug 1534455, but it's still desirable to get rid of moz-input-box regardless (from the urlbar notably).