Open Bug 1650511 Opened 5 years ago Updated 7 months ago

URL remains in places.sqlite after deleting from bookmark (corrupt moz_origins)

Categories

(Firefox :: Bookmarks & History, defect, P3)

Product:
Firefox
Component:
Bookmarks & History
Version:
78 Branch
Type:
defect

Tracking

()

People

(Reporter: nigelh747, Unassigned)

References

Details

(Keywords: privacy, Whiteboard: [snt-scrubbed][places-privacy])

Attachments

(1 file, 1 obsolete file)

test_origins.patch
1.59 KB, patch
Details | Diff | Splinter Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

I had a bookmarked URL that was on my desktop client and synchronised it to my Android Firefox client.

I deleted the bookmark from the Android Client and resynchronised

Actual results:

Bookmark disappeared from the Desktop Client correctly however the places.sqlite still remembered the old URL.

The only way of clearing the issue was to delete the places.sqlite.

Expected results:

If Bookmarks are deleted remotely, the desktop client should also remove the bookmark and make sure on synchronisation that the places.sqlite has the entry removed so that it does not always suggest it

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Bookmarks & History

Did you also remove the page from history?

Removing a bookmark only removes the fact that it is bookmarked, however it remains in your history until you've removed it from there as well (or it expires after about 6 months).

Flags: needinfo?(nigelh747)

Mark

I have the setting to remove all history on exiting Firefox. I also manually cleared all history and site settings, but the previously bookmarked URL that was removed from another device via synchronisation still kept the URL on the desktop.

I dont synchronise tabs or history, just bookmarks, addons, passwords and addons..

Thus, I believe that there is definitely a bug when a bookmark created on a desktop profile, synchronised to another device (android), removed from that device, synchronised back, bookmark disappears from the desktop, however the URL remains in the history even if you clear it - it would suggest that it somehow still in the places.sqlite file carries a bookmark attribute that stops the normal remove from history functionality removing it from history.

Flags: needinfo?(nigelh747)

bookmarked pages are not removed immediately on bookmarks removal anyway, they are removed on sunsequent idles, or on Clear History. See https://bugzilla.mozilla.org/show_bug.cgi?id=1475582#c2
If the page goes away after a bit it's covered by that bug.

Otherwise, if you can find the page after a Clear History, there's something wrong for sure.
Though, when you say "Even if you clear it" it's unclear to me what you mean: did you clear whole history, just a single page, did you use "Forget about this Site?". There are many different ways to remove history and not all of them are expected to remove the page.
In pratice, I'd like a more fine grained list of steps you made before checking the url was still there. And also how you confirmed that the url was still there.

Flags: needinfo?(nigelh747)

