Closed Bug 408274 Opened 17 years ago Closed 16 years ago

Location bar autocomplete does not work after being removed from the toolbar and being added again

Categories

(Firefox :: Address Bar, defect)

x86
Windows Vista
defect
Not set
major

Tracking

()

VERIFIED DUPLICATE of bug 404135

People

(Reporter: ehsan.akhgari, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: See comment 15 before trying to reproduce the bug)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2007121305 Minefield/3.0b3pre

The autocomplete function of the location bar ceases to work once it's removed from the toolbar, and is added again.

Reproducible: Always

Steps to Reproduce:
1. Open the Customize Toolbar dialog, and remove the location bar, and click Done.
2. Open the Customize Toolbar, and add the location bar back again.
3. Now type something in the location bar which *should* trigger the autocomplete.  Nothing happens.  Here is the error message that can be observed in the Error Console:

Error: uncaught exception: [Exception... "Component does not have requested interface arg 0 [nsIAutoCompleteController.input]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: attachController :: line 267"  data: no]

4. Try pressing Enter, Ctrl+Enter, Shift+Enter, and Ctrl+Shift+Enter to autocomplete the URL.  None work either.
Actual Results:  
The autocomplete dies off completely.

Expected Results:  
The autocomplete should work as usual in this test case.

about:buildconfig

Build platform
target
i686-pc-mingw32

Build tools
Compiler 	Version 	Compiler flags
cl 	14.00.50727 	-TC -nologo -W3 -Gy -Fd$(PDBFILE)
cl 	14.00.50727 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fd$(PDBFILE)

