User Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0a2) Gecko/20111207 Firefox/10.0a2 Build ID: 20111207042022 Steps to reproduce: Created an add-on that adds an autocomplete textbox with the enablehistoy attribute set to true. Actual results: Autocomplete textbox appears and functions correctly *except* that clicking the dropdown arrow (which the enablehistory attribute adds) has no effect. IOW the dropdown (popup) does not appear. Expected results: The dropdown showing possible selections should open when the arrow is clicked.

Seamonkey exhibits the same bug; Firefox does not. I added a workaround to my actual add-on (not the attached testcase add-on) that adds a click event handler to the dropdown arrow which calls myAutocompleteTextbox.showHistoryPopup(); making the dropdown/popup appear.

Maybe duplication of Bug 704521

Sorry, please ignore comment #2

Confirmed on http://hg.mozilla.org/comm-central/rev/778c81627f48 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111207 Thunderbird/11.0a1 ID:20111207030021 http://hg.mozilla.org/releases/comm-aurora/rev/494757cf43d9 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111207 Thunderbird/10.0a2 ID:20111207030021 http://hg.mozilla.org/releases/comm-beta/rev/da477a14d2ce Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111130 Thunderbird/9.0 ID:20111130015651 http://hg.mozilla.org/releases/comm-release/rev/3a77e857b5c1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 ID:20111105021620

Upon further examination with DOMi, the bug shown in the first attached testcase may not be triggered by the same code as the bug I am encountering in my actual extension development, even though it exhibits the exact same symptom. In the first attachment's testcase, clicking the arrow shows: Error: textbox.showHistoryPopup is not a function Source File: chrome://global/content/bindings/autocomplete.xml Line: 1628 in the error console. Attaching a second testcase which adds an autocomplete textbox to the Add-ons Manager (also simplified, but better illustrates what I encountered in my actual extension development). In the second testcase, the dropmarker/arrow appears (in DOMi) to have an xbl binding with a showPopup method consisting of the code: var textbox = document.getBindingParent(this); var kids = textbox.getElementsByClassName("autocomplete-history-popup"); if (kids.item(0) && textbox.getAttribute("open") != "true") { // Open history popup kids[0].showPopup(textbox, -1, -1, "popup", "bottomleft", "topleft"); textbox.setAttribute("open", "true"); } which appears to be the same code as found at: http://mxr.mozilla.org/comm-central/source/mozilla/xpfe/components/autocomplete/resources/content/autocomplete.xml#1749 (...but I thought that modern versions of Thunderbird were using Toolkit code rather than xpfe.) There are no 'kids' with that classname and though showHistoryPopup does exist on the textbox when using testcase 2, it does not appear to get called (which is apparently what makes my workaround mentioned in Comment #1 work - and means that workaround should be effective if applied to testcase2, but not to testcase 1). I am not certain I am interpreting all of this correctly, but posting it in hopes it will help track down the bug's cause. If anything I've explained is unclear, just ask.

Adding tracking flags -> extension author needs it, testcase present start of analysis in comment #5.

Is this actually a regression? Did it ever work in TB or SM? Both TB and SM still use the xpfe autocomplete (although we do support some of the toolkit interfaces within it).

The first option is to adapt the CSS for toolkit autocomplete textboxes from Firefox's version of XUL.css into your extension (I think Thunderbird does this for gloda somewhere). Note that you would need to be more careful if you were overlaying a window that already used an autocomplete textbox, but it can be done (SeaMonkey does this for its search bar). The second option is to write your autocomplete using the XPFE style of history popup. This involves adding a menupopup with the autocomplete-history-popup class and a popupshowing handler that populates it (unlike the toolkit popup which invokes a search with an empty string to populate its history popup). The third option is to help either with fixing LDAP autocomplete to use toolkit interfaces or switching the message compose window over from XPFE to toolkit autocomplete. Then toolkit will become the default autocomplete, and only a few select widgets in SeaMonkey will still use XPFE autocomplete.

Given the steps that Neil mentioned, the work around for now is to implement the extension to support the xpfe autocomplete. The work for switching to toolkit autocomplete is being done in bug 360648 and bug 452232 so I'm marking this as dependent on bug 360648 (as it isn't a direct duplicate).