Callek noticed this... With linux trunk build 2005032705, if I 0. have more than one tab open 1. type a partial URL 2. select one of the auto-complete URLs 3. hit enter 4. switch to a different tab 5. switch back Actual results: only the part of the URL I typed in step 1 is display. Once the page starts actually loading, the full URL is displayed again Expected results: The full URL should be displayed as it was between steps 3 and 4. This regressed between linux trunk 2005021505 and 2005021613. Could bug 272002 have caused this?

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050326 5a. switching back quickly loads partial URL, with .com appended. 5b. switching back a bit slower shows the partial URL, replaced by the full when loading has finished. saw behaviour as described, typeing 'the' I selected theinquirer.net, hit return, switched to another tab, and back, saw 'the' in the URL bar until the page was loaded. Sometimes however, if I switched back very quick, the.com was loaded. Also tested with hei, showing lots of entires for heise.de, could also load hei.com.

Well slight correction, I noticed it with windows XP, asked you to verify for me with your build (which is linux), so OS-All seems appropriate. Thank you for filing.

bryner, can you have a look at this please?

*** Bug 295224 has been marked as a duplicate of this bug. ***

Per Deer Park meeting mconnor and asa will investigate. Maybe doesn't occur in Firefox.

(In reply to comment #5) > Per Deer Park meeting mconnor and asa will investigate. Maybe doesn't occur in > Firefox. It happens in Firefox alright.. Look at bug 295224 (which is a dupe of this) that I've filed.

->bryner. Brian, if you can't help us here, can you suggest a better owner?

*** Bug 299532 has been marked as a duplicate of this bug. ***

*** Bug 303870 has been marked as a duplicate of this bug. ***

This appears to be fixed, actually as of 06/14, I think this is why I thought it was already fixed in Firefox. Duping since this morphed to a firefox bug, please file a seamonkey bug if this still exists there. *** This bug has been marked as a duplicate of 227826 ***

this doesn't seem to be in Firefox product to me reopening

I can still trigger the problem using a 1.8branch build. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050819 Firefox/1.0+ Try using the instructions from the other bug report. Steps to reproduce: 1. Load the provided url in a tab (http://agadak.net/10sec.php) 2. Open a new tab and type "aga" to trigger autocomplete 3. Select the entry for the same page 4. Switch to a different tab then back to the tab used for step 3 (before it finishes loading) Actual: "aga" is shown in the location bar Expected: Selected entry should be in the location bar It works fine in Firefox 1.0.6, and the trunk builds work until 20050215. Versions from 20050216 up to the latest (20050807) are not working correctly. Tested on mac and windows.

backing out bug 272002 fixed this bug xif

This patch makes us treat user-initiated autocomplete the same as the user typing in the field, that is, dispatch an oninput event. To make this work I had to fix the event code to correctly handle a script-created input event.

Comment on attachment 193411 [details] [diff] [review] patch r=me on the toolkit/xpfe bits, the layout/content bits look ok, but jst can r+sr those as appropriate.

Comment on attachment 193411 [details] [diff] [review] patch sr=jst

Comment on attachment 193411 [details] [diff] [review] patch requesting approval... note that this bug should probably still be marked as blocking1.8b4+, since it was only minused when it was incorrectly marked as a dup.

checked in on trunk and branch

This checkin caused the regression in bug 305591.

I'm seeing some pretty whacky thunderbird autocomplete regressions in this morning's branch builds that was not there in yesterdays's build. This patch looks suspicious :). For starters, the auto complete popup won't stay open so you can't select an autocomplete match at all. Second, I keep ending up with resutls like Scott >> Scott MacGregor <mscott@mozilla.org> after hitting enter to accept an autocomplete result. I'll get a bug started.

I filed Bug #305654 to track broken auto complete in mail caused by this bug.

I've verified that removing the firing of the oninput event inside setTextValue makes autocomplete work again. i.e. removing: var evt = document.createEvent("UIEvents"); evt.initUIEvent("input", true, false, window, 0); var oldIgnoreInput = this.mIgnoreInputEvent; this.mIgnoreInputEvent = true; this.dispatchEvent(evt); this.mIgnoreInputEvent = oldIgnoreInput; if browser autocomplete needs this, maybe it should set an attribute on the autocomplete widget for simulating oninput events which it can explicitly ask for. setTextValue could then check the value of that field before executing this new code.

Shouldn't be necessary; this is supposed to just restore the pre-272002 behavior. I'll take a look to see why it's not working as it should. (In reply to comment #22) > if browser autocomplete needs this, maybe it should set an attribute on the > autocomplete widget for simulating oninput events which it can explicitly ask > for. setTextValue could then check the value of that field before executing this > new code. > >