Steps how to reproduce with official en-US SeaMonkey 2.48a1 (NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Build 20160904003221 (Default Classic Theme) on German WIN7 64bit 0. Create backup of your user profile → Dwonload installer.exe from <http://archive.mozilla.org/pub/seamonkey/nightly/> → Unzip → Close running SeaMonkey → Launch new SeaMonkey with double click on seamonkey.exe in "core" folder 2. Launch Browser → Visit one of your login pages for what your have multiple accounts 3. Start Typing user name Expected: list with suggestions matching with typed string appears below input line (sometimes it might be necessary to use <tab> to go to password iinput, click behind user name string, press <Backspace> until list appears Actual: no suggestions a) this was still ok with official en-US SeaMonkey 2.48a1 (NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Build 20160804000913 (Default Classic Theme) on German WIN7 64bit b) Problem persists in safe mode

c) Problem persists in newly created profile with single password stored in password manager d) Problem is not related to passwords, but a general "suggestions for autofill" problem. Steps to reproduce: 11. visit page of what you know that suggestions are stored for input fields, for me this is Bugzilla advanced search 12. Start typing a string of what you know that you already used it for me in "Whiteboard" input line I type "[" Expected: for me should show "[easyconfirm]" and others Actual: no suggestions.

e) same problem with next build 20160905005658

Rainer, please check your error console. This might be a dupicate of bug 1300539.

(In reply to Frank-Rainer Grahl from comment #3) In step 12. Error Console shows nothing.

ok, please check again when bug 1300539 is fixed.

Bug 1300539 is fixed. I can confirm the problem using a local en-US build: User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48a1 Build identifier: 20160909170142

Seems to be caused by bug 1294502. The browser parts need to be ported.

Non working patch. Shows box in the correct size but without content.

empty list box. Correct size and also reacts to user input in the expected way. The two stored items start with an f.

f) "Bug 1305923 - Unwanted autocomplete for particular input lines" probably only shows an other aspect of this one, please feel free to DUP that one if you find indications that my suspect is correct

This one seems to work mostly. The FormAutoComplete:MaybeOpenPopup was never received in AutoCompletePopup.jsm. Keyboard action is ok but clicking into the suggestions popup with the mouse does not select an entry. Any ideas?