Configure arguments
--enable-application=browser --enable-update-channel=nightly --enable-optimize --disable-debug --disable-tests --enable-update-packaging
Flags: in-litmus?
Flags: blocking-firefox3?
Keywords: regression
I bet this is related to the pref for rich URL bar results. Once we've removed and re-added the URL bar it's autocompletepopup attribute will revert to the default value.
I can only reproduce this rarely. Today 0 times. I do see the autocomplete, but not the two line autocomplete. Yesterday I saw a kind of focus issue (I needed to triple click to select after customizing) but even that I can't reproduce anymore.
Hmmm, this is odd, since I can reproduce it each time.  What's your platform?
I'm on Windows XP. So you need to open and close the customize window twice; after removing the URLbar and after re-adding it. No, I can't reproduce this anymore. Are you using a Clear URL extension, an extension that clears the location bar and focuses it?  
(In reply to comment #4)
> I'm on Windows XP. So you need to open and close the customize window twice;
> after removing the URLbar and after re-adding it. No, I can't reproduce this
> anymore. Are you using a Clear URL extension, an extension that clears the
> location bar and focuses it?  

I got curious, and I tried to reproduce it again, and now I can't reproduce it any more!  Instead, I get another weird effect, which entails the old style autocomplete list appearing after step 4, without anything on the error console.  Restarting the browser causes the new style autocomplete list (with items spanning two rows) get used again.

I highly suspect comment 1 is on the right track.  FWIW, I checked the value of the browser.urlbar.richResults pref (I'm not sure if it's the pref gavin was talking about or not) and it was true both before and after preforming the test steps in comment 0.

And to answer your question, no I'm not using that (or any other) extension, besides DOM Inspector, on this profile.
I tested this on a clean profile as well, and I could only reproduce the problem in comment 5.
Then I'm quite curious what made the bug appear when I tested it for the first time. 
Same here.  I did test the bug ~5-6 times before reporting, and I maybe tested another 10 times during reporting in order to reduce the test case to the one I posted in comment 0.  I didn't update my nightly build since I filed this bug, so the code should not have changed...

Is there anyone worth CCing on this bug, who could hopefully provide more insight into this?
(In reply to comment #5)
> I highly suspect comment 1 is on the right track.  FWIW, I checked the value of
> the browser.urlbar.richResults pref (I'm not sure if it's the pref gavin was
> talking about or not) and it was true both before and after preforming the test
> steps in comment 0.

Comment 1 is certainly a bug, but perhaps it's not this bug as originally reported. The code that checks the richResults pref only runs at window startup, so if you remove and re-add the location bar, you lose rich results. Since we're  going to remove the pref in bug 407836, that'll be fixed there, I guess.
gavin, for the issue in comment #5, even before we remove the pref, we could switch the default in browser.xul to be rich version (PopupAutoCompleteRichResult) and make the code in browser.js change to the tree style if the pref is false.

This bug would then become the reverse if browser.urlbar.richResults was false, and you added and removed the location bar, you'd switch back to rich results, which, since browser.urlbar.richResults is true by default, is something that would be fixed once bug #407836 is fixed.

as for the comment #1, where autocomplete stops working altogether, I'm not sure what's going on there yet.
nice, I just hit comment #1 while testing the idea in comment #10:

JavaScript error: , line 0: uncaught exception: [Exception... "Component does no
t have requested interface arg 0 [nsIAutoCompleteController.input]"  nsresult: "
0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: chrome://global/content/bin
dings/autocomplete.xml :: attachController :: line 267"  data: no]
for comment #5, I'll attach a patch

for comment #1, it looks like I can reproduce this if I do a url bar autocomplete first, before I remove the location bar, close the customize toolbar dialog, re open it, and then add it back.
Comment on attachment 293173 [details] [diff] [review]
patch for comment #5, but the real issue is comment #1

Thanks for the patch, Seth.
Attachment #293173 - Flags: review?(gavin.sharp)
(In reply to comment #12)
> for comment #1, it looks like I can reproduce this if I do a url bar
> autocomplete first, before I remove the location bar, close the customize
> toolbar dialog, re open it, and then add it back.

Good catch Seth.  Yes, that's how I did that now that I think of it, but didn't catch the importance of that in reproducing the bug...

So a Step 0 should be added to the test case in comment 0:

Step 0. Type something in the location bar which triggers an autocomplete result, and dismiss the autocomplete list once it's opened.

Marking this important detail in the status whiteboard...
Whiteboard: See comment 15 before trying to reproduce the bug
Comment on attachment 293173 [details] [diff] [review]
patch for comment #5, but the real issue is comment #1

This patch will just reverse the problem (break the "normal" autocomplete if you remove/re-add the location bar). I suppose that's a less common scenario, but I don't really see the point of landing this if we're going to remove the pref entirely.
> This patch will just reverse the problem

agreed, see comment #10

note, this is actually half the fix for removing the pref, right?  (The other half will be remove the default in firefox.js and then the code in browser.js)

fwiw, I still use the pref for testing rich vs. not rich, so it might stick around until fx 3.
the big problem is comment #0 / #12 / #15, where autocomplete stops working all together, which is the common case.
Comment on attachment 293173 [details] [diff] [review]
patch for comment #5, but the real issue is comment #1

(In reply to comment #17)
> > This patch will just reverse the problem
> 
> agreed, see comment #10

Ah, indeed! My fault for not reading all the comments.

> note, this is actually half the fix for removing the pref, right?  (The other
> half will be remove the default in firefox.js and then the code in browser.js)

Good point, I suppose we might as well land it.

> fwiw, I still use the pref for testing rich vs. not rich, so it might stick
> around until fx 3.

I hope that you don't mean "we might ship with it"... I'd rather not have to carry this code around indefinitely.
Attachment #293173 - Flags: review?(gavin.sharp) → review+
> I hope that you don't mean "we might ship with it"... I'd rather not have to
> carry this code around indefinitely.

Yes, I agree, it should be gone by fx 3.  

Hmm, maybe best to remove it now since we could have an extension to allow for fx 2 style results, which would be better than twiddling prefs (for the end users) anyway.

And, I can always hack browser.xul locally to test stuff.

I'll land this fix (and keep and eye on Ts / Txul) and attach a follow up patch in bug #407836.

I don't want to support browser.urlbar.richResults, either.
Comment on attachment 293173 [details] [diff] [review]
patch for comment #5, but the real issue is comment #1

for the "easy half" of this bug, the fix in bug #407836 will do the trick (which includes the patch that gavin reviewed)

the original bug here is not fixed yet.
Attachment #293173 - Attachment is obsolete: true
The problem started around Dec 2005.
note, the fix for bug #407836 has landed, so the easy half of this bug is fixed, but the other half is not
Flags: blocking-firefox3? → blocking-firefox3+
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Verified dup
Status: RESOLVED → VERIFIED
https://litmus.mozilla.org/show_test.cgi?id=5171 covers this over in bug 404135, so in-litmus+
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: