Closed Bug 527311 Opened 10 years ago Closed 10 years ago

Addressbar suggests adaptive results regardless of requested behavior

Categories

(Firefox :: Address Bar, defect, major)

3.6 Branch
x86_64
Windows 7
defect
Not set
major

Tracking

()

RESOLVED FIXED
Firefox 3.7a1
Tracking Status
status1.9.2 --- final-fixed
status1.9.1 --- unaffected

People

(Reporter: ekerazha, Assigned: mak)

References

Details

(Keywords: privacy)

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5

In Options > Privacy you can configure addressbar suggestions, choosing beetween

- history and bookmarks
- history
- bookmarks
- no suggestion

Addressbar still suggests history and bookmarks also if I've set "history" only, they have the same behaviour while "history" shouldn't suggest any bookmark.

Reproducible: Always

Steps to Reproduce:
1. Install Firefox 3.5.x
2. Go to a website.
3. Add this site to bookmarks.
4. Clean history, cache etc. (so history is empty)
5. Options > Privacy, change setting from "history and bookmarks" to "history" only
6. Begin to type the website address into the addressbar...
Actual Results:  
Addressbar does show the suggestion for the site! But it isn't in history anymore (we did clean history, cache etc.), it is in bookmarks but we configured "history" only suggestions.

Expected Results:  
It shouldn't suggest bookmarks if we configured "history" only suggestions. "History" only option is broken.

I find this bug on 5 different systems (XP, Vista, 7), clean Firefox 3.5.x installations, ITalian language.
Duplicate of this bug: 527312
Version: unspecified → 3.5 Branch
Version: 3.5 Branch → 3.6 Branch
I confirm this bug on version 3.6 Beta 4 too.

ADDITION: I've found that often the bug doesn't appear immediately but after some time (after some minutes, after some program restarts, after some system restarts...... after some time), so in order to reproduce the bug, you could have to wait some time between the STEP 5 and the STEP 6.

Thank you.
3.6 has different code handling the locationbar and preferences, it is hard to confirm the bug has been ported from 3.5 to 3.6, could be similar but hardly the same.

Can you try to reproduce in Safe mode?
http://kb.mozillazine.org/Safe_Mode

Since it could be caused by an add-on, so we first need to be sure it's not the case.
Thank you for your reply.

I switched back to 3.5.5 now and yes, I can reproduce the bug in safe mode.

I also do know people with this same bug. I've found one here: https://addons.mozilla.org/en-US/firefox/addon/7637

> Same here. Without the add-on Firefox would bring up bookmarks when I        > selected "suggest history" only.

and another on an Italian support board. Probably they are too lazy to open a bug report.
(In reply to comment #4)
> and another on an Italian support board. Probably they are too lazy to open a
> bug report.

ekerazha: you can't say that some people are lazy just because they don't file a bug. Since they aren't able to reproduce the bug they can't fill it just to make you happy. 
More, Bugzilla is an open tool so you are free (as you've done) to fill a bug by yourself.
Then please, be so kind and polite as to never use any offending adjectives towards a support team that for a long time has tried to help you in understanding your issue but with no reproducible results.

Thanks,
Giuliano aka jooliaan
(In reply to comment #5)
>a support team that for a long time has tried to help you in
> understanding your issue but with no reproducible results.

Just for the records: who's interested to follow the whole discussion (in Italian) about ekerazha's issue, can read it here: http://forum.mozillaitalia.org/index.php?topic=40622.0

Neither one of the Italian support team, nor other users have been able to reproduce the "bug" up to now.
> ekerazha: you can't say that some people are lazy just because they don't file
> a bug. Since they aren't able to reproduce the bug they can't fill it just to
> make you happy. 
> More, Bugzilla is an open tool so you are free (as you've done) to fill a bug
> by yourself.
> Then please, be so kind and polite as to never use any offending adjectives
> towards a support team that for a long time has tried to help you in
> understanding your issue but with no reproducible results.

Nobody talked about people who can't reproduce the bug and nobody offended your support board, so please don't fill the bug report with this garbage, this is not the proper place.

> Neither one of the Italian support team, nor other users have been able to
> reproduce the "bug" up to now.

False, the user "Xilreg" did reproduced the bug.

Could somebody clean the bug report from the Giuliano Masseroni garbage so we can focus on the real issue? Thank you.
Mozilla is open, even if we don't support spam we support opinions, so everyone is free to report his own opinion, that's a good reason why bugzilla does not allow us to remove comments :)

That said, we are particularly interested in ways to reproduce the bug in 3.6b4, even if it could be a valid 3.5 bug, there would be small value in fixing it there because:
- the implementation changed too much between 3.5 and 3.6
- looks like it's hard to reproduce, and so hitting a small percentage of users (also hard for us to get consistent steps to verify the fix)

So please, concentrate your search for good steps to reproduce on 3.6 branch for this specific bug.
Attached file Insulting email (obsolete) —
The email sent to me by ekerazha where he insults me just because I wrote here my personal remarks about his politeness. The attached email is in eml format and written in Italian.
> The email sent to me by ekerazha where he insults me just because I wrote here
> my personal remarks about his politeness. The attached email is in eml format
> and written in Italian.

You should know spreading private correspondence without permission is a crime (for Italian law at least... and you are Italian), you'll be contacted by my lawyer as soon as possible.


Now let's focus back on the real issue.

> So please, concentrate your search for good steps to reproduce on 3.6 branch
> for this specific bug.

Ok, I'm going to reinstall Firefox 3.6.
Attachment #416534 - Attachment is obsolete: true
(In reply to comment #10)
> > The email sent to me by ekerazha where he insults me just because I wrote here
> > my personal remarks about his politeness. The attached email is in eml format
> > and written in Italian.
> You should know spreading private correspondence without permission is a crime
> (for Italian law at least... and you are Italian), you'll be contacted by my
> lawyer as soon as possible.
Both of you need to cut it out *right now* or you'll find your bugzilla accounts disabled.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Ok, I think I found a scientific way to reproduce the bug, give me a few minutes as I'm testing the test-case for the 4th time to be sure. Firefox 3.6 Beta 4.
So... this way I can reproduce the bug 95% of the times I tried (sometimes, not always, cleaning the history/cache using CCleaner instead of the built-in option, the issue disappeared, on Firefox 3.6 at least).

- Clean Firefox installation, clean Firefox profile.
- Open Firefox.
- Tools > Options > Privacy, set "History" only, OK
- Type an address: gazzetta.it (this time without www. before)
- Add the site to bookmarks using the star on the address bar
- !new IMPORTANT step! Type "gazz" in the address bar so it does show up the suggestion (site is in the history at the moment so it's ok) and reopen the site choosing the suggested item.
- Click on the home page icon to leave the site
- Tools > Clean...... choose to Clean "All" and check everything.
- Try to type "gazz" in the address bar, *the bookmark is suggested* -> BUG, IMPORTANT: if you used "gazzetta.it" before you have to use "gazz" if you used "www.gazzetta.it" you have to use "www.gaz", you must be consistent or you'll not reproduce it.

Try this and let me know, thanks.
(In reply to comment #13)
> Try this and let me know, thanks.

With these detailed steps I've just been able to reproduce the bug on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; it; rv:1.9.2b6pre) Gecko/20091207 Namoroka/3.6b6pre (new profile)

Is there some sort of caching for the suggestions? The address doesn't show up if I type "www.gazz" or "azz", only if I type "gazz", like if it is searching a "suggestions cache" instead of the real history.

If I set the browser to use suggestions from bookmarks, the address is displayed as expected for all the previous strings ("gazz", "www.gazz", "azz").
For what it's worth, it happens also on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; it; rv:1.9.3a1pre) Gecko/20091208 Minefield/3.7a1pre

It doesn't happen if you don't add a bookmark to that page.
So it seems like 3.5.x, 3.6.x and 3.7.x are all affected.
hm, could be an adapative result, but in such a case you should have typed "gazz" to visit the website and actually visited it) before.
Marco, did you also reproduce the bug like flod and me?
do you see a star near the locationbar dropdown entry?
Looks like some kind of issue with adaptive results filtering.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file xpcshell test (obsolete) —
This looks like due to the adaptive query, filtering out adaptive results i don't see anything, and steps are confirming this.
I'm attaching an xpcshell test that should show an interesting behavior.
the AUTOCOMPLETE_MATCH function gets called once with numeric arguments rather the real values from the db columns, looks like a Storage or Sqlite bug.
I'll try to build a smaller storage-only test to show the behavior.
seems to be caused by the IFNULLS, if the field is an IFNULL(a,b) and the sqlite function gets a number, it does not get the value, if i set an alias on the column and i pass the alias to the function, it actually works.
ok, the test is bogus but actually i can probably come with something better, looks like i indetified the issue in the autocomplete code.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
this could block, but i don't have a strong feeling about it because we are still returning a bookmarked item, so the privacy hit is reduced.
Still the awesomebar is not working as expected returning non history results when we only want them. I'm merely asking blocking to make drivers aware of the issue.
Hope to have a better test with a patch.
Flags: blocking-firefox3.6?
Keywords: privacy
Summary: Addressbar suggests "history and bookmarks" also if I've set "history" only → Addressbar suggests adaptive results even if they have no visits and we want "history" behavior
Attached patch patch v1.0Splinter Review
This is actually interesting.
Attachment #416791 - Attachment is obsolete: true
Attachment #416811 - Flags: review?(sdwilsh)
Comment on attachment 416811 [details] [diff] [review]
patch v1.0

I am shamed.  r=sdwilsh
Attachment #416811 - Flags: review?(sdwilsh) → review+
Summary: Addressbar suggests adaptive results even if they have no visits and we want "history" behavior → Addressbar suggests adaptive results regardless of requested behavior
Any chance to see this fix backported to the 3.5.x stable branch?
http://hg.mozilla.org/mozilla-central/rev/e00cdc84b9dd

no, this fix applies only to 3.6b4, and personally i don't want to risk regressions on 3.5 (it will also be a different bug since the implementation is completely different and would steal development cycles to other stuff), the privacy hit is reduced and 3.6 is around the corner.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
Flags: in-testsuite+
Comment on attachment 416811 [details] [diff] [review]
patch v1.0

approval would probably be enough for this one
Attachment #416811 - Flags: approval1.9.2?
This actually does block, as without it the "control your awesomebar" feature basically doesn't work.
Flags: blocking-firefox3.6? → blocking-firefox3.6+
Attachment #416811 - Flags: approval1.9.2?
Maybe the code is different, but I can reproduce a similar behaviour (I'd say the same) on Firefox 3.5.x. If you need info on the Firefox 3.5.x bug I'm here, as it *is* bugged too and I can show you this.
I'd say the same test-case is applicable to Firefox 3.5.x, let me know if not.
(In reply to comment #30)
> Maybe the code is different, but I can reproduce a similar behaviour (I'd say
> the same) on Firefox 3.5.x. If you need info on the Firefox 3.5.x bug I'm here,
> as it *is* bugged too and I can show you this.

once you have confirmed steps to reproduce the issue on latest 3.5.x release you should open a new bug please, since it's a separate issue. this fix can't be ported to 3.5 since this code does not even exist there.
notice the test is slightly different on 1.9.2 since do_timeout has been changed on trunk not on branch.
> once you have confirmed steps to reproduce the issue on latest 3.5.x release
> you should open a new bug please, since it's a separate issue. this fix can't
> be ported to 3.5 since this code does not even exist there.

Well, as you can read from the first post, I opened this bug report for the 3.5.x release, then you said to me to concentrate my research on the 3.6.x branch and it's what I've done, but I originally found this bug on the 3.5.x version. If you want I can open a new bug report, maybe I should have opened a new one for 3.6.x keeping this one for 3.5.x, but I thought it was the same bug as the "bugged behaviour" is the same.
3.6 has priority atm, just that, so either case 3.6 would have been fixed first. if the steps to reproduce are consistent on 3.5, open a new bug, otherwise try to find steps that allows us to reproduce and fix the issue on 3.5, without them it's hard for us to actually fix a similar issue.
Ok, it seems like the same test-case I posted for the 3.6.x branch doesn't reproduce the issue on Firefox 3.5.5 so the bug is very similar but different, I'm working on a test-case for the 3.5.x branch and I'll (re)open a new bug report for 3.5.x when I'll find it.
The "3.5.x edition" of the bug is fraying me. Yesterday I reinstalled Firefox 3.5.5 with a clean profile and I couldn't find a way to reproduce the bug, this morning still ok, now -> BUG! And I don't installed any new extension, plugin etc. this is very frustrating.
Attached image 3.5.x bug edition
I can reproduce this bug too on 3.5.x - every time I upgrade to a newer version of 3.5.x I checked this function - but never get fixed.

This is a serious bug as the Location Bar Suggestions does NOT work.
Yet another confirmation of the 3.5.x "edition" of the BUG. Could you try to reproduce the bug starting from a clean profile? I still can't identify the exact steps to "scientifically" reproduce the bug.

Developers: could there be some "timer" or something not user-related which could produce the bug (along with a previous user action)?
(In reply to comment #41)
> Developers: could there be some "timer" or something not user-related which
> could produce the bug (along with a previous user action)?
Not that I am aware of.  We'll need reliable steps to reproduce this in order to fix it since none of us have been able to reproduce.
Finally 3.6 version is out so I can trash Firefox 3.5 and its frustrating addressbar bug.

I just hope the 3.6 version bug I found was the only one about addressbar suggestions.

:)
The bug still exists on FF 3.6.10 on my machine. My preference is suggest history only, but FF shows both my bookmarks and history.
Yeah, I still see this behavior on Firefox 3.6.x (it's not the same bug that I've found for Firefox 3.6 Beta). However, like for the Firefox 3.5.x "edition" of the bug, it's difficult to reproduce (it just happened after some days of use and I couldn't understand why), so I get tired to try to reproduce it (because I have to use the browser too, not to delete profiles every day) so I workarounded it using the "NotAwesome" extension https://addons.mozilla.org/en-US/firefox/addon/14031/
if you have steps to reproduce the issue, you should file a new bug, not comment here.
You need to log in before you can comment on or make changes to this bug.