Comment on attachment 8796982 [details] [diff] [review] 1300547-autcomplete-mostlyworking.patch Review of attachment 8796982 [details] [diff] [review]: ----------------------------------------------------------------- This looks like a fine start (though I really don't know much about navigator.xul or nsSuiteGlue.js, so take what I say with a grain of salt). Regarding not being able to select items with the mouse, do you know if this block is being entered when you try?: http://searchfox.org/mozilla-central/rev/3411332d29d377bf86405fc3ea72461ea0cb0295/toolkit/components/satchel/AutoCompletePopup.jsm#259 That's what's supposed to be called when you select an item from the popup by mouse. If so, then this is the other half that's supposed to handle that message: http://searchfox.org/mozilla-central/rev/3411332d29d377bf86405fc3ea72461ea0cb0295/toolkit/content/browser-content.js#1409 Are you certain that browser-content.js is being loaded in the <xul:browser> that you're opening the autocomplete popup for?

Comment on attachment 8797698 [details] 1300547-log.txt Mike, sorry hit enter to fast. >> This looks like a fine start (though I really don't know much about navigator.xul or nsSuiteGlue.js, so take what I say with a grain of salt). << More or less SeaMonkeys browser.xul and nsbrowserglue.js. >> Regarding not being able to select items with the mouse, do you know if this block is being entered when you try?: I think there lies the problem. I added some log output statements to autocomplete.jsm. With the keyboard everything works. With the mouse handleEnter is called after popuphidden. This 'if (browser && this.openedPopup) {' is never executed because popuphidden in handleEvent sets openedPopup and weakBrowser to null. See the log file for the event chain. >> Are you certain that browser-content.js is being loaded in the <xul:browser> that you're opening the autocomplete popup for? << Pretty sure but take it with a grain of salt. Somewhat new to programming SeaMonkey and Mozilla stuff. I can add some more output if you need it.

Oh btw. this was a normal form field but password fields behave the same. Using Up and Down plus Enter key after selecting the right value works in them too.

Hrm. That's strange. Perhaps SeaMonkey is using a slightly different autocomplete binding? If you do: dump(new Error().stack + "\n"); Right here: http://searchfox.org/mozilla-central/source/toolkit/components/satchel/AutoCompletePopup.jsm#260 What's the stack when you attempt to choose an item with the mouse?

The Enter in Firefox is handled by autocomplete-treebody in: d:\seamonkey\comm-central\mozilla\toolkit\content\widgets\autocomplete.xml AutoCompletePopup handleEnter Stack: this.AutoCompletePopup.handleEnter@resource://gre/modules/AutoCompletePopup.jsm:279:81 AutoCompleteTreeView.handleEnter@resource://gre/modules/AutoCompletePopup.jsm:65:5 onPopupClick@chrome://browser/content/urlbarBindings.xml:1236:13 onxblmouseup@chrome://global/content/bindings/autocomplete.xml:2317:1 The Enter in Seamonkey is handled by autocomplete-treebody in: \mozilla\xpfe\components\autocomplete\resources\content\autocomplete.xml AutoCompletePopup handleEnter Stack: this.AutoCompletePopup.handleEnter@resource://gre/modules/AutoCompletePopup.jsm:279:81 AutoCompleteTreeView.handleEnter@resource://gre/modules/AutoCompletePopup.jsm:65:5 onxblmouseup@chrome://global/content/autocomplete.xml:1583:11 So it seems we have two autocomplete.xml files. The second one has not been updated in the last year.

This works for me. Just needed to attach the correct css for the old autocomplete.

I first thought the other autocomplete needed some changes too. This works with both SeaMonkey and Firefox but isn't needed. Overall I think if you look where autocomplete css and xml files end up in the dist tree it might need an additional overall refactoring.

NI: NeilAway because he owns the XPFE autocomplete > + <!-- Note: this binding is applied to the autocomplete popup used in web page content. --> > + <binding id="navigator-autocomplete-result-popup" extends="chrome://global/content/bindings/autocomplete.xml#autocomplete-result-popup"> > + <resources> > + <stylesheet src="chrome://communicator/content/autocomplete.css"/> > + </resources> > + </binding> This changes the binding from: panel[type="autocomplete"] { -moz-binding: url("chrome://global/content/autocomplete.xml#autocomplete-result-popup"); } to chrome://global/content/bindings/autocomplete.xml#autocomplete-result-popup" You should instead port whatever is needed from the toolkit #autocomplete-result-popup binding to the equivalent binding in the xpfe autocomplete. (NOTE: xpfe/components/autocomplete/ belongs to SUITE for historical reasons[1] so all we need is a seamonkey reviewer signoff. [1] Originally most of suite was under xpfe/* XPFE was the old "new toolkit" (compared to Netscape 5) whereas the current mozilla/toolkit is the new new (aviary) toolkit.

Comment on attachment 8799259 [details] [diff] [review] 1300547-autcomplete-mc-part.patch The approach looks fine to me, though I don't know much about what goes on under xpfe, so I'm going to clear my feedback flag.

And bug 1296638 completely broke this again for 2.49...

>> You should instead port whatever is needed from the toolkit #autocomplete-result-popup binding to the equivalent binding in the xpfe autocomplete. << This needs another complete overhaul after bug 1296638. I would like to use the existing c-c patch for 2.48 and port it properly for 2.49.

Comment on attachment 8799257 [details] [diff] [review] 1300547-autcomplete-cc-part.patch [Approval Request Comment] Regression caused by (bug #): 1294502 User impact if declined: Autocomplete does work. Suggestions not shown if more than one possible match. Testing completed (on m-c, etc.): c-a Risk to taking this patch (and alternatives if risky): none already broken String changes made by this patch: none I would like to take this patch to c-a only. After Bug 1296638 it needs to be adapted and this would mean unnecessary work for just one releaee (2.48) because it works right now there.

Comment on attachment 8799257 [details] [diff] [review] 1300547-autcomplete-cc-part.patch ouch, but I guess we don't have an alternative

BTW. Just did a new build. I'm getting this error: Sat Nov 05 2016 07:07:48 Error: TypeError: invalid 'in' operand this.popup Source file: chrome://global/content/autocomplete.xml Line: 70

c-a only fix: https://hg.mozilla.org/releases/comm-aurora/rev/4ee4185cf67a246d654b2c7131dc5235fd7089e6 m-c patch is not needed for c-a 2.49 still broken. Stay tuned.

Preliminary cc part for 2.49+

Preliminary m-c part for 2.49+

Bug 1181078 might also need to be ported.

Comment on attachment 8807940 [details] [diff] [review] 1300547-autcomplete-cc-part-V2.patch WFM

Comment on attachment 8807941 [details] [diff] [review] 1300547-autcomplete-mc-part-V2.patch WFM

>> Bug 1181078 might also need to be ported. Location bar and search still happily works with the xpfe autocomplete and unmodified xuls. I would not touch it in this bug whithout need. Switched over the location bar to the new autocomplete for testing a few weeks ago. Not all worked without further tweaking but it became somewhat slow and sluggish as I think the awesomebar also is.

Comment on attachment 8807941 [details] [diff] [review] 1300547-autcomplete-mc-part-V2.patch We decided to go this way and use the mozilla autocomplete for search suggestions. The added lines are all inside MOZ_SUITE code and will not affect Firefox. If this is reviewed after merge day tomorrow please approve for m-a. too. Approval Request Comment [Feature/regressing bug #]: 1296638 [User impact if declined]: search suggestions do not work in SeaMonkey. Autocomplete broken. [Describe test coverage new/current, TreeHerder]: c-c [Risks and why]: none only inside SeaMonkey code tree. Already broken. [String/UUID change made/needed]: none

Comment on attachment 8807941 [details] [diff] [review] 1300547-autcomplete-mc-part-V2.patch Review of attachment 8807941 [details] [diff] [review]: ----------------------------------------------------------------- Assuming this only affects MOZ_SUITE, r=me.

Works fine for me with Server-Installation of unofficial (by FRG) en-US SeaMonkey 2.49a2 (NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build 20161118170316 (Default Classic Theme) on German WIN7 64bit: Bugzilla login here and selection of fields in <https://bugzilla.mozilla.org/query.cgi?query_format=advanced> show all expected suggestions.

Comment on attachment 8807940 [details] [diff] [review] 1300547-autcomplete-cc-part-V2.patch r=me, a=me if needed. > - <panel id="PopupAutoComplete" type="autocomplete" noautofocus="true"/> > + <panel type="autocomplete-richlistbox" id="PopupAutoComplete" noautofocus="true" hidden="true"/> id first then type and other attributes. We should try to keep the line length in this file to <= 80 characters. There seem to be two styles used in this file: (1) wrap on 80 and vertically align on first attribute. (2) one attribute per line if wrapping is needed. This seems to be the newer style. > _onBrowserStartup: function(aWindow) > { > + AutoCompletePopup.init(); > + Any reason you're doing the init in "sessionstore-windows-restored" instead of "final-ui-startup"? File a follow-up bug to see if we need to port stuff like: https://hg.mozilla.org/mozilla-central/annotate/b7f895c1dc2e/browser/themes/windows/browser.css#l1536 Lines 1536 to 1611 (Also check with Stefan about the mac theming)

c-c part with nit adressed: https://hg.mozilla.org/comm-central/rev/64ce0979ad96d1d52927c72befc7b4da263a1dbf https://hg.mozilla.org/releases/comm-aurora/rev/a34ceeec6f8b88f272e0290d81d2823ee5f6267c

Pushed by frgrahl@gmx.net: https://hg.mozilla.org/integration/mozilla-inbound/rev/770ce0c52559 Switch suite to standard autocomplete for search suggestions in fields. r=mconley

m-i https://hg.mozilla.org/integration/mozilla-inbound/rev/770ce0c52559d994559ad45ed5c05853be1700a1

Compared to 2.49a2 (my Comment 36) I see a regression with Server-Installation of unofficial (by FRG) en-US SeaMonkey 2.50a1 (NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 Build 20161121115504 (Default Classic Theme) on German WIN7 64bit: On <https://bugzilla.mozilla.org/index.cgi?logout=1> and logged out, when I click on "Log in" in page header → click into user name input line → type "r" g) 2.49a2 suggests both existing usernames for my 2 accounts starting with "r" h) 2.50 will not show suggestions

Mike, m-c patch has been checked in and looks like it causes no problems. Can you approve the patch for m-a? If you can I push it myself?

I'm afraid I don't have (and have never had) comm-aurora-approved +'ing abilities. Sorry!

Mike c-a part is already pushed. I need approval for the m-a part in https://bug1300547.bmoattachments.org/attachment.cgi?id=8807941 If you can't do it could you recommend someone?

Maybe Magnus Melin? I'm not sure who has comm-approval permissions these days, to be honest.

Mike I need mozilla-aurora approval :)

Dave, could you give me mozilla-aurora approval for the above patch: https://bug1300547.bmoattachments.org/attachment.cgi?id=8807941 It changes a part in xul.css only used by suite. Thanks FRG

Comment on attachment 8807941 [details] [diff] [review] 1300547-autcomplete-mc-part-V2.patch seamonkey fix, doesn't affect firefox, take in aurora52

Julien thanks. https://hg.mozilla.org/releases/mozilla-aurora/rev/a7c5e5d204bdf11a3aa6d44cc0b08fd7a770344f

(In reply to Frank-Rainer Grahl from comment #50) > Julien thanks. > > https://hg.mozilla.org/releases/mozilla-aurora/rev/ > a7c5e5d204bdf11a3aa6d44cc0b08fd7a770344f setting the flag per comment 50