Correcting an entry in location bar doesn't update results / awesomebar search not triggered when editing the middle of text

VERIFIED FIXED in Firefox 3.1a2

Status

()

Firefox
Address Bar
P1
major
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: John P Baker, Assigned: Mardak)

Tracking

(Blocks: 1 bug)

Trunk
Firefox 3.1a2
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 -
wanted-firefox3.5 +
in-testsuite ?
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-Safari][parity-SeaMonkey], URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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?
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: in-litmus?
OS: Windows 2000 → All
Hardware: PC → All
Version: unspecified → Trunk
https://litmus.mozilla.org/show_test.cgi?id=5033

in-litmus+
Flags: in-litmus? → in-litmus+
Flags: blocking-firefox3?
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.
Flags: blocking-firefox3?
Flags: blocking-firefox3-
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?

Updated

10 years ago
Duplicate of this bug: 415217
Duplicate of this bug: 415940
Bugspam: changing the summary to increase searchability.
Summary: Correcting an entry in location bar doesn't update results → Correcting an entry in location bar doesn't update results / awesomebar search not triggered when editing the middle of text

Updated

10 years ago
Duplicate of this bug: 419820

Updated

10 years ago
Duplicate of this bug: 421179

Comment 11

10 years ago
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.

Updated

10 years ago
Blocks: 357220

Comment 12

10 years ago
Created attachment 311885 [details] [diff] [review]
Assume that aIgnoreSelection is always true (temporary patch)

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.
Attachment #311885 - Flags: review?

Updated

10 years ago
Attachment #311885 - Flags: review? → review?(gavin.sharp)
(Reporter)

Comment 13

10 years ago
(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 

Comment 14

10 years ago
(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.
(Assignee)

Comment 15

10 years ago
Created attachment 317394 [details] [diff] [review]
v2

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...)
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #317394 - Flags: review?(gavin.sharp)
(Assignee)

Updated

10 years ago
Duplicate of this bug: 416960
(Assignee)

Comment 17

10 years ago
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..
(Assignee)

Comment 18

10 years ago
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?
(Assignee)

Comment 19

10 years ago
Oh nevermind me. "satchel" was the name for the autocomplete controller that replaced "wallet".
(Assignee)

Comment 20

10 years ago
Brian: Do you remember why formfill was made to only show results when the cursor is at the end of the selection?
(Assignee)

Comment 21

10 years ago
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

Comment 22

10 years ago
(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
(Assignee)

Comment 23

10 years ago
Created attachment 317747 [details] [diff] [review]
v2.1

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".
Attachment #317394 - Attachment is obsolete: true
Attachment #317747 - Flags: review?(gavin.sharp)
Attachment #317394 - Flags: review?(gavin.sharp)
(Assignee)

Comment 24

10 years ago
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.
Whiteboard: [has patch][need review gavin][parity-Safari][parity-SeaMonkey]

Updated

10 years ago
Duplicate of this bug: 431368
(Assignee)

Comment 26

10 years ago
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

Updated

10 years ago
Duplicate of this bug: 410933

Updated

10 years ago
Duplicate of this bug: 437603

Updated

10 years ago
Duplicate of this bug: 437830
I think it shoudn't block 3.1 but shouldn't be marked as wanted 3.1 ?
Priority: -- → P1
Target Milestone: --- → Firefox 3.1

Updated

10 years ago
Flags: wanted-firefox3.1?

Updated

10 years ago
Flags: wanted-firefox3.1? → wanted-firefox3.1+

Updated

10 years ago
Duplicate of this bug: 444402
(Assignee)

Comment 32

10 years ago
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?

Comment 33

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

Attachment #317747 - Flags: review?(gavin.sharp) → review+
Whiteboard: [has patch][need review gavin][parity-Safari][parity-SeaMonkey] → [has patch][parity-Safari][parity-SeaMonkey]

Updated

10 years ago
Attachment #311885 - Flags: review?(gavin.sharp)
(Assignee)

Comment 34

9 years ago
http://hg.mozilla.org/mozilla-central/index.cgi/rev/51d7287b210c

target milestone 3.1a2? 3.1b1?
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][parity-Safari][parity-SeaMonkey] → [parity-Safari][parity-SeaMonkey]
(Assignee)

Updated

9 years ago
Target Milestone: Firefox 3.1 → Firefox 3.1a2

Comment 35

9 years ago
Edit Middle should now be uninstalled on trunk? Or can they co-exist?
(Assignee)

Comment 36

9 years ago
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
Status: RESOLVED → VERIFIED
(Reporter)

Comment 38

9 years ago
(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.

Flags: in-testsuite?
(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.

Blocks: 455561

Updated

9 years ago
Duplicate of this bug: 468812
You need to log in before you can comment on or make changes to this bug.