[GH-ISSUE #572] hints for MANY bookmarks - what to do? #402

Closed
opened 2026-02-25 22:37:02 +03:00 by kerem · 12 comments
Owner

Originally created by @drandreaskrueger on GitHub (Jun 16, 2020).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/572

What I already found out is this:

floccus showed

Error
QUOTA_BYTES quota exceeded

then I found this workaround for today:

chrome --unlimited-storage

Suggestion - Your floccus add-on can ask for permission to store more than 5 MB, read this https://developer.chrome.com/apps/offline_storage

I keep an eye on the nextcloud server "htop" - which is fine; and on the chrome "task manager" which is at 150-250 CPU for a very long time now.

What can I do with MANY bookmarks?


Is your feature request related to a problem? Please describe.
more than a decade of bookmarking ...

Describe the solution you'd like
either floccus or nextcloud is hitting some limits

Describe alternatives you've considered
reinstalling nextcloud but this time not via snap, because I read that snap causes programs to need more resources. but somehow this looks as if the main problem is in the client (chrome) not on the server (nextcloud).

What in your experience is the fastest and most stable browser to use when many bookmarks, for floccus?

Additional context
11000 - 19000 bookmarks. Not totally sure, a partial sync into a browser, and then export to HTML file, shows that 19081 times the word 'http' is in the sourcecode of that HTML bookmarks file. However, the nextcloud web interface says 116... on https://.../index.php/apps/bookmarks/ so I guess that means 11600 (and the nextcloud webinterface code needs a small change). Is it possible that a bug in floccus, or due to over the limit errors ... that duplicate bookmarks got introduced when syncing?

Anyways, the above is more a selection of questions, and suspicions, than a clear feature request. It's half way to a bug report anyways. Sorry for that. Perhaps this is useful nevertheless.

Keep up the good work. Much appreciate floccus. Good job!

Originally created by @drandreaskrueger on GitHub (Jun 16, 2020). Original GitHub issue: https://github.com/floccusaddon/floccus/issues/572 What I already found out is this: floccus showed Error QUOTA_BYTES quota exceeded then I found this workaround for today: chrome --unlimited-storage **Suggestion** - Your floccus add-on can ask for permission to store more than 5 MB, read this https://developer.chrome.com/apps/offline_storage I keep an eye on the nextcloud server "htop" - which is fine; and on the chrome "task manager" which is at 150-250 CPU for a very long time now. What can I do with MANY bookmarks? --- **Is your feature request related to a problem? Please describe.** more than a decade of bookmarking ... **Describe the solution you'd like** either floccus or nextcloud is hitting some limits **Describe alternatives you've considered** reinstalling nextcloud but this time not via snap, because I read that snap causes programs to need more resources. but somehow this looks as if the main problem is in the client (chrome) not on the server (nextcloud). _What in your experience is the fastest and most stable browser to use when many bookmarks, for floccus?_ **Additional context** 11000 - 19000 bookmarks. Not totally sure, a partial sync into a browser, and then export to HTML file, shows that 19081 times the word 'http' is in the sourcecode of that HTML bookmarks file. However, the nextcloud web interface says 116... on https://.../index.php/apps/bookmarks/ so I guess that means 11600 (and the nextcloud webinterface code needs a small change). Is it possible that a bug in floccus, or due to over the limit errors ... that duplicate bookmarks got introduced when syncing? Anyways, the above is more a selection of questions, and suspicions, than a clear feature request. It's half way to a bug report anyways. Sorry for that. Perhaps this is useful nevertheless. Keep up the good work. Much appreciate floccus. Good job!
kerem 2026-02-25 22:37:02 +03:00
  • closed this issue
  • added the
    question
    label
Author
Owner

@marcelklehr commented on GitHub (Jun 16, 2020):

Thank you for your feedback! I do have heard from people having trouble with more than 10000 bookmarks.

QUOTA_BYTES quota exceeded

Ah, I will fix that. thanks for reporting.

What can I do with MANY bookmarks?

For many (read: ALOT of) bookmarks, I generally recommend using the webDAV sync method, because it uses much less network than syncing with the bookmarks app. However, in this case, your bookmarks won't show up in the web UI.

If you do want to stick with the bookmarks app, you might be happy to know that only the initial sync time is proportional to the amount of bookmarks you have, as floccus indexes them all and builds a cache. Once that is done, sync time is proportional to the amount of changes and their depth in the bookmarks tree. That way, if you have no changes, it shouldn't take more than a minute. Come to think about it, I do know about one bottleneck that could be improved further to speed up regular syncs.

reinstalling nextcloud but this time not via snap, because I read that snap causes programs to need more resources. but somehow this looks as if the main problem is in the client (chrome) not on the server (nextcloud).

This is unlikely to be the problem, although snap does have numerous disadvantages in my book :)

