Open Bug 1796961 Opened 3 years ago Updated 1 year ago

Domain history persists after bookmarking in private mode

Categories

(Application Services :: Places, defect)

All
Android
defect

Tracking

(Not tracked)

People

(Reporter: tb.sea, Unassigned)

References

Details

(Whiteboard: [fxsync-places])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

  1. Ensure Settings -> Search -> {Autocomplete URLs, Search browsing history} are enabled
  2. Enter private browsing mode
  3. Navigate to some site for which URLs are not auto-completed by default, e.g. example.com
  4. Bookmark example.com
  5. Delete the bookmark to example.com
  6. type "exam" in the address bar

Actual results:

Firefox will do the following (neither of which it did before bookmarking/un-bookmarking):

  • auto-complete the url showing "example.com"
  • show "example.com" in the "Firefox suggests" section

Clearing the browser history may remove the domain from the auto-complete / firefox suggests sections, though not in all circumstances. I have not been able to determine when this fails / succeeds.

Disabling Settings -> Search -> Search browsing history will avoid the symptoms of this bug, though re-enabling the setting will cause the symptoms to reappear.

Expected results:

Bookmarking a site should not permanently add it to the browsing history, particularly when a site was never visited outside of private mode.

Thanks for the report, but bookmarks aren't added to your history - but are used for auto-complete and for "suggests" by design. This is true for all bookmarks, including ones added while in private browsing and matches the long-standing behavior of desktop Firefox.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID

(In reply to Mark Hammond [:markh] [:mhammond] from comment #1)

Thanks for the report, but bookmarks aren't added to your history - but are used for auto-complete and for "suggests" by design. This is true for all bookmarks, including ones added while in private browsing and matches the long-standing behavior of desktop Firefox.

I think you missed step #4 (delete the bookmark) in my steps to reproduce above. The suggestion still shows up in Firefox Android even after the bookmark is deleted. Surely that is not by design and it does not match the behavior on my desktop Firefox. I also tried this on Firefox Nightly downloaded from the Android Playstore -- still happens there as well. Please advise.

Flags: needinfo?(markh)

I think you missed step #4 (delete the bookmark) in my steps to reproduce above.

I did indeed! Sorry about that.

I'll reopen this for further investigation, but I can't reproduce it locally. Does it reproduce for you after killing and restarting the app?

Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(markh)
Resolution: INVALID → ---

It does reproduce even after killing the app, though I assume this could depend on whether Firefox is set to "Delete browsing data on quit". As indicated above, there are instances where clearing the browsing history will also clear the suggestion and url-autocomplete; however, in other instances it will not (I'm not sure what causes the difference in behavior). Irrespectively, the difference in behavior from clearing browsing history is strange since the site was only ever visited in private browsing mode.

I have reproduced this on 3 out of 3 Android devices I have access to:

  • Pixel 4 on Android 13 (tested on nightly only with new profile)
  • Motorola Moto Z2 Force on Android 8.0.0 (on stable with seasoned profile and nightly with new profile)
  • Nexus 5X on Android 8.1.0 (tested on nightly only with new profile)

(In reply to theodore from comment #4)

It does reproduce even after killing the app

That rules out an in-memory cache, so it sounds like something might be ending up in history.

Status: REOPENED → NEW
Severity: -- → S3

I tried again with a clean install and can reproduce it. Best I can tell, it's because the places database still has an entry in moz_origins - which it probably should not. I've attached an application services test which fails but should succeed. No idea why we don't remove it though - it looks like we do try via the moz_updateoriginsdelete_afterdelete_trigger trigger.

Whiteboard: [fxsync-places]
Component: History → Places
Product: Fenix → Application Services
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: