starred/karakeep

Fork 0

mirror of https://github.com/karakeep-app/karakeep.git synced 2026-04-24 23:46:06 +03:00

[GH-ISSUE #2502] Saving a page that was previously saved fails #1498

New issue

Open

opened 2026-03-02 11:57:41 +03:00 by kerem · 4 comments

kerem commented

2026-03-02 11:57:41 +03:00

Owner

Originally created by @Garrett-R on GitHub (Feb 22, 2026).
Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/2502

Describe the Bug

If you saved a page in the past, you can't save it again.

Steps to Reproduce

Install the Firefox extension
Go to a Youtube video and hit the extension icon to save
Go to Karakeep
Archive the item
Go back to the Youtube video and hit the extension to save it again
Observe it implies it worked:

Expected Behaviour

It should appear in my bookmarks again (https://cloud.karakeep.app/dashboard/bookmarks), but it does not.

In other words, it should be unarchived and moved to the top of bookmarks. That's how Pocket worked IIRC. With the current behavior, I think most people will think it's just a bug and Karakeep is not saving it successfully.

Screenshots or Additional Context

No response

Device Details

Firefox 147.0.3 on Ubuntu 22.04.1

Exact Karakeep Version

Karakeep Cloud; and FF extension v1.2.7

Environment Details

No response

Debug Logs

No response

Have you checked the troubleshooting guide?

I have checked the troubleshooting guide and I haven't found a solution to my problem

Originally created by @Garrett-R on GitHub (Feb 22, 2026). Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/2502 ### Describe the Bug If you saved a page in the past, you can't save it again. ### Steps to Reproduce 1. Install the Firefox extension 2. Go to a Youtube video and hit the extension icon to save 3. Go to Karakeep 4. Archive the item 5. Go back to the Youtube video and hit the extension to save it again 6. Observe it implies it worked: <img width="511" height="638" alt="Image" src="https://github.com/user-attachments/assets/7c2306f5-f0b0-4855-8763-ed3e5f558088" /> ### Expected Behaviour It should appear in my bookmarks again (https://cloud.karakeep.app/dashboard/bookmarks), but it does not. In other words, it should be unarchived and moved to the top of bookmarks. That's how Pocket worked IIRC. With the current behavior, I think most people will think it's just a bug and Karakeep is not saving it successfully. ### Screenshots or Additional Context _No response_ ### Device Details Firefox 147.0.3 on Ubuntu 22.04.1 ### Exact Karakeep Version Karakeep Cloud; and FF extension v1.2.7 ### Environment Details _No response_ ### Debug Logs _No response_ ### Have you checked the troubleshooting guide? - [x] I have checked the troubleshooting guide and I haven't found a solution to my problem

kerem added the

status/approved

pri/medium

UI/UX

labels

2026-03-02 11:57:41 +03:00

kerem commented

2026-03-02 11:57:42 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Feb 22, 2026):

hmmm, I feel like this is more of a UX question rather than a bug. Archived is not "deleted". Archive means hide from the homepage. In the mobile app, you'll get an "Already Hoarded" message, instead of just "Hoarded", which will indicate to you that it's already in your library, maybe that's what we need to do in the extension?

I can see the argument about un-archiving a page on re-addition though, the other caveat is, the createdAt timestamp wouldn't change, so it'd still not appear in your grid if immediately if you have newer bookmarks saved. Updating createdAt sounds wrong though, how would you expect this to be behave?

@MohamedBassem commented on GitHub (Feb 22, 2026): hmmm, I feel like this is more of a UX question rather than a bug. Archived is not "deleted". Archive means hide from the homepage. In the mobile app, you'll get an "Already Hoarded" message, instead of just "Hoarded", which will indicate to you that it's already in your library, maybe that's what we need to do in the extension? I can see the argument about un-archiving a page on re-addition though, the other caveat is, the `createdAt` timestamp wouldn't change, so it'd still not appear in your grid if immediately if you have newer bookmarks saved. Updating `createdAt` sounds wrong though, how would you expect this to be behave?

kerem commented

2026-03-02 11:57:42 +03:00

Author

Owner

@Garrett-R commented on GitHub (Feb 22, 2026):

True, good points.

Yeah, I guess the behavior of "unarchive and move to top" (Pocket behavior) could have some people not happy about that. So in either case, it's possible to have people wishing it was the other way.

But I do still think a change is merited. This only impacts you when you re-bookmark an item, I see little risk in Pocket-style behavior.

with "Current Karakeep" behavior:
- if someone rebookmarks and then next day notices the bookmark is not there, there's a good chance they'll think it's a Karakeep bug (even if unfairly). They may or may not remember that they had previously bookmarked it.
- for weeks, I thought Karakeep was just bugging out and bookmarking was janky until I realized that maybe those were all re-bookmarks
with "Pocket" behavior:
- only risk here is someone re-bookmarks and then is unhappy to see it reappear in bookmarks, but then I wonder why they would be using re-bookmark in the first place, seems like not much use-case for "re-bookmarking to keep it in the archive [aka no-op]". I guess perhaps they could just making extra sure it's in the archive, but that seems like an unlikely use case.

Updating createdAt sounds wrong though, how would you expect this to be behave?

True, once a row in DB is created, its createdAt should probably never be updated. I guess 2 solutions could:

the same item can be bookmarked twice (2 different DB rows)
add a new field like lastSavedAt or something

In any case, the implementation details probably shouldn't be part of the Product/UX decision (since there's ways to get it to work as desired, whatever that desired behavior is).