However, the nextcloud web interface says 116

The counting logic is rather new and there have been reports of it misbehaving, so, I wouldn't depend on it being accurate, atm.

duplicate bookmarks got introduced when syncing?

I have had reports of this in the past, but I think those issues should be sorted out now.

If you're up for a bit of debugging, you could try the addon inspector. This will tell you what floccus is up to (in the console tab) as well as the currently running network requests (in the network tab).

Firefox

  • Go to about:debugging
  • enable debugging
  • click on debug or Inspect button next to floccus entry

Chrome

  • Go to chrome://extensions
  • enable Developer mode
  • click on dist/html/background.html button in floccus' entry next to "Inspect views: "
<!-- gh-comment-id:644865486 --> @marcelklehr commented on GitHub (Jun 16, 2020): Thank you for your feedback! I do have heard from people having trouble with more than 10000 bookmarks. > QUOTA_BYTES quota exceeded Ah, I will fix that. thanks for reporting. > What can I do with MANY bookmarks? For many (read: ALOT of) bookmarks, I generally recommend using the webDAV sync method, because it uses much less network than syncing with the bookmarks app. However, in this case, your bookmarks won't show up in the web UI. If you do want to stick with the bookmarks app, you might be happy to know that only the initial sync time is proportional to the amount of bookmarks you have, as floccus indexes them all and builds a cache. Once that is done, sync time is proportional to the amount of changes and their depth in the bookmarks tree. That way, if you have no changes, it shouldn't take more than a minute. Come to think about it, I do know about one bottleneck that could be improved further to speed up regular syncs. > reinstalling nextcloud but this time not via snap, because I read that snap causes programs to need more resources. but somehow this looks as if the main problem is in the client (chrome) not on the server (nextcloud). This is unlikely to be the problem, although snap does have numerous disadvantages in my book :) > However, the nextcloud web interface says 116 The counting logic is rather new and there have been reports of it misbehaving, so, I wouldn't depend on it being accurate, atm. > duplicate bookmarks got introduced when syncing? I have had reports of this in the past, but I think those issues should be sorted out now. If you're up for a bit of debugging, you could try the addon inspector. This will tell you what floccus is up to (in the console tab) as well as the currently running network requests (in the network tab). #### Firefox * Go to `about:debugging` * enable debugging * click on `debug` or `Inspect` button next to floccus entry #### Chrome * Go to `chrome://extensions` * enable `Developer mode` * click on `dist/html/background.html` button in floccus' entry next to "Inspect views: "
Author
Owner

@drandreaskrueger commented on GitHub (Jun 17, 2020):

Fantastic, that is very valuable information. Thanks for the quick reply.

For many (read: ALOT of) bookmarks, I generally recommend using the webDAV sync method,

Great. So I should look into this, right? "XBEL file in WebDAV share"?

Is that a single file? Doesn't that mean that always the whole 2 MB have to be transferred? Is it still faster than the mysql nextcloud bookmarks app? What about concurrent read write attempts from different browsers? Is the XBEL file locked during one sync? Sorry for all the questions, is there s.th. I could read? Thanks.

your bookmarks won't show up in the web UI.

Hmmmm ... the few times I tried that, it was super slow. So that might not be a big loss.

If you do want to stick with the bookmarks app, you might be happy to know that only the initial sync time is proportional to the amount of bookmarks you have, as floccus indexes them all and builds a cache. Once that is done, sync time is proportional to the amount of changes and their depth in the bookmarks tree. That way, if you have no changes, it shouldn't take more than a minute.

