426864 - Only show user typed history pages for the urlbar dropdown

Status: RESOLVED FIXED

(Toolkit :: Places, enhancement, P3)

Description

[al_9x]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

You can access bookmarks from the toolbar, sidebar, menu, but the typed url history is only available from the urlbar dropdown, so there should be an option to not pollute it with bookmarks.

I wasn't sure if Bug 422944 covers this request, as it talks about search results which is not necessarily the same as the deafault dropdown

Reproducible: Always

Comment 2

[al_9x]

Per Bug 426924, urls from history that were not user entered, should also be kept out.  Just as with bookmarks you can see history elsewhere (sidebar).  If you conflate everything then a useful feature, user entered url history, is lost.

Comment 3

[al_9x]

Can anyone from Mozilla comment on this?  Is there any workaround? Searching all available urls makes sense and is an enhancement but showing everything when dropping down is not an enhancement, it's a loss of user entered URL history.

Comment 4

[Jacob]

The history being shown in autocomplete spoils the feature completely for me as you end up with a lot of long useless urls from sites. I am currently using browser.urlbar.matchOnlyTyped, however it would be much better if i could have my bookmarks show up too.

Comment 6

[Ed Lee :Mardak]

Attachment: v1

Bug 463483 provides a restrict for typed pages, so use it to find typed pages with visit count > 0.

Comment 7

[Marco Bonardo [:mak]]

Comment on attachment 346744 [details] [diff] [review]
v1

first-pass:

   mRestrictTyped = mAutoCompleteOnlyTyped;
+  

nit: trailing space

this needs a test though

Comment 8

[al_9x]

(In reply to comment #6)
> Created an attachment (id=346744) [details]
> v1
> 
> Bug 463483 provides a restrict for typed pages, so use it to find typed pages
> with visit count > 0.

Can you please confirm if the proposed solution applies to non search drop down?  i.e. is the meaning of mCurrentSearchTokens.Count() == 0, that you are not searching and just dropping down?

Is there a new option for this?

Comment 9

[Ed Lee :Mardak]

Attachment: v2

Add tests and change to explicitly check for empty original search. Tests failed for special searches that ended up with removed tokens if we check after processing.

Comment 10

[Ed Lee :Mardak]

Talked to beltzner on IRC and he said that this should be the behavior when clicking on the dropdown button. Could possibly make it for RC1.

I'll need to rework the patch here and in bug 463483 if we're not targeting bug 463459 for rc1.

Comment 11

[Dietrich Ayala (:dietrich)]

Comment on attachment 346845 [details] [diff] [review]
v2

r=me, thanks!

Comment 12

[Ed Lee :Mardak]

http://hg.mozilla.org/mozilla-central/rev/5a68110f39c1

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 346845 [details] [diff] [review]
v2

a191=beltzner

Comment 14

[Ed Lee :Mardak]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/fe68aec0c04b

Comment 17

[al_9x]

clearing history should clear the "typed" flag on bookmarked urls, otherwise if you open a bookmark with typed flag (after clearing history) it starts showing up in the urlbar drop down.

Comment 18

[Shawn Wilsher :sdwilsh]

(In reply to comment #17)
> clearing history should clear the "typed" flag on bookmarked urls, otherwise if
> you open a bookmark with typed flag (after clearing history) it starts showing
> up in the urlbar drop down.
Then you should file a new bug for that behavior instead of changing the scope of your initial report long after it was fixed.

Comment 19

[al_9x]

(In reply to comment #18)
> (In reply to comment #17)
> > clearing history should clear the "typed" flag on bookmarked urls, otherwise if
> > you open a bookmark with typed flag (after clearing history) it starts showing
> > up in the urlbar drop down.
> Then you should file a new bug for that behavior instead of changing the scope
> of your initial report long after it was fixed.

Bug 519830