Icon badge color does not reflect query parameters.

[dragonmaus]

If I have a bookmark with one or more query parameters, and navigate to a different page where only the query is different, the icon badge will remain dark blue, indicating that bukubrow thinks the current page is bookmarked.

This is especially common when managing webcomics, as many sites use query parameters to indicate the current comic page.

Screenshot below. I overlaid an example of the "same domain, different URL" badge (green arrow), to show the contrast:

[samhh]

The trouble here is that other websites can use query params constantly, essentially invalidating your ability to ever match the page URL.

I'll leave the issue open for further feedback.

[dragonmaus]

Ah, yes. I can see how that would be an issue.

I'm sure there are all sorts of (terrible) ways to work around this dichotomy, but I'll leave those as an exercise to the reader; no need to muddy the waters here.

[LeXofLeviafan]

On one hand it does make sense to highlight it, on the other this is precisely what the light-blue badge is for. (…You could also pick a different shade of blue to indicate "bookmarked but not quite" :-D)

I would, however, argue that only exactly-matching URLs should be considered as such, in part because both URL parameters and hash can be used for identifying individual pages (e.g. apps with non-RESTful URL schemas would use parameters like ?id=foo to specify the page, and single-page apps can very well just use hash-routing: #!/foo/bar/baz).

Case in point – I've just encountered a rather bothersome issue: since only the base URL is ever considered when matching a bookmark, it turns out that not only does it match all bookmarks sharing the same base URL, but I also have to look through all of them to see if the current page is actually bookmarked or not (because the bookmark that matches the current URL exactly isn't at the top of the list where I expect it to be, regardless of how many are highlighted dark-blue).

[LeXofLeviafan]

both URL parameters and hash can be used for identifying individual pages (e.g. apps with non-RESTful URL schemas would use parameters like ?id=foo to specify the page, and single-page apps can very well just use hash-routing: #!/foo/bar/baz)

Example for the former: DHL shipment tracking page uses URL query parameters (such as &tracking-id=…) for identifying parcels; and pages with the same base URL but different tracking ID would have different content, so it certainly makes more sense to consider them different pages when identifying bookmarks.

As for the latter – hostings such as web.app (used for hosting Firebase web-apps) or neocities only have basic HTTP servers with no extra tweaking (AFAIK), so if one wants routing they have to use URL hash for it.

…Oh, and now that I think about it – this behaviour (using exact URL to match a bookmark, parameters & hash included) is consistent with built-in browser bookmarks, too.

[LeXofLeviafan]

…Just checked the behaviour of bookmarklet handler in buku repo – it also does exact matching to detect if the URL exists in DB, same as builtin browser bookmarks functionality.