Sounds good. One time time usage is no big problem.

Note: It is recommended to not enable native bookmark synchronization built into your browser, as it is known to cause issues.

Good to know. That had been my hope for syncing the bookmarks from my mobile browser. Enable a brave sync between mobile and desktop, and then do a floccus sync between desktop and cloud. Not a good idea? How else to get my mobile bookmarks off the android? (*) Thanks.
Actually, I could switch it on and off manually, right? Either brave sync or floccus sync. Would that work?

(*) this? https://play.google.com/store/apps/details?id=com.kiwibrowser.browser can it import existing bookmarks?

although snap does have numerous disadvantages in my book :)

Yes snap was great for a quick start. But I have already wiped it of the machine. Let's start again this time step by step, manually :-)

addon inspector.

Nice one. Didn't know it existed.

click on dist/html/background.html button in floccus' entry next to "Inspect views: "

found it. That will help. Thanks!

duplicate bookmarks

Using three different add ons, I could reduce the number of duplicates and dead sites by 10000. Now less than 9k bookmarks in total, should work better.

<!-- gh-comment-id:645164441 --> @drandreaskrueger commented on GitHub (Jun 17, 2020): Fantastic, that is very valuable information. Thanks for the quick reply. > For many (read: ALOT of) bookmarks, I generally recommend using the webDAV sync method, Great. So I should look into this, right? "XBEL file in WebDAV share"? Is that a single file? Doesn't that mean that always the whole 2 MB have to be transferred? Is it still faster than the mysql nextcloud bookmarks app? What about concurrent read write attempts from different browsers? Is the XBEL file locked during one sync? Sorry for all the questions, is there s.th. I could read? Thanks. > your bookmarks won't show up in the web UI. Hmmmm ... the few times I tried that, it was super slow. So that might not be a big loss. > If you do want to stick with the bookmarks app, you might be happy to know that only the initial sync time is proportional to the amount of bookmarks you have, as floccus indexes them all and builds a cache. Once that is done, sync time is proportional to the amount of changes and their depth in the bookmarks tree. That way, if you have no changes, it shouldn't take more than a minute. Sounds good. One time time usage is no big problem. > Note: It is recommended to not enable native bookmark synchronization built into your browser, as it is known to cause issues. Good to know. That had been my hope for syncing the bookmarks from my mobile browser. Enable a brave sync between mobile and desktop, and then do a floccus sync between desktop and cloud. Not a good idea? How else to get my mobile bookmarks off the android? (*) Thanks. Actually, I could switch it on and off manually, right? Either brave sync or floccus sync. Would that work? (*) this? https://play.google.com/store/apps/details?id=com.kiwibrowser.browser can it import existing bookmarks? > although snap does have numerous disadvantages in my book :) Yes snap was great for a quick start. But I have already wiped it of the machine. Let's start again this time step by step, manually :-) > addon inspector. Nice one. Didn't know it existed. > click on dist/html/background.html button in floccus' entry next to "Inspect views: " found it. That will help. Thanks! > duplicate bookmarks Using three different add ons, I could reduce the number of duplicates and dead sites by 10000. Now less than 9k bookmarks in total, should work better.
Author
Owner

@marcelklehr commented on GitHub (Jun 17, 2020):

Is that a single file? Doesn't that mean that always the whole 2 MB have to be transferred? Is it still faster than the mysql nextcloud bookmarks app? What about concurrent read write attempts from different browsers? Is the XBEL file locked during one sync? Sorry for all the questions, is there s.th. I could read? Thanks.

Yes, it's a single file and floccus employs a lock file mechanism. Usually even if the file is large (and we're talking about single digit megabytes here, so downloading that shouldn't take too long) this method is faster because you only have a fixed number of network requests and nearly no server-side computation.

Enable a brave sync between mobile and desktop, and then do a floccus sync between desktop and cloud. [...] Actually, I could switch it on and off manually, right?

