Closed Bug 66049 Opened 24 years ago Closed 18 years ago

erroneous urls still try to autocomplete

Categories

(SeaMonkey :: Location Bar, defect)

Product:
SeaMonkey
Component:
Location Bar
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 126320

People

(Reporter: tono, Unassigned)

References

(
URL
)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20010115 BuildID: 2001011520 If you misstype a url say like the above url, and hit enter before checking, the misstyped url will appear in your urlbar history and will therefore be trying to autocomplete to the wrong url. Reproducible: Always Steps to Reproduce: type bad url into urlbar hit "go" or enter Actual Results: url shows up in urlbar history and depending on the alphabetical nature of the typo may try to autocomplete to that url Expected Results: for sanity's sake, it shouldn't do that A theoretical fix could be to not add addresses that fail on host name lookup because it's really annoying to autocomplete to the wrong url and hit enter and get yet another DNS error.
Dup of bug 46584, "[RFE]Mistyped url's shouldn't be added to url dropdown history widget."
Oops. *** This bug has been marked as a duplicate of 46584 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
No DUP. Autocomplete != history (at least theoretically, dunno about the code). I agree that this bug should be fixed (unlike bug 46584). REOPENing. From the description, it sound like there are actually two bugs here: - Autocomplete shouldn't sort lexically, but after last-used or most-used. - I agree that we shouldn't autocomplete to invalid URLs (but we *should* keep invalid URLs in the history, see the other bug for explanation).
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
i actually think this is a dupe, it's the same issue - wrong url typed, and comes in autocomplete...
The other bug is about the *history*, the list that is displayed when you click the down arrow.
Status: UNCONFIRMED → NEW
Ever confirmed: true
over to radha
Assignee: asa → radha
Component: Browser-General → XP Apps
-> ducarroz
Assignee: radha → ducarroz
QA Contact: doronr → claudius
Component: XP Apps → XP Apps: GUI Features
I don't think this belongs to ducarroz (owner of autocomplete widget only, not the urlbar autocompletion). But I do not own this anymore. So, I will give it to vishy for now. This bug is kinda part of or in association with bug 46584. The urlbar autocompletion and urlbar history share the same datasource. Right now no check is made about the validity of a url before it is put in to urlbar History.(Some people think that it is the right thing to do). Autocompletion just uses whatever is in the urlbar history. If we decide to fix 46584, that should take care of this too. Otherwise we should probably consider having a different datasource for autocompletion which will take care of the problem described here.
Assignee: ducarroz → vishy
history/urlbar -> alecf
Assignee: vishy → alecf
Component: XP Apps: GUI Features → History: URLBar
I swear this is a dupe..
*** This bug has been marked as a duplicate of 9203 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
No dup. This opne is about the autocomplete, not history. Please read back. REOPEN.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I did read back. This is a dup. Autocompletion and urlbar history share the same datasource. The only way we'll realistically block it from autocompletion is if we block it from being added to the urlbar history. I suppose in the future, if autocompletion from global history/other sources ever starts working, this would be an issue, but I think we can cross that bridge when (if) we get to it. *** This bug has been marked as a duplicate of 9203 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
blake, ------- Additional Comments From Radha Kulkarni 2001-01-23 15:16 ------- If we decide to fix 46584, that should take care of this too. Otherwise we should probably consider having a different datasource for autocompletion which will take care of the problem described here. Note the "if"! I strongly support the "otherwise", because I think, bug 9203 (formerly bug 46584) should be WONTFIX. Unless we decide, that we will definitley fix bug 9203, this is not a dup. REOPENing.
.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
> I strongly support the "otherwise" Actually, I support removing autcomplete (inline) altogether, but this is another bug...
url bar autocomplets against it's own history, and the history appears in the dropdown url bar.. it's all the same thing, there is no difference. urlbar history is different than session or global history. (and yes, we want to fix that, but that's another bug) I can't fix this without fixing 9203, and vice versa. it's a dupe for goodness sake. *** This bug has been marked as a duplicate of 9203 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
> I can't fix this without fixing 9203, and vice versa. There are 2 other possible resolutions of this bug: 1. You create different "histories" for the urlbar - one for the drop-down, one for autocomplete. One contains mistypes, the other one not. 2. You mark this bug a dup of the bug to remove autocomplete altogether. This action would be exactly as arguably as duping this bug against bug 9203. I'm sick of this game, so I don't reopen again. But do not verify unless bug 9203 is fixed. If we decide on another resolution (not fixing 9203 and/or removing autocomplete altogether), reopen.
If this bug really depends on bug 9203, it should be marked as dependent, not as a dup. Bogus dups make searching for bugs hard.
Depends on: 9203
Summary: url's that don't resolve still try to autocomplete → auto complete should not include dead/404/incorrect urls
presumably accidental change to summary fixed.
Summary: auto complete should not include dead/404/incorrect urls → url's that don't resolve still try to autocomplete
From reading old comments in this bug, it sounds like autocomplete used to come from location bar history. It now comes from global history, so this bug is no longer a dup.
Status: RESOLVED → REOPENED
No longer depends on: 9203
Resolution: DUPLICATE → ---
Summary: url's that don't resolve still try to autocomplete → erroneous urls still try to autocomplete
*** Bug 161554 has been marked as a duplicate of this bug. ***
*sigh* over to blake. sorry man.
Assignee: alecf → hewitt
Status: REOPENED → NEW
oops.. its really more of a global history implementation detail, but I think we should leave the component at autocomplete. over to blake one more time :) this is pretty minor though, because invalid urls are purged at shutdown... I guess we should also purge invalid URLs on some idle timer too...or have some sort of notification sent when a DNS or other network error related to the url in question occurs
Assignee: hewitt → blaker
*** Bug 162325 has been marked as a duplicate of this bug. ***
*** Bug 155927 has been marked as a duplicate of this bug. ***
Blocks: 131193
*** Bug 199831 has been marked as a duplicate of this bug. ***
Severity: enhancement → minor
Solved. Use error pages instead of dialog messages. Refer. http://texturizer.net/firebird/tips.html#beh_errorpages thanks.
*** Bug 240944 has been marked as a duplicate of this bug. ***
*** Bug 241331 has been marked as a duplicate of this bug. ***
*** Bug 247499 has been marked as a duplicate of this bug. ***
*** Bug 266096 has been marked as a duplicate of this bug. ***
*** Bug 352973 has been marked as a duplicate of this bug. ***
Assignee: bross2 → location-bar
QA Contact: claudius
This bug has now been fixed in Firefox trunk nightlies. If this is a Seamonkey-only bug now, I think it would make sense to change Product to Mozilla Application Suite. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007101204 Minefield/3.0a9pre ID:2007101204
Andrew, do you have a bug #? If this was fixed for core it should also be fixed for SeaMonkey. Robert, do you know something about?
no, don't know about this, Neil might know. I'll ping him about this.
Status: NEW → RESOLVED
Closed: 24 years ago → 18 years ago
Resolution: --- → DUPLICATE
(In reply to comment #37) > *** This bug has been marked as a duplicate of bug 126230 *** Er, wrong bug #?
I said that the bug had been fixed because I am unable to reproduce it and assumed that it had been taken care of with the move to Places (sorry, should have made that clearer instead of just declaring it fixed).
Places has nothing to do with it, SeaMonkey hasn't moved to places yet. The bug number is a typo though, it's 320, not 230.
Product: Core → SeaMonkey
No longer depends on: 9203
You need to log in before you can comment on or make changes to this bug.