@Garrett-R commented on GitHub (Feb 22, 2026): True, good points. Yeah, I guess the behavior of "unarchive and move to top" (Pocket behavior) could have some people not happy about that. So in either case, it's possible to have people wishing it was the other way. But I do still think a change is merited. This only impacts you when you re-bookmark an item, I see little risk in Pocket-style behavior. - with "Current Karakeep" behavior: - if someone rebookmarks and then next day notices the bookmark is not there, there's a good chance they'll think it's a Karakeep bug (even if unfairly). They may or may not remember that they had previously bookmarked it. - for weeks, I thought Karakeep was just bugging out and bookmarking was janky until I realized that maybe those were all re-bookmarks - with "Pocket" behavior: - only risk here is someone re-bookmarks and then is unhappy to see it reappear in bookmarks, but then I wonder why they would be using re-bookmark in the first place, seems like not much use-case for "re-bookmarking to keep it in the archive [aka no-op]". I guess perhaps they could just making extra sure it's in the archive, but that seems like an unlikely use case. > Updating createdAt sounds wrong though, how would you expect this to be behave? True, once a row in DB is created, its `createdAt` should probably never be updated. I guess 2 solutions could: 1. the same item can be bookmarked twice (2 different DB rows) 2. add a new field like `lastSavedAt` or something In any case, the implementation details probably shouldn't be part of the Product/UX decision (since there's ways to get it to work as desired, whatever that desired behavior is).

kerem commented

2026-03-02 11:57:42 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Feb 23, 2026):

@Garrett-R ok, I'm convinced :) I'll implement it.

@MohamedBassem commented on GitHub (Feb 23, 2026): @Garrett-R ok, I'm convinced :) I'll implement it.

kerem commented

2026-03-02 11:57:42 +03:00

Author

Owner

@Garrett-R commented on GitHub (Feb 23, 2026):

Woohoo, awesome! Loving this project BTW 😎

@Garrett-R commented on GitHub (Feb 23, 2026): Woohoo, awesome! Loving this project BTW 😎

kerem referenced this issue

2026-03-02 11:59:27 +03:00

[PR #1498] [CLOSED] fix: Update docker development environment with automatic database migrations #1847

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/karakeep#1498

No description provided.

Rows
Columns