Different browsers employ different native bookmark syncing mechanisms. Firefox is known to change bookmark ids when it syncs bookmarks, which causes trouble for floccus. Turning sync on and off will not fix this. I have no experience with other browsers' native sync, though. That message is more of a warning, i.e. if you want to try that, have backups (which you should always have when syncing anyway) and be prepared that things will break.

How else to get my mobile bookmarks off the android? (*) Thanks.

  • Install nextcloud bookmarks as a PWA on your phone (available in your browser menu)
  • Install the android nextcloud bookmarks app
  • Install kiwi browser and sync with floccus

(Also, on initial sync floccus will pull upstream bookmarks and merge them with what you have locally)

<!-- gh-comment-id:645372899 --> @marcelklehr commented on GitHub (Jun 17, 2020): > Is that a single file? Doesn't that mean that always the whole 2 MB have to be transferred? Is it still faster than the mysql nextcloud bookmarks app? What about concurrent read write attempts from different browsers? Is the XBEL file locked during one sync? Sorry for all the questions, is there s.th. I could read? Thanks. Yes, it's a single file and floccus employs a lock file mechanism. Usually even if the file is large (and we're talking about single digit megabytes here, so downloading that shouldn't take too long) this method is faster because you only have a fixed number of network requests and nearly no server-side computation. > Enable a brave sync between mobile and desktop, and then do a floccus sync between desktop and cloud. [...] Actually, I could switch it on and off manually, right? Different browsers employ different native bookmark syncing mechanisms. Firefox is known to change bookmark ids when it syncs bookmarks, which causes trouble for floccus. Turning sync on and off will not fix this. I have no experience with other browsers' native sync, though. That message is more of a warning, i.e. if you want to try that, have backups (which you should always have when syncing anyway) and be prepared that things will break. > How else to get my mobile bookmarks off the android? (*) Thanks. * Install nextcloud bookmarks as a PWA on your phone (available in your browser menu) * Install the android nextcloud bookmarks app * Install kiwi browser and sync with floccus (Also, on initial sync floccus will pull upstream bookmarks and merge them with what you have locally)
Author
Owner

@marcelklehr commented on GitHub (Jun 17, 2020):

Would you mind finding out with the instpector what exactly is taking so long? I have a theory.

<!-- gh-comment-id:645376135 --> @marcelklehr commented on GitHub (Jun 17, 2020): Would you mind finding out with the instpector what exactly is taking so long? I have a theory.
Author
Owner

@drandreaskrueger commented on GitHub (Jun 17, 2020):

Would you mind finding out with the ...

Oh I am sorry, I have purged that nextcloud installation. So for now the answer is: Sorry, no.

Once I have it up and running again (might take a while) I will try what I can find out for you.

<!-- gh-comment-id:645481217 --> @drandreaskrueger commented on GitHub (Jun 17, 2020): > Would you mind finding out with the ... Oh I am sorry, I have purged that nextcloud installation. So for now the answer is: Sorry, no. Once I have it up and running again (might take a while) I will try what I can find out for you.
Author
Owner

@drandreaskrueger commented on GitHub (Jun 17, 2020):

Firefox is known to change bookmark ids when it syncs bookmarks, which causes trouble for floccus.

Oh ouch, yes I can imagine that to be a source of trouble.

Idea: Floccus could perhaps ignore the "bookmark id" completely?

And instead use a hash of the whole bookmark (title and url and whatever else is stored) to identify whether that one bookmark is unchanged, or whether it needs syncing. And a hash of all hashes (or even a Merkle tree) could answer whether any bookmark had been changed since last sync.

Then firefox can change the id, with no effects.

<!-- gh-comment-id:645483437 --> @drandreaskrueger commented on GitHub (Jun 17, 2020): > Firefox is known to change bookmark ids when it syncs bookmarks, which causes trouble for floccus. Oh ouch, yes I can imagine that to be a source of trouble. Idea: Floccus could perhaps ignore the "bookmark id" completely? And instead use a hash of the whole bookmark (title and url and whatever else is stored) to identify whether that one bookmark is unchanged, or whether it needs syncing. And a hash of all hashes (or even a Merkle tree) could answer whether _any_ bookmark had been changed since last sync. Then firefox can change the id, with no effects.
Author
Owner

