User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007121009 Minefield/3.0b2pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007121009 Minefield/3.0b2pre If you edit text in the location bar at any position except at the end you do not get any search results. Reproducible: Always Steps to Reproduce: 0. Visit a bugzilla bug 1. Type ubg in location bar ('ubg') 2. left cursor and delete b ('ug') 3. left cursor and insert b ('bug') 4. add space to end ('bug ') or delete 'g' ('bu') Actual Results: No drop-down results shown until step 4 Expected Results: results for step 2 and 3

Confirming with build Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007121022 Minefield/3.0b2pre. Thanks for the excellent bug report, John! Do you have any idea when this broke?

https://litmus.mozilla.org/show_test.cgi?id=5033 in-litmus+

I'm pretty sure this is by design, Fx2 shows the same behaviour. I don't remember exactly why this is, but there was some issues if we tried to show results like this.

This isn't a blocker, in any case, behaviour matches Fx2.

Agreed, not a blocker. If this is by design, but we can't remember the reasoning behind the design, it can't have been very compelling reasoning. I see users with poor typing skills doing this constantly. Why should they be denied the awesomebar?

Bugspam: changing the summary to increase searchability.

The search only occurs when the cursor is at end of the textbox. http://mxr.mozilla.org/firefox/source/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp#260 This is directed by the aIgnoreSelection argument from HandleText. http://mxr.mozilla.org/firefox/source/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp#186 And aIgnoreSelection is only true when a mouse click occurs. http://mxr.mozilla.org/firefox/source/toolkit/components/satchel/src/nsFormFillController.cpp The question is still : why would we want this ? We could try in the beta 5 to assume that aIgnoreSelection is always true to check if there is any regression.

This does what it says. This allows to check regressions, but if aIgnoreSelection was to be found to not be necessary anymore, its references would have to be also removed.

(In reply to comment #12) If you are really doing autocomplete then surely those conditions have to satisfied as a) the text has to be added at the end of what has already been typed b) the new text needs to be selected - and hence edited with the next keystroke. For example, I can't see that this patch would work with browser.urlbar.autoFill set to true

(In reply to comment #13) I'm not sure to understand why you mean, but yes this patch works with browser.urlbar.autoFill set to true. If you enter ('://') then go the left and enter ('http'), autofill will make its job.

I have no idea what badness this might cause! ;) gavin? :) (For others following along, this would also make autocomplete show results for non-locationbar stuff like input boxes too... but I suppose I've run into situations that I wanted normal input boxes to show me stuff when correcting...)

Comment on attachment 317394 [details] [diff] [review] v2 gavin: Brett Wilson r+'d a patch similar to this in bug 324997 but it was held off for Firefox 2 it seems..

gavin: I traced the handleText back to autocomplete.xml 1.1 and autocompletecontroller.cpp 1.1.. and on the way when aIgnoreInput was added, the default behavior was to only show results when the cursor was at the end. The autocomplete widget seems like it was added for satchel ?? but there weren't any comments about why it should only activate when the cursor is at the end. I suppose bryner and hewitt aren't around to ask?

Oh nevermind me. "satchel" was the name for the autocomplete controller that replaced "wallet".

Brian: Do you remember why formfill was made to only show results when the cursor is at the end of the selection?

Could people try this out to see if anything strange happens with autocompletes (like searchbox as well, but seems like not HTML inputs).. or does it always do what you want? E.g., type "direct" for location bar or search bar then delete "e" then delete "r" and it should be searching for "dict" automatically Builds will start showing up here: https://build.mozilla.org/tryserver-builds/2008-04-23_17:20-edward.lee@engineering.uiuc.edu-edit.middle/ Bug 430486 - Clear List button doesn't disable when it should Bug 407888 - Correcting an entry in location bar doesn't update results / awesomebar search not triggered when editing the middle of text Bug 429531 - Location bar should show non-word-boundary matches below word-boundary matches Bug 392143 - show keywords as url bar autocomplete choices Bug 249468 - Add all bookmark keywords to location bar autocomplete drop-down list Bug 422698 - different levels of URL decoding for address bar and autocomplete suggestions Bug 424717 - Location bar autocomplete should be willing to complete to a URL with a different protocol Bug 424509 - Location bar autocomplete favors "http://" over domain name starting with "h" Bug 395161 - Make it possible to restrict the url bar autocomplete results to bookmarks/history entries and match only url/title/tags Bug 424557 - Allow AwesomeBar to default search only urls (or history/titles/bookmarks/tags) Bug 420437 - Search and emphasize quoted strings with spaces Bug 423718 - Use native platform colors for URLs in the location bar autocomplete, make the line between rows lighter Bug 414326 - Use DownloadUtils for software update downloads

(In reply to comment #21) > Could people try this out to see if anything strange happens with autocompletes > (like searchbox as well, but seems like not HTML inputs).. or does it always do > what you want? so far.. update of auto-complete list seems to work fine for both location bar and search box. However, editing in middle of search terms in location bar makes the list flicker, something similar to what was described in bug 416962. It doesn't happen in the search box though. on Mac OS X 10.5.2 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008042317 Minefield/3.0pre ID:2008042317

This patch only changes things for xbl:autocomplete type things and not HtmlInputElement (that would require changing satchel/nsFormFillController). Additionally prevent some unexpected behavior if you have autoFill turned on. E.g., you have "http://mozila.com" in your history/bookmark and are currently searching for "mozia". You're trying to fix it to "mozilla", but autoFill would have defaulted to "mozila|.com|" where .com is selected and then result in "mozilal" when you type the second l of "mozilla".

Both Safari and SeaMonkey will update their autocomplete when you fix typos. Same thing for Spotlight in OS X. This doesn't affect bug 357220 because that problem shows up for HtmlInputElement autocomplete showing up when you click the textbox to make it pop up.

If you want to be able to edit from the middle of the location bar for Firefox 3, you can use this add-on: https://addons.mozilla.org/en-US/firefox/addon/7400

I think it shoudn't block 3.1 but shouldn't be marked as wanted 3.1 ?

Peers add-on is looking for edit-middle functionality like what the Edit Middle add-on provides for the location bar. The patch in this bug should provide edit middle functionality for both the location bar and search bar (and any xul autocomplete textbox). Perhaps a separate bug should be filed for html input boxes?

(In reply to comment #32) > Perhaps a separate bug should be filed for html input boxes? > That's bug 357220.

http://hg.mozilla.org/mozilla-central/index.cgi/rev/51d7287b210c target milestone 3.1a2? 3.1b1?

Edit Middle should now be uninstalled on trunk? Or can they co-exist?

Edit Middle is no longer needed for 3.1. I haven't looked into it, but some reason it stopped working for the last few days anyway on trunk..

Verified auto-completion in the middle of an URL with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/2008072702 Minefield/3.1a2pre ID:2008072702 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/2008072703 Minefield/3.1a2pre ID:2008072703

(In reply to comment #2) > https://litmus.mozilla.org/show_test.cgi?id=5033 > > in-litmus+ This test was disabled in bug 415217 comment #3. Presumably it should be re-enabled at some stage.

(In reply to comment #38) > (In reply to comment #2) > > https://litmus.mozilla.org/show_test.cgi?id=5033 > > > > in-litmus+ > > This test was disabled in bug 415217 comment #3. Presumably it should be > re-enabled at some stage. Done; re-enabled.