[GH-ISSUE #944] Sorting of ignored bookmarks #615

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

Originally created by @misterhsp on GitHub (Aug 19, 2021).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/944

Describe the bug

I removed floccus again because it regularly messes up my bookmark sorting. Doesn't work at all like that.

To Reproduce

none

Expected behavior

none

Screenshots

none

..........

Originally created by @misterhsp on GitHub (Aug 19, 2021). Original GitHub issue: https://github.com/floccusaddon/floccus/issues/944 ### Describe the bug I removed floccus again because it regularly messes up my bookmark sorting. Doesn't work at all like that. ### To Reproduce none ### Expected behavior none ### Screenshots none ..........
kerem 2026-02-25 22:37:38 +03:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@marcelklehr commented on GitHub (Aug 23, 2021):

Hi @misterhsp
I cannot reproduce your issue.

I have here an example of steps I have taken to try and get the sorting out of sync, which failed. The sorting is always in sync.

Peek 2021-08-23 21-14

If you can, please share a similar step-by-step guide to reproduce your issue.

<!-- gh-comment-id:904049904 --> @marcelklehr commented on GitHub (Aug 23, 2021): Hi @misterhsp I cannot reproduce your issue. I have here an example of steps I have taken to try and get the sorting out of sync, which failed. The sorting is always in sync. ![Peek 2021-08-23 21-14](https://user-images.githubusercontent.com/986878/130504713-09f9ef54-82a2-47ae-9c7e-621209818a22.gif) If you can, please share a similar step-by-step guide to reproduce your issue.
Author
Owner

@Veazer commented on GitHub (Sep 2, 2021):

I am also seeing re-ordering with non-http bookmarks. For example, my Bookmarks bar is almost entirely folders full of bookmarks but I have three bookmarks on the Bookmarks bar as well, i.e.:

[bookmark] [bookmark] [bookmark] [folder] [folder] [folder] [folder] [folder] [folder] [folder] [folder] [folder]

The three non-folder bookmarks are:
chrome://apps
chrome://bookmarks
https://docs.google.com/document/d/xxxxxx (A Google doc I use as a scratchpad)

If I move theses three links to the beginning/left of the bookmark bar and execute a sync, the chrome:// urls will move to the right end but the Google Doc will stay in place.

<!-- gh-comment-id:910968695 --> @Veazer commented on GitHub (Sep 2, 2021): I am also seeing re-ordering with non-http bookmarks. For example, my Bookmarks bar is almost entirely folders full of bookmarks but I have three bookmarks on the Bookmarks bar as well, i.e.: [bookmark] [bookmark] [bookmark] [folder] [folder] [folder] [folder] [folder] [folder] [folder] [folder] [folder] The three non-folder bookmarks are: chrome://apps chrome://bookmarks https://docs.google.com/document/d/xxxxxx (A Google doc I use as a scratchpad) If I move theses three links to the beginning/left of the bookmark bar and execute a sync, the chrome:// urls will move to the right end but the Google Doc will stay in place.
Author
Owner

@marcelklehr commented on GitHub (Sep 2, 2021):

@Veazer Thank you for the feedback! That makes sense indeed, as non-http bookmarks aren't synced. I'll see what I can do!

<!-- gh-comment-id:911124838 --> @marcelklehr commented on GitHub (Sep 2, 2021): @Veazer Thank you for the feedback! That makes sense indeed, as non-http bookmarks aren't synced. I'll see what I can do!
Author
Owner

@mnalis commented on GitHub (Sep 2, 2021):

That makes sense indeed, as non-http bookmarks aren't synced. I'll see what I can do!

@marcelklehr oh, I wasn't aware of that. So only http: and https: protocols are synced (and ftp: maybe)? None of bookmarkets (javascript:) gets synced? That is a shame, I would really like them to be synced too...

Would it be possible to implement? If not, maybe at least put a notice in account status window like 20 non-http URLs were ignored), and mention this limitation in add-on description (as it is much nicer to find about it beforehand, than if one has to restore bookmarks and only then find some of them are gone).

<!-- gh-comment-id:911711886 --> @mnalis commented on GitHub (Sep 2, 2021): > That makes sense indeed, as non-http bookmarks aren't synced. I'll see what I can do! @marcelklehr oh, I wasn't aware of that. So only `http:` and `https:` protocols are synced (and `ftp:` maybe)? None of bookmarkets (`javascript:`) gets synced? That is a shame, I would really like them to be synced too... Would it be possible to implement? If not, maybe at least put a notice in account status window like `20 non-http URLs were ignored`), and mention this limitation in add-on description (as it is much nicer to find about it beforehand, than if one has to restore bookmarks and only then find some of them are gone).
Author
Owner

@Veazer commented on GitHub (Sep 2, 2021):

None of bookmarkets (javascript:) gets synced? That is a shame, I would really like them to be synced too...

I would also like to see them synced. IMHO it makes more sense to have synced bookmarks that aren't usable (like chrome:// urls on Firefox) rather than have them discarded without notification. I'm using chromium based browsers on desktop and mobile, so my urls are fully usable on all platforms. Kiwi browser on Android supports chrome:// urls and javascript: urls.

On unsupported browsers, it would also be possible to convert the non http/https URLs to instead go to local error pages that explain why they are non-functional. This way they would still be present and not break syncing.

<!-- gh-comment-id:912007686 --> @Veazer commented on GitHub (Sep 2, 2021): > None of bookmarkets (javascript:) gets synced? That is a shame, I would really like them to be synced too... I would also like to see them synced. IMHO it makes more sense to have synced bookmarks that aren't usable (like `chrome://` urls on Firefox) rather than have them discarded without notification. I'm using chromium based browsers on desktop and mobile, so my urls are fully usable on all platforms. Kiwi browser on Android supports `chrome://` urls and` javascript:` urls. On unsupported browsers, it would also be possible to convert the non http/https URLs to instead go to local error pages that explain why they are non-functional. This way they would still be present and not break syncing.
Author
Owner

@marcelklehr commented on GitHub (Sep 3, 2021):

To be precise, when syncing with WebDAV, floccus accepts 'https:', 'http:', 'ftp:', 'data:', 'javascript:', while Nextcloud Bookmarks currently only accepts http(s). There's an issue open for javascript URLs, though.

On unsupported browsers, it would also be possible to convert the non http/https URLs to instead go to local error pages that explain why they are non-functional.

That would entail making sure the converted URL is not synced back up, so is non-trivial, but I agree that this would be a nice solution. Alas, there's no shortage of improvements to take care of :D

<!-- gh-comment-id:912322211 --> @marcelklehr commented on GitHub (Sep 3, 2021): To be precise, when syncing with WebDAV, floccus accepts `'https:', 'http:', 'ftp:', 'data:', 'javascript:'`, while Nextcloud Bookmarks currently only accepts http(s). There's an issue open for javascript URLs, though. > On unsupported browsers, it would also be possible to convert the non http/https URLs to instead go to local error pages that explain why they are non-functional. That would entail making sure the converted URL is not synced back up, so is non-trivial, but I agree that this would be a nice solution. Alas, there's no shortage of improvements to take care of :D
Author
Owner

@mnalis commented on GitHub (Sep 3, 2021):

Thanks for the info @marcelklehr, it might be worth noting in add-on details perhaps? It would influence my choice of backend, so perhaps for others it might too.

BTW ftp:// also seems to work with nextcloud bookmarks (at least in v4.4.1 it seem to work)

<!-- gh-comment-id:912600953 --> @mnalis commented on GitHub (Sep 3, 2021): Thanks for the info @marcelklehr, it might be worth noting in add-on details perhaps? It would influence my choice of backend, so perhaps for others it might too. BTW `ftp://` also seems to work with nextcloud bookmarks (at least in `v4.4.1` it seem to work)
Author
Owner

@Veazer commented on GitHub (Sep 3, 2021):

That would entail making sure the converted URL is not synced back up, so is non-trivial...

Another problem I considered: it would break manual bookmark exports on platforms with "translated" bookmarks. It's probaby more trouble than it is worth.

I'd rather just have non-crossbrowser URLs (chrome://) synced as-is - even if they don't work on all of my browsers.

<!-- gh-comment-id:912827905 --> @Veazer commented on GitHub (Sep 3, 2021): > That would entail making sure the converted URL is not synced back up, so is non-trivial... Another problem I considered: it would break manual bookmark exports on platforms with "translated" bookmarks. It's probaby more trouble than it is worth. I'd rather just have non-crossbrowser URLs (`chrome://`) synced as-is - even if they don't work on all of my browsers.
Author
Owner

@mnalis commented on GitHub (Sep 3, 2021):

I agree with @Veazer, I too don't mind if special URLs bookmarked on Chromium won't work on Firefox, and that they won't show nice error message if opened.

I just want them to be safely synced (so when I for exapmle reinstall the machine and resync, I have exactly the same bookmarks as I had before, instead of many of them lost)

<!-- gh-comment-id:912842409 --> @mnalis commented on GitHub (Sep 3, 2021): I agree with @Veazer, I too don't mind if special URLs bookmarked on Chromium won't work on Firefox, and that they won't show nice error message if opened. I just want them to be safely synced (so when I for exapmle reinstall the machine and resync, I have exactly the same bookmarks as I had before, instead of many of them lost)
Author
Owner

@marcelklehr commented on GitHub (Sep 4, 2021):

The reason they are not synced is not just that they don't work, but that they are not accepted by other browsers -- the sync run would fail. Still, it's possible to just not add them on the respective browsers. This would then definitely kill this ticket as won't fix, though.

<!-- gh-comment-id:912877322 --> @marcelklehr commented on GitHub (Sep 4, 2021): The reason they are not synced is not just that they don't work, but that they are not accepted by other browsers -- the sync run would fail. Still, it's possible to just not add them on the respective browsers. This would then definitely kill *this* ticket as won't fix, though.
Author
Owner

@mnalis commented on GitHub (Sep 4, 2021):

Oh, failing sync would be bad, indeed. But if one has to choose between loosing bookmarks completely or loosing just their sort order, I would think the later is to be preferred.

But perhaps you can munge/demunge those browser-specific URLs if the browser does not support them and would barf on them? I don't know how much complexity that would bring in, though...

For example, chromium might upload chrome://apps to WebDAV, but when trying to sync that bookmark to Firefox, instead of dropping it, it might become instead https://floccus.org/fake_url/chrome%3A%2F%2Fapps. (It could even be clickable and display the explanation if user tries to open it on Firefox! Or you might use non-existent subdomain like https://fakeurl.floccus.org/... if you do not want that kind of traffic, where clicking it would just return regular can't connect error)

The same thing in reverse: when syncing up bookmarks, if URL starts with https://floccus.org/fake_url/, it would just urldecode original URL and sync that instead. So when in example above Firefox would like to sync back that https://floccus.org/fake_url/chrome%3A%2F%2Fapps it would detect that and sync chrome://apps to WebDAV instead.

<!-- gh-comment-id:913045957 --> @mnalis commented on GitHub (Sep 4, 2021): Oh, failing sync would be bad, indeed. But if one has to choose between loosing bookmarks completely _or_ loosing just their sort order, I would think the later is to be preferred. But perhaps you can munge/demunge those browser-specific URLs if the browser does not support them and would barf on them? I don't know how much complexity that would bring in, though... For example, chromium might upload `chrome://apps` to WebDAV, but when trying to sync that bookmark to Firefox, instead of dropping it, it might become instead `https://floccus.org/fake_url/chrome%3A%2F%2Fapps`. (It could even be clickable and display the explanation if user tries to open it on Firefox! Or you might use non-existent subdomain like `https://fakeurl.floccus.org/...` if you do not want that kind of traffic, where clicking it would just return regular `can't connect` error) The same thing in reverse: when syncing up bookmarks, if URL starts with `https://floccus.org/fake_url/`, it would just urldecode original URL and sync that instead. So when in example above Firefox would like to sync back that `https://floccus.org/fake_url/chrome%3A%2F%2Fapps` it would detect that and sync `chrome://apps` to WebDAV instead.
Author
Owner

@Veazer commented on GitHub (Sep 5, 2021):

marcelklehr wrote:

The reason they are not synced is not just that they don't work, but that they are not accepted by other browsers -- the sync run would fail. Still, it's possible to just not add them on the respective browsers. This would then definitely kill this ticket as won't fix, though.

Can the plugin be written to ignore URLs that aren't supported? For example, can't the Firefox version of the extension just drop chrome:// URLs when pulling bookmarks from the sync destination to the local bookmarks, but leave them in the sync destination? I understand this probably wouldn't work for a push sync because that is just making the sync destination an exact copy of the local bookmarks, which would lack the chrome:// urls.

mnalis wrote:

For example, chromium might upload chrome://apps to WebDAV, but when trying to sync that bookmark to Firefox, instead of dropping it, it might become instead https://floccus.org/fake_url/chrome%3A%2F%2Fapps.

This is essentially what I had suggested, though the translated URL would be handled by the extension, like chrome-extension://fnaicdffflnofjppbagibeoednhnbjhg/dist/html/unsupported-url/chrome%3A%2F%2Fmedia-internals%2F Ultimately I think it would be better if they were just hidden.

<!-- gh-comment-id:913087092 --> @Veazer commented on GitHub (Sep 5, 2021): **marcelklehr wrote:** > The reason they are not synced is not just that they don't work, but that they are not accepted by other browsers -- the sync run would fail. Still, it's possible to just not add them on the respective browsers. This would then definitely kill _this_ ticket as won't fix, though. Can the plugin be written to ignore URLs that aren't supported? For example, can't the Firefox version of the extension just drop `chrome://` URLs when pulling bookmarks from the sync destination to the local bookmarks, but leave them in the sync destination? I understand this probably wouldn't work for a push sync because that is just making the sync destination an exact copy of the local bookmarks, which would lack the `chrome://` urls. **mnalis wrote:** > For example, chromium might upload chrome://apps to WebDAV, but when trying to sync that bookmark to Firefox, instead of dropping it, it might become instead https://floccus.org/fake_url/chrome%3A%2F%2Fapps. This is essentially what I had suggested, though the translated URL would be handled by the extension, like `chrome-extension://fnaicdffflnofjppbagibeoednhnbjhg/dist/html/unsupported-url/chrome%3A%2F%2Fmedia-internals%2F` Ultimately I think it would be better if they were just hidden.
Author
Owner

@misterhsp commented on GitHub (Sep 24, 2021):

Is the problem fixed in 4.8? If so, I would make another attempt with floccus.

....

<!-- gh-comment-id:926519329 --> @misterhsp commented on GitHub (Sep 24, 2021): Is the problem fixed in 4.8? If so, I would make another attempt with floccus. ....
Author
Owner

@marcelklehr commented on GitHub (Sep 24, 2021):

Is the problem fixed in 4.8?

It is not, sorry. I've been focusing on the android app. But I think it would be doable to ignore browser-unsupported bookmarks client-side, so they are both a) not deleted from the server and b) not added on the client.

So, actionable items:

  • UI: Make it more clear which URL types are supported per adapter
  • Ignore actions involving URLs not supported by the current browser.

Do we know which URLs schemes those are? Which browser can handle which scheme? That would be good to find out, before tackling this.

<!-- gh-comment-id:926690866 --> @marcelklehr commented on GitHub (Sep 24, 2021): > Is the problem fixed in 4.8? It is not, sorry. I've been focusing on the android app. But I think it would be doable to ignore browser-unsupported bookmarks client-side, so they are both a) not deleted from the server and b) not added on the client. So, actionable items: - [x] UI: Make it more clear which URL types are supported per adapter - [ ] Ignore actions involving URLs not supported by the current browser. Do we know which URLs schemes those are? Which browser can handle which scheme? That would be good to find out, before tackling this.
Author
Owner

@github-actions[bot] commented on GitHub (Mar 20, 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:1476306098 --> @github-actions[bot] commented on GitHub (Mar 20, 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#615
No description provided.