@drandreaskrueger commented on GitHub (Jun 17, 2020):

How else to get my mobile bookmarks off the android?

  • Install ...

thx for those instructions. Will try that.

<!-- gh-comment-id:645484178 --> @drandreaskrueger commented on GitHub (Jun 17, 2020): > > How else to get my mobile bookmarks off the android? > * Install ... thx for those instructions. Will try that.
Author
Owner

@marcelklehr commented on GitHub (Jun 17, 2020):

Idea: Floccus could perhaps ignore the "bookmark id" completely?
And instead use a hash of the whole bookmark (title and url and whatever else is stored) to identify whether that one bookmark is unchanged, or whether it needs syncing. And a hash of all hashes (or even a Merkle tree) could answer whether any bookmark had been changed since last sync.

Ah, yes. I'm already using Merkle trees for diffing. The IDs are important for moving items, though. Without those it's really difficult to tell where the user moved a folder, if that folder has also been changed.

<!-- gh-comment-id:645501666 --> @marcelklehr commented on GitHub (Jun 17, 2020): > Idea: Floccus could perhaps ignore the "bookmark id" completely? > And instead use a hash of the whole bookmark (title and url and whatever else is stored) to identify whether that one bookmark is unchanged, or whether it needs syncing. And a hash of all hashes (or even a Merkle tree) could answer whether any bookmark had been changed since last sync. Ah, yes. I'm already using Merkle trees for diffing. The IDs are important for moving items, though. Without those it's really difficult to tell where the user moved a folder, if that folder has also been changed.
Author
Owner

@drandreaskrueger commented on GitHub (Jun 17, 2020):

The IDs are important for moving items

instead also hash the folders perhaps?
Then a location in the tree can be expressed with a sequence of hashes (instead of that unreliable id)?

<!-- gh-comment-id:645524664 --> @drandreaskrueger commented on GitHub (Jun 17, 2020): > The IDs are important for moving items instead also hash the folders perhaps? Then a location in the tree can be expressed with a sequence of hashes (instead of that unreliable id)?
Author
Owner

@marcelklehr commented on GitHub (Jun 17, 2020):

instead also hash the folders perhaps?

What happens if the folder contents have changed? I still want to move that folder even if its name and contents have changed.

<!-- gh-comment-id:645525851 --> @marcelklehr commented on GitHub (Jun 17, 2020): > instead also hash the folders perhaps? What happens if the folder contents have changed? I still want to move that folder even if its name and contents have changed.
Author
Owner

@drandreaskrueger commented on GitHub (Jun 18, 2020):

not sure I understand what you mean by "move".

What happens if the folder contents have changed? I still want to move that folder even if its name and contents have changed.

difficult to tell where the user moved a folder, if that folder has also been changed.

Why not let it "disappear" (i.e. delete) at location A, and "create" a completely new branch in location B? At some level of user changes, giving up on tracking all of them might be easier, no?

But sorry for the curious questions, you are the expert on your software, I just had some ideas - but all based on my dangerous half-knowledge. So don't get distracted by me ;-) You will know what's best.

Thanks for your amazing responsiveness, hope my feedback was valuable somehow.

<!-- gh-comment-id:645864360 --> @drandreaskrueger commented on GitHub (Jun 18, 2020): not sure I understand what you mean by "move". > What happens if the folder contents have changed? I still want to move that folder even if its name and contents have changed. > difficult to tell where the user moved a folder, if that folder has also been changed. Why not let it "disappear" (i.e. delete) at location A, and "create" a completely new branch in location B? At some level of user changes, giving up on tracking all of them might be easier, no? But sorry for the curious questions, you are the expert on your software, I just had some ideas - but all based on my dangerous half-knowledge. So don't get distracted by me ;-) You will know what's best. Thanks for your amazing responsiveness, hope my feedback was valuable somehow.
Author
Owner

@github-actions[bot] commented on GitHub (Mar 21, 2023):

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

<!-- gh-comment-id:1477197825 --> @github-actions[bot] commented on GitHub (Mar 21, 2023): This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/floccus#402
No description provided.