(In reply to Marco Bonardo [:mak] from comment #4)

bookmarked pages are not removed immediately on bookmarks removal anyway, they are removed on sunsequent idles, or on Clear History. See https://bugzilla.mozilla.org/show_bug.cgi?id=1475582#c2
If the page goes away after a bit it's covered by that bug.

Otherwise, if you can find the page after a Clear History, there's something wrong for sure.
Though, when you say "Even if you clear it" it's unclear to me what you mean: did you clear whole history, just a single page, did you use "Forget about this Site?". There are many different ways to remove history and not all of them are expected to remove the page.
In pratice, I'd like a more fine grained list of steps you made before checking the url was still there. And also how you confirmed that the url was still there.

I have removed the bookmark and checked that the synchronisation on both devices was up to date.

I also checked in the bookmark library and saw that the bookmark was not there and only was in history

I tried to delete the individual bookmark from history from the URL bar and it did not go

My settings are to clear all history when I exit a session. This I did several times, but when I started Firefox desktop it still was in the history

I manually asked Firefox from the options, privacy and security to clear all data now including history. The old bookmark that is no more remained in history.

I then closed Firefox again, renamed the places.sqlite file and opened Firefox. Once the places.sqlite file was created, the issue had disappeared.

Hope that helps explain that as far as I am concerned, exiting Firefox that should and does clear history on exit, should have removed what was a previous bookmark and its history, but that did not happen.

I am 99.99% certain that a bug exists and that when a bookmark is removed on a different synchronised device (where history and tabs are not synchronised), there is an issue when the synchronisation is removing the bookmark its not removing it from history

Flags: needinfo?(nigelh747)

(In reply to Nigel from comment #5)

I tried to delete the individual bookmark from history from the URL bar and it did not go

Ok, this may not work, not all the urlbar entries support direct removal, the best way is to search in the Library Window or in the History Sidebar and then Forget about this Site, or at least remove from there.

My settings are to clear all history when I exit a session. This I did several times, but when I started Firefox desktop it still was in the history

So you have Clear History on Firefox Shutdown option enabled, and in the Clear History panel you selected History and Downloads?

Have you ever used a third party app to clear Firefox data, like CCleaner or similar? Those apps are known to leave orphans behind that may not be cleared properly.

I manually asked Firefox from the options, privacy and security to clear all data now including history. The old bookmark that is no more remained in history.

To check it remained in history, did you just type in the urlbar and it was autofilled, or did you actually open the History Sidebar and searched for it?
Could you please give me more details, are you typing part of the domain in the urlbar? if you type the same string in the History Sidebar does anything appear?
If you are doing it differently, having a sshot of the urlbar with the result may also help me.

Sorry for the many questions, I'm trying to restrict a bit the investigation area.
Thank you for your help.

I am 99.99% certain that a bug exists and that when a bookmark is removed on a different synchronised device (where history and tabs are not synchronised), there is an issue when the synchronisation is removing the bookmark its not removing it from history

This is an interesting thing to investigate, I would only have 2 theories:

  1. somehow the foreign_count column in moz_places gets out of sync, though that would mean something is removing a bookmark in a very strange way, or something ran a raw SQL query on the database
  2. somehow the origin is not being removed from moz_origins, though there must be something keeping it alive.
Flags: needinfo?(nigelh747)

Confirming for investigation, we still need info though.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: privacy
Priority: -- → P2

(In reply to Marco Bonardo [:mak] from comment #6)

(In reply to Nigel from comment #5)

I tried to delete the individual bookmark from history from the URL bar and it did not go

Ok, this may not work, not all the urlbar entries support direct removal, the best way is to search in the Library Window or in the History Sidebar and then Forget about this Site, or at least remove from there.

I tried this and it did not work

My settings are to clear all history when I exit a session. This I did several times, but when I started Firefox desktop it still was in the history

So you have Clear History on Firefox Shutdown option enabled, and in the Clear History panel you selected History and Downloads?

Yes

Have you ever used a third party app to clear Firefox data, like CCleaner or similar? Those apps are known to leave orphans behind that may not be cleared properly.

Not with this profile and from memory not in the last few years

I manually asked Firefox from the options, privacy and security to clear all data now including history. The old bookmark that is no more remained in history.

To check it remained in history, did you just type in the urlbar and it was autofilled, or did you actually open the History Sidebar and searched for it?

I simply typed in the urlbar and it was automatically filled

Could you please give me more details, are you typing part of the domain in the urlbar? if you type the same string in the History Sidebar does anything appear?

Just typed a couple of letters unique to the URL and it appeared in the URL bar - its not in the history now as I have replaced the places.sqlite file

If you are doing it differently, having a sshot of the urlbar with the result may also help me.

Sorry - tried to obtain the places.sqlite file but it appears I have deleted it.

Sorry for the many questions, I'm trying to restrict a bit the investigation area.
Thank you for your help.

I am 99.99% certain that a bug exists and that when a bookmark is removed on a different synchronised device (where history and tabs are not synchronised), there is an issue when the synchronisation is removing the bookmark its not removing it from history

This is an interesting thing to investigate, I would only have 2 theories:

  1. somehow the foreign_count column in moz_places gets out of sync, though that would mean something is removing a bookmark in a very strange way, or something ran a raw SQL query on the database

The only way that the bookmark was removed on the desktop was because it was removed from the Android client and it then told as part of Sync to remove it from the desktop client. Note that my sync does not include history and that may account for the bug as a case that was not tested?

  1. somehow the origin is not being removed from moz_origins, though there must be something keeping it alive.
Flags: needinfo?(nigelh747)

So the problem would apparently be in a moz_origins entry not being removed. We had this problem in the past when a third party app did something unexpected, not going through the official API. Either moz_origins has an orphan, or the page has a broken foreign_count for which it can't be removed.
Unfortunately without the broken database we can't tell what was the actual corruption.

We should probably clear moz_origins orphans on a clear history, and teach Places Maintenance to remove them and probably also fix wrong foreign_counts.
Off-hand I think this was a latent corruption in the db data, more than an actual bug caused by Sync, because I can't find a point where Sync would not go through the usual triggers that cleanup moz_origins, and we didn't see many reports.

Certainly it would be nice if we'd fix these corruptions automatically.

Priority: P2 → P3
Summary: URL remains in places.sqlite after deleting from bookmark → URL remains in places.sqlite after deleting from bookmark (corrupt moz_origins)

I think there might be a bug in Sync where we forget to clean up moz_origins. When we delete bookmarks, we set the frecency of their URLs to -1 (to avoid calling CALCULATE_FRECENCY for every item in a long-running transaction), and then recalculate all of them after. But we never call DELETE FROM moz_updateoriginsupdate_temp after recalculating. (Our recalculate-on-idle logic does this correctly).

Could that cause this bug?

I had missed that DELETE FROM moz_bookmarks call, maybe because it's in a rust file and my mind skipped it :(
But yes, removing bookmark without deleting from moz_updateoriginsupdate_temp would cause orphans to appear if nothing else later deletes from it.
https://searchfox.org/mozilla-central/rev/85ae3b911d5fcabd38ef315725df32e25edef83b/toolkit/components/places/nsPlacesTriggers.h#157,163-168

We should fix that, but also cleanup orphans in maintenance and clear history.
And I think we should add a MOZ_ASSERT on shutdown that checks moz_updateoriginsupdate_temp is empty.
Thanks for finding this.

Priority: P3 → P2
Severity: S3 → S2
Whiteboard: [snt-scrubbed][places-privacy]
Assignee: nobody → daisuke
Status: NEW → ASSIGNED

I tried to confirm with the following STRs, but could not reproduce this issue.

  1. Prepare browsers A and B (and logged into Firefox Account).
  2. A: Creates a bookmark for http://example.com.
  3. B: Push Sync button.
    • Confirmed that the bookmark of http://example.com was created in B.
  4. B: Remove the bookmark.
  5. A: Push Sync button
    • Confirmed that the bookmark of http://example.com was removed from A.
  6. A: Close the browser (to see the sqllite)
  7. Check places.sqlite on a terminal.
    • Confirmed that record of {url: "http://example.com", visit_count: 0, foreign_count: 0} is in moz_places table.
    • Confirmed that record of {host: "example.com" } is in moz_origins table.
  8. A: Boot the browser again.
  9. A: Clear all histories.
  10. A: Close the browser.
  11. Check places.sqlite on a terminal.
    • Confirmed that record of {url: "http://example.com"} is not in moz_places table.
    • Confirmed that record of {host: "example.com" } is not in moz_origins table.

And also, I made a test that simulates the above STR, but could not reproduce the issue too.
https://phabricator.services.mozilla.com/D172641#change-FZ6MeJ7D2lr0
Am I doing something wrong?

BTW, it seems like no problem, as we call DELETE FROM moz_updateoriginsupdate_temp after calling remove_local_items()?
https://searchfox.org/mozilla-central/rev/5349e0db4db34dabecced362a59ea7528dcc7afc/toolkit/components/places/bookmark_sync/src/store.rs#739,753
And also, we delete the table in PlacesFrecencyRecalculator regularly now.

I don't think the original bug can be reproduced today, due to the Recalculator, though it may still happen due to third party software, and if we have a creash between removing a page and deleting from moz_updateoriginsupdate_temp. In the future we could maybe use the recalc_frecency field I'm adding to moz_origins to do the removal when we recalc the origin frecency.

Anyway, for now we at least need a maintenance task to clean up old databases that were already broken, we've seen multiple reports.

Hi - I just repeated the steps that I originally did and the bug still exists

To recreate - bookmark a URL with Firefox Desktop (I am using Windows x64 version) and undertake a SYNC

Go to an Android device and undertake a SYNC

Find the new bookmark and delete it

Undertake another SYNC

Go to the Desktop Firefox and undertake a SYNC

Exit Firefox Desktop with the options to delete history etc

Copy the places.sqllite file

Open Firefox Desktop and view the copied file

I used SQL as SELECT * FROM moz_bookmarks
and went to the last record

I could see the just added URL even though I had deleted it via Android

Signed into another device a few hours later and the website that I had bookmarked was suggested by Firefox on Android, even when I asked Firefox not to remember history, so I believe the website is still kept in places.sqllite even though it's no longer a bookmark

Hi Nigel! Thank you very much for your report!

I tried to reproduce this using the same OS (Windows + Android), and yes, I could reproduce it.
But not always. Sometimes,

  • could delete immediately and the data in places was no problem
  • could delete but took a long time to delete. But the data was no problem
  • could delete but took a long time to delete. And the forein_count in moz_places remained as 1. So the data was moz_origin even if clear all history.

So, it looks like not only the database issue, but Sync system? We need to investigate more.

Glad that you are able to reproduce the issue.

Having taken a quick look at my places.sqllite file, it contains around 862 entries and I don't believe that I have more than 200 bookmarks. Thus there is an issue with the file that it contains history even when as a privacy and security issue that the user requests that Firefox deletes all history after exiting. The only things that should remain in the database file should be the users bookmarks if history is to be deleted at the end of a session for example.

My guess is that Synchronisation and the Firefox clients at least with Windows and Android all have related issues.

I just did a quick check on my bookmarks Jason file and my places file.

Given that I have the settings to clear history on exit,I would only expect the places.sqllite file to contain the bookmarks.

I have 364 bookmarks but 865 items in the places file.

This is a fundamental privacy issue. Do I need to raise this as a separate issue?

(In reply to Nigel from comment #20)

This is a fundamental privacy issue. Do I need to raise this as a separate issue?

Before jumping to conclusions, lets check the facts first.

I have 364 bookmarks but 865 items in the places file.

What do you mean by the "places file"? The moz_bookmarks table or across all of the tables?

It wouldn't surprise me if you are including other tables in the count - for example, the moz_bookmarks table doesn't store URLs but they are stored in the moz_places table. That would double the number of entries to begin with. We also store origins in separate tables as well.

If you are only including the moz_bookmarks table, then take note of the fact that folders and tags are stored in there as well. For example, an "empty" table with no bookmarks in it would have 5 or 6 entries in it to begin with - which are the built-in folders.

(In reply to Mark Banner (:standard8) from comment #21)

(In reply to Nigel from comment #20)

This is a fundamental privacy issue. Do I need to raise this as a separate issue?

Before jumping to conclusions, lets check the facts first.

I have 364 bookmarks but 865 items in the places file.

What do you mean by the "places file"? The moz_bookmarks table or across all of the tables?

Just from the bookmarks table itself!

It wouldn't surprise me if you are including other tables in the count - for example, the moz_bookmarks table doesn't store URLs but they are stored in the moz_places table. That would double the number of entries to begin with. We also store origins in separate tables as well.

If you are only including the moz_bookmarks table, then take note of the fact that folders and tags are stored in there as well. For example, an "empty" table with no bookmarks in it would have 5 or 6 entries in it to begin with - which are the built-in folders.

Ok it's the bookmarks table itself having 865 items in it. The bookmarks Jason file shows 364 bookmarks.

I have around 20 folders and subfolders, so that means I should have around at maximum 400 bookmarks, but the places.sqllite file in the moz_b9okmarks table has more than double the number of entries. Thus it's a problem..

I could look at at an Android version of a different profile, and I spotted the following
a) number of bookmark records appeared to include deleted bookmarks from the same user on the same device
b) the synchronise table has double the number of entries.

Looking at the top sites table it has entries even though all history is supposed to be removed by the settings...

Hi Nigel.

I don't know why but I can't reproduce this now.. (I wonder if I misunderstood something..)
I am very sorry to trouble you, if possible, could you tell me about the following specific operations?

  1. How to add a bookmark on the Desktop. e.g. click the star icon on the urlbar etc.
  2. Place where the bookmark was added to on the Desktop. e.g. toolbar etc.
  3. How to sync on Android. e.g. click "Sync now" button etc.
  4. How to remove the bookmark on Android. e.g. select a menu item of removal from 3 dot menu etc.
  5. How to sync on Android to apply to the Desktop. e.g. pull down the screen of bookmark etc.
  6. How to sync on the Desktop. e.g. click "Sync now" button etc.

And also, if possible, I want to know the Firefox version for each.

Thank you very much!

Flags: needinfo?(nigelh747)

(In reply to Daisuke Akatsuka (:daisuke) from comment #23)

Hi Nigel.

I don't know why but I can't reproduce this now.. (I wonder if I misunderstood something..)
I am very sorry to trouble you, if possible, could you tell me about the following specific operations?

  1. How to add a bookmark on the Desktop. e.g. click the star icon on the urlbar etc.
    I normally click the star icon on the urlbar
  2. Place where the bookmark was added to on the Desktop. e.g. toolbar etc.
    Normally put to another folder such as other bookmarks
  3. How to sync on Android. e.g. click "Sync now" button etc.
    I press my account name that then adds the ability to resync
  4. How to remove the bookmark on Android. e.g. select a menu item of removal from 3 dot menu etc.
    Take the 3 dots option
    Take bookmarks
    Navigate to Desktop Bookmarks
    Navigate to the folder you saved on the desktop
    Take option at Right hand side of bookmark
    Select the delete bookmark
  5. How to sync on Android to apply to the Desktop. e.g. pull down the screen of bookmark etc.
    See 3 above
  6. How to sync on the Desktop. e.g. click "Sync now" button etc.
    Take the menu for tools, options and then sync

And also, if possible, I want to know the Firefox version for each.
This has been occurring for over 3 years so is indifferent to the version number.
It still occurs with version 110, but would expect it to exist on 111 as well

Thank you very much!

I am not able to clear the needs info flag but I have answered the questions

Thank you very much! I will clear the need info.

Flags: needinfo?(nigelh747)

(In reply to Nigel from comment #22)

I have around 20 folders and subfolders, so that means I should have around at maximum 400 bookmarks, but the places.sqllite file in the moz_b9okmarks table has more than double the number of entries.

Maybe you also have tagged some bookmarks? Those will create entries.
What matters is just the number of urls in the moz_places table.

Hi Marco

(In reply to Marco Bonardo [:mak] from comment #27)

(In reply to Nigel from comment #22)

I have around 20 folders and subfolders, so that means I should have around at maximum 400 bookmarks, but the places.sqllite file in the moz_b9okmarks table has more than double the number of entries.

Maybe you also have tagged some bookmarks? Those will create entries.
What matters is just the number of urls in the moz_places table.

  • that explains things better - 349 items in the moz_places file.

There are several entries that I know I have deleted from bookmarks that still remain, typically after they have been deleted via a different device typically created in desktop and deleted in Android - that still needs to be resolved - and thats in this case

Removing a bookmark doesn't immediately remove the page, that happens asynchronously at a later time, at least for now (we'd like to change it so it just happens when the bookmark is removed). So all of that must be verified. This bug is about entries that, even after days, persist in the database. If there's a bug in Sync not removing orphan origins, it should be handled, but anyway we'll still need to clean things periodically after fixing that.

(In reply to Marco Bonardo [:mak] from comment #29)

Removing a bookmark doesn't immediately remove the page, that happens asynchronously at a later time, at least for now (we'd like to change it so it just happens when the bookmark is removed). So all of that must be verified. This bug is about entries that, even after days, persist in the database. If there's a bug in Sync not removing orphan origins, it should be handled, but anyway we'll still need to clean things periodically after fixing that.

I believe that you also must remove old bookmarks at anytime the user initiates the clear all history option. Whether that's invoked on shutdown or manually.

This needs to be fixed for all versions of Firefox not only Desktop but also Android

Hello,
I've tried investigating the explained issue with steps provided by Nigel as well as steps provided by Daisuke, but without any success. The moz_places, moz_origins or moz_bookmarks doesn't contain any trace of the deleted bookmark entry or its URL.
I've also tried the issue with a dirty profile (containing old bookmark data) and tried reproducing it by deleting the old data from the phone, but upon removal, no trace of its URL is kept in the DB.
This was tested using a Windows 10 + Android device, using the latest nightly build, which should still contain the issue.

Duplicate of this bug: 1493795

Hi

I last tested this on release 110 and 111 and was able to reproduce.

You need to create the bookmark (in one place) sync it on both devices, delete on the other device and sync it back again, and then check on the original device.

I can recheck around the weekend if you want me to do so. It's possible that Fenic has had a change that's resolved the issue but ...

I've been looking into this due to a similar bug reported on mobile (so in app-services) and I think I've identified an issue. IIUC, for all "filtered" history clearing operations, the removal code is optimized to only clear origins etc for items which were affected by the removal. This means that if a bookmark is deleted while it has zero visits, none of the filter operations other than PlacesUtils.history.clear(); will remove the now-orphaned origin.

There are many ways to delete a bookmark while it has no visits, having Firefox never remember history would probably make it more likely than not.

(The main reason I'm writing this is that I discovered the behaviour in app-services and wondered if it happened over here, and this test was the result. Please LMK if I've misunderstood anything)

thank you Mark, that makes sense.
I have some plan in the future to cleanup orphans when an origin's frecency must be recalculated. Plus there's Bug 1475582 to do cleanups when a bookmark is removed, rather than leaving that to timed expiration.
Having a more precise eviction, rather than just "timed expiration", should help here.

In the meanwhile I still think it's worth adding a maintenance task to cleanup weekly.

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

Your explanation explains what I have seen as 99% of all use of Firefox on mobile is done in incognito mode.

Also for both mobile and desktop I have the settings to clear all history on exit that I typically do multiple times a day.

(In reply to Marco Bonardo [:mak] from comment #35)

In the meanwhile I still think it's worth adding a maintenance task to cleanup weekly.

Thanks Mak. Is there any reason the deletion of a bookmark can't unconditionally call cleanupPages? I'm thinking of adding that to app-services but wondering if there's some reason that's dangerous?

Flags: needinfo?(mak)

Actually, I guess one reason is that some of these deletes happen via a cascade - eg, deleting a parent folder. It could probably be managed via triggers though. While I think a weekly task seems ideal to catch up what we missed, it still leaves a worst-case scenario where the bug appears for a week, then magically disappears. If the site in question happens to be NSFW, the fact autocomplete keeps trying to fill it for that week doesn't seem ideal.

Flags: needinfo?(mak)
See Also: → 1813898

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

Thanks Mak. Is there any reason the deletion of a bookmark can't unconditionally call cleanupPages? I'm thinking of adding that to app-services but wondering if there's some reason that's dangerous?

Well, long term that's more or less the plan. I say more or less because I don't know if we're going to invoke cleanupPages, or rather a bookmark-related version of it. That's what I'd like Bug 1475582 to do, every code removing stuff should take care of its own orphans, rather than delegating.
The weekly cleanup was just intended as a short term workaround, not as a solution.

Hey Mak, when you can find a minute or 2, can you please have a look at https://github.com/mozilla/application-services/commit/1706218dbdb35cb6f35932584ab5e5b10c171300 - it's a relatively small patch and seems to fix the issue in app-services, but I'd really like to know if you can think of anything that would go wrong if the same patch was applied to desktop (because the schemas are so close, the same thing would likely go wrong in a-s)

The usual problem with using a trigger is Sqlite does not support per statement triggers, instead the trigger runs per each row, that is expensive on batch removals.
We already do have a trigger on moz_bookmarks deletion and we don't have a batch removal API, so the cost woule be acceptable.

One downside is we must send a page-removed notification, that can be solved by dispatching a main thread runnable and notifying from there. This adds some complexity.

Then we should still remove other orphans caused by the page removal, like icons, annotations, or input history.
We could theorically do those removals in a moz_places DELETE trigger (we have one already). Though that trigger would then be activated by history, that has batch removal APIs "unfortunately".
That trigger would be expensive, and likely we don't want it.

Overall, while we could remove the moz_places entry with a trigger, the benefit would be small because:

  • we still have to do all the other page related removals outside of the trigger
  • it would complicate notifying about the page removal

So I think it may not be worth it, compared to just running cleanup queries and notifying.

While looking at this I notices we should set an origin's recalc_frecency to 1 when a page is removed. We only do that when a page's frecency changes. This sounds like a bug we must fix regardless, so I filed Bug 1837217 for it.

Note: I must also note removing from moz_places won't solve this bug, that is about moz_origins

Thanks Mak. For app-services, I think most of these limitations don't really apply. We don't currently support annotations, icons or input history, nor do we support observer like capabilities to notify about the removal. app-services also has an "on delete cascade" so deleting the place does delete the origin.

In addition to the removal we make with moz_updateoriginsdelete_afterdelete_trigger, I introduced a trigger in Bug 1846781, to ensure empty origins are removed when their frecency changes to 0.
That should be sufficient to handle dynamic cases.

The only thing left is to clean-up leftovers from previous versions, for which a PlacesDBUtils maintenance task should be sufficient.
I wouldn't do anything else here.

Severity: S2 → S3
Priority: P2 → P3
Assignee: daisuke → nobody
Status: ASSIGNED → NEW
Attachment #9323144 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: