Add-ons sometimes add their own autocomplete component to the autocompletesearch attribute of built-in autocomplete fields, for example the toAddrInput field (and friends) in the message composer.

This worked till TB78.0b2.

Due to bug 1627200 which landet in TB78.0b3, the value entry is no longer displayed, if these custom autocomplete components do not return a style which ends with "-abook". I traced it down to these changes:

https://hg.mozilla.org/releases/comm-beta/rev/a2681c24ae667222a519ff18fb3d8a956ebd5d07#l2.12

After I found the cause, I can work around the issue by using a matching style and add the change to the update guide. But maybe it is worth fixing the original issue without restricting the style value?

If this CSS is to be changed it needs to be done in a way that these rules are not applied by default, because there are other autocomplete popups that the rules should not apply to. Probably the most logical change is to make them only apply to descendants of the popups in question, though there are several of those and I'm not sure where they all are.

John, can you propose a patch?

The original CSS looks actually fine to me. If there is a comment, than display the comment. This is pretty straight forward.

The reason why Geoff changed that (I think), was because the datalist autocomplete search returns a comment and a title, with both being identical and that looked ugly. Or was there anything else?

Is the autocomplete implementation of the datalist/input combination under our own control? I failed to find it so far.

I guess https://searchfox.org/mozilla-central/rev/d54712b9644b49cec6cc90a9e0c325fdfab04e7c/toolkit/content/widgets/autocomplete-popup.js#615?

I traced it down to

https://searchfox.org/mozilla-central/source/toolkit/components/satchel/FormAutoComplete.jsm#514

where datalists return a value and a label, which later turn into comment/url and title. Still looking for the actual implementation where these two are generated. However, FF disables the url everywhere, so they do not have the issue

https://searchfox.org/mozilla-central/source/toolkit/themes/linux/global/autocomplete.css#76

so I do not know if m-c want to make any changes in that area. From my current understanding datalist is the only problematic element. It would be helpful to know from Geoff, if he made this change to the CSS just for datalists or if I have missed something. I am also trying to tweak the CSS to check for originaltype containing datalist but it is so difficult to find all cases and then be sure to have not missed any...

That is the gist of why I changed it, yes. Although the CSS is you want is specific to the address book autocomplete pop-ups, so it should still be limited somehow to those. Perhaps a new class should be added to those.

Hm. Attaching a class to the autocomplete-input CE we use in c-c to make such an autocomplete search box, will not help. The richlistbox is not a direct descendant of the autocomplete-input but lives inside a popupset outside of the input node. We cannot style that richlistbox or anything therein differently based on attributes or classes attached to the input.

I think we need to stick with Geoffs solution. Changes in toolkit itself are probably not justified.

John, IIRC you figured out what to do with this?

As I was not able to fix it as described above, I would close this as wontfix. But it is not pretty and this is probably going to bite us later again. Maybe someone more skilled with toolkit code finds a way to fix it. Firefox is not using this at all.