IE5.5 has the exact same URL autocomplete and URL dropdown history list in the 'Open Web Location' (File->Open in IE5.5) dialog as in the main location bar. This is a nice feature [and logical to], and hopefully easy to implement as the autocomplete and history list is implenmented in the main location bar already.

The URL history list part of this is already covered by bug 38409; updating summary to reflect this. changing component, reassigning to radha (who handles autocomplete), confirming, changing sev to enhancement, making OS and platform ALL, and adding dependency. whew.

changing QA to sairuh, who's the contact for 38409 and has expressed interest in the feature, unless you have some special interest in this jelwell

Not my priority right now. I have a bunch of Session History to fix for Beta 2. Assigning to don and let him give it to the right person when the time comes.

This was approved for beta feature addition...Adding nsbeta2+..don, who will do this work?

Jan - bug 38409 discusses having a history list for this same textfield. Seems to me that this would be a prerequisite for this nsbeta2+ bug to be implemented, if the autocomplete you're referring to is IE-style (i.e. with the dropdown list). We'd need a history list for this before we could autocomplete, so seems to me like 38409 needs to be beta2 also.

Clearing "nsbeta2+" and moving taget milestone to Future. This is not an approved feature. This is just an RFE like bug #38409.

[nsbeta2-]

nav triage team: this is an nsbeta3-

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.

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

adding UE2 keyword from dupe bug.

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

reassinging as Blake was holding the dupe and nothing will happen if assigned to pointy-headed don.

Well, actually, what you duped against this (that I was holding) wasn't really a dup. But I don't mind holding onto this (although I don't really plan on fixing it any time soon, 38409 needs to be done first and will be harder).

my bad, I forgot autocomplete and the history drop down are two different things...

removing nsbeta2 coz it be old history...

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

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

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

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

I know people who consider the fact that this dialog doesn't autocomplete and the URL bar does an advantage. As URL completion works in the URL bar do we really need it in this dialog? Offering identical functionality to the URL bar makes this dialog pointless.

its not pointless as the reason i use it is because i tend to use keyboard shortcuts as much as possible. Strangely enough, the build i am using right now (2001040604) when i hit ctrl-l it doesnt pop up that window, but highlights the url text entry instead... which as it turns out i prefer...

That's why I waited until recently to make this comment. CTRL-L is now for the focus of the URLbar so the keyboard access people are now happy. Ctrl-shift-L is now for the dialog and people who choose the dialog won't want the same behaviour as the URL bar or they'd just press ctrl-l.

what happens if the toolbars are hidden and you press ctrl-l?

David, either you need the dialog or you don't. It is nearing uselessness but still has some functions one cannot get elsewhere. So fine, we need the dialog. If that is the case then the dialog can and should have the same creature comforts one is used to when entering url's. Unless you are contending that the _only_ reason people use the open dialog is to get away from autocomplete your argument is illogical captain. IF that is the case then not adding this feature still isn't the right answer either.

I concur. Consistancy is of utmost importance. If the user wants no auto-completion, they can/should disable it.

blake, how's that fix in hand? would it make it in for moz0.9, or moz0.9.1? [unless, o'course, it has bit-rotted...]

alec, sr?

easy enough! sr=alecf

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

I've tested this patch as well and it works fine. Will this be checked in soon? Can I help? r=cmanske

Don't check that patch in, the patch in bug 43189 fixes this using the new autocomplete widget.

Joe, please check in the other patch also.

Removing mozilla0.9 keyword

Themes Triage Team Marking nsbeta1+

fixed

unable to really test --all i get is a blank dropdown list, like bug 78726, which was in turn dup'd in favor of bug 78771. but i can check if i've a build from 1st or 2nd May that'd have this fix...

found comm bits from 2001.05.02.0x, and autocomplete works in the open web location dialog. removing dependency and vrfy fixed.

trivial correction --the winnt 5/2 i used was mozilla, not commericial.