Closed Bug 200004 Opened 21 years ago Closed 21 years ago

"match only previously typed sites" autocomplete pref doesn't work (type in location bar and nothing is matched)

Categories

(SeaMonkey :: Autocomplete, defect)

Product:
SeaMonkey
Component:
Autocomplete
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: nisheeth_mozilla)

References

Details

(4 keywords)

Attachments

(1 file)

Fix
696 bytes, patch
caillon
: review+
hjtoi-bugzilla
: superreview+
asa
: approval1.4+
Details | Diff | Splinter Review 
found using 2003.03.31 on all platforms. not sure if this pref ever worked.

1. go to the Smart Browsing pref panel and make sure the checkbox for
"Automatically complete text typed in the Location bar" is enabled.

2. click on the Advanced button.

3. make sure these three options are enabled (checked):

a. "autcomplete best match as you type"
b. "show list of matching results"
c. "match only websites you've typed previously"

4. click OK, OK to save and dismiss prefs.

5. open a new browser window.

6. go to the urlbar and enter supersnail.com.

7. once that site loads, click on a link or two.

8. close that window and open another one.

9. go to the urlbar and start typing supersnail.com...

expected: due to (a), autcomplete should prefill "supersnail.com" in the urlbar.
due to (b) a droplist should also appear that contains "supersnail.com". and,
because of (c), the other links visited at supersnail.com should not appear at all.

actual results: neither prefilling of the urlbar nor an autocomplete droplist
appear at all.
QA Contact: claudius → sairuh
It seems to me that only new URLs typed in the URL bar have this problem.  URLs
that I typed in last week will autocomplete correctly with today's build (2003
03 31 08).
hm, i tried this today (a different browser session from yesterday, but same
profile), and it still doesn't work for me.
Nav triage team: nsbeta1-
Severity: normal → enhancement
Keywords: nsbeta1 → nsbeta1-
this isn't an enhancement, since the feature as is doesn't work.
Severity: enhancement → normal
Keywords: helpwanted, relnote
WorksForMe on Linux with a Mozilla binary built yesterday.
Autocomplete does not work with 2003041408 trunk on WinXP.
Keywords: regression
Confirming that autocomplete works if browser.urlbar.matchOnlyTyped is set to
"false". If it is set to "true", autocomplete stops working.

Question: How does Bug 194992 get an nsbeta1+ designation, and this bug gets an
nsbeta1-?
*** Bug 202940 has been marked as a duplicate of this bug. ***
*** Bug 201160 has been marked as a duplicate of this bug. ***
Flags: blocking1.4b?
Flags: blocking1.4?
Keywords: useless-UI
Summary: "match only previously typed sites" autocomplete pref doesn't work → "match only previously typed sites" autocomplete pref doesn't work (type in location bar and nothing is matched)
Great. This broken feature finally make autocomplete more or less completely
unusable. (Alongside bug 96700 and bug 175725). Way to go. I can't wait to see
what else is up the sleeve for 1.4.
WorksForMe with latest Firebird running under Linux.
Still broken with 2003050211 trunk (latest trunk).
strangely enough, there are a few urls that still work like they used to
(triggering autocomplete with the given setting "match only websites you've
typed previously" and .."match as you type":

slashdot.org seems to work all the time. And news.bbc.co.uk
I can't even remember i ever type the last one - i have a bookmarke of that one
easily available. (I don't have slashdot bookmarked.)
Although this is out of the scope of this bug, I would add to R.K.Aa's comments
that Mozilla has always spuriously completed URLs that weren't typed in with
that pref set.
wrt comment 14, see also bug 128341. (a very annoying bug indeed.)
Flags: blocking1.4b? → blocking1.4b-
This pref is really important to making autocomplete usable and we should get it
for 1.4.
Flags: blocking1.4? → blocking1.4+
Keywords: nsbeta1
this regressed between linux trunk 2003032705 and 2003032805
backing out the second patch from bug 197127 (attachment 118506 [details] [diff] [review]) fixes this bug
Looking into this...
Assignee: varga → nisheeth
Target Milestone: --- → mozilla1.4final
I can confirm that this used to work (in 1.3 release), but it's broken in
1.4beta (under Linux, at least).

Specifically, I have the options checked like so:
    [ ] Autocomplete best match as you type
    [x] Show list of matching results
    [x] Show internet search engine
    [x] Match only websites you've typed previously

When installing 1.4beta I completely erased my old profile, and so I can't seem
to make any URLs at all stick in there.  (That is, I have no existing URLs
stored so I can't tell if the problem is in the storing or the retrieving.) 
Here's hoping this is fixed by 1.4 release; it's a favorite feature of mine.
*** Bug 204998 has been marked as a duplicate of this bug. ***
I can also confirm that this used to work in 1.3 on XP.  I am running the latest
1.4b build (completly wiped and reinstalled cleanly with no prefs) and it is
still broken.

Interestingly, if I turn on "Match only websites you've typed previously" it
fails to work at all.  But if I turn it off it works for all links, both typed
and not.  So, this is a workaround of sorts.

Windows XP (SP1)
IBM ThinkPad P4 1.6Ghz / 1G RAM / 8GB HD
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030512

Later...
  Richard
Attached patch Fix — — Splinter Review 
s/fixedupURI/fixedUpURI.  I had cased the variable name wrongly when I fixed
bug 197127.  Thanks to Andrew Schultz for doing the legwork to narrow down the
problem to my patch.
Comment on attachment 123673 [details] [diff] [review]
Fix

Here is another case why empty catch blocks are evil.  I don't think exceptions
like this should be eaten without at least dumping an error to console, but we
have this problem in so many places.

Anyway, I can review this.  r=caillon.
Attachment #123673 - Flags: review+
Comment on attachment 123673 [details] [diff] [review]
Fix

Thanks, Chris, for the r=.

Heikki, would you sr=?	This is a one character change for fixing a 1.4
blocker.

Thanks!
Attachment #123673 - Flags: superreview?(heikki)
Attachment #123673 - Flags: superreview?(heikki) → superreview+
Attachment #123673 - Flags: approval1.4?
Comment on attachment 123673 [details] [diff] [review]
Fix

a=asa (on behalf of drivers) for checkin to 1.4
Attachment #123673 - Flags: approval1.4? → approval1.4+
Fix checked into trunk:

Checking in sessionHistoryUI.js;
/cvsroot/mozilla/xpfe/browser/resources/content/sessionHistoryUI.js,v  <--  sess
ionHistoryUI.js
new revision: 1.45; previous revision: 1.44
done
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
(This bug currently has both keywords 'nsbeta1' and 'nsbeta1-'.
May be one of them could be removed ?)

thanks for fixing this, nisheeth!

vrfy'd fixed with 2003.05.20.08 comm builds.
Status: RESOLVED → VERIFIED
Keywords: nsbeta1
*** Bug 206750 has been marked as a duplicate of this bug. ***
*** Bug 207956 has been marked as a duplicate of this bug. ***
We're back! Checked with 20030810 trunk and 2003081504 trunk. This has returned.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Flags: blocking1.5b?
Flags: blocking1.4b-
Flags: blocking1.4+
Target Milestone: mozilla1.4final → ---
File a new bug, then.  This specific instance of the bug is fixed.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Restoring verified state from comment 28.
Status: RESOLVED → VERIFIED
Yes sir, master sir. Bug 216441.

DO the Bugzilla guidelines that state a bug shouldn't be reopened when it occurs
again just because the fix might be different? Seems like a waste, but no matter
to me. It's not my database :)
Flags: blocking1.5b?
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: