[GH-ISSUE #1220] FR: [bounty $50] support for highlights on android

kerem commented

2026-03-02 11:52:46 +03:00

Owner

Originally created by @thiswillbeyourgithub on GitHub (Apr 8, 2025).
Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1220

Describe the feature you'd like

Hi!

Karakeep was very promising last time I checked but now is clearly awesome!

I am still missing one crucial feature for my workflow: the ability to create new highlights on android. I am willing to bounty $50 to whoever pulls this off :)

As far as I am concerned, to earn the bounty, this can be either from the android app or the browser, including in "desktop mode" of the android browser. I also can accept minimal highlights like only text highlights, no color selectors, no area highlighter etc.

Also I was surprised to not find any issue already tracking this feature, I apologize if it exists already but I couldn't find it in issues, PR nor discussions.

Describe the benefits this would bring to existing Hoarder users

A way to enjoy all features of karakeep from your phone or tablet
A real alternative to the good old omnivore.
A usable setup for users that want to hoard highlights instead of mostly static documents.

Can the goal of this request already be achieved via other means?

No, I tried adding highlights from the android app, from the brave browser, and from the brave browser with desktop mode enabled.

Have you searched for an existing open/closed issue?

I have searched for existing issues and none cover my fundamental request

Additional context

Sort of related to #620 and #1014

Originally created by @thiswillbeyourgithub on GitHub (Apr 8, 2025). Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1220 ### Describe the feature you'd like Hi! Karakeep was very promising last time I checked but now is clearly awesome! I am still missing one crucial feature for my workflow: the ability to create new highlights on android. I am willing to bounty $50 to whoever pulls this off :) As far as I am concerned, to earn the bounty, this can be either from the android app or the browser, including in "desktop mode" of the android browser. I also can accept minimal highlights like only text highlights, no color selectors, no area highlighter etc. Also I was surprised to not find any issue already tracking this feature, I apologize if it exists already but I couldn't find it in issues, PR nor discussions. ### Describe the benefits this would bring to existing Hoarder users - A way to enjoy all features of karakeep from your phone or tablet - A real alternative to the good old omnivore. - A usable setup for users that want to hoard highlights instead of mostly static documents. ### Can the goal of this request already be achieved via other means? No, I tried adding highlights from the android app, from the brave browser, and from the brave browser with desktop mode enabled. ### Have you searched for an existing open/closed issue? - [x] I have searched for existing issues and none cover my fundamental request ### Additional context Sort of related to #620 and #1014

kerem

2026-03-02 11:52:46 +03:00

closed this issue
added the
feature request

status/untriaged
labels

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@Mxrk commented on GitHub (Apr 13, 2025):

As I would also like to have this feature, I found a good fix which also supports mobile browsers:

https://github.com/user-attachments/assets/a7d8ecd8-84d4-4652-8bfc-40157fb5a412

I will check if that’s enough and won’t break anything else, but seems working so far. Is this how it should be on mobile or would you prefer something else?

@Mxrk commented on GitHub (Apr 13, 2025): As I would also like to have this feature, I found a good fix which also supports mobile browsers: https://github.com/user-attachments/assets/a7d8ecd8-84d4-4652-8bfc-40157fb5a412 I will check if that’s enough and won’t break anything else, but seems working so far. Is this how it should be on mobile or would you prefer something else?

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@thiswillbeyourgithub commented on GitHub (Apr 13, 2025):

Hi!

Thanks for the reply. I'm not sure I understood. Did you find a workaround to make the highlighting work from android or did you code it yourself? I do believe it is fair that only the latter qualifies for the bounty. We can debate this of course!

Regarding the video example: it seems alright but on android I don't know if the fact that it highlights the text right away is the way to go, normally there is a contextual menu that appears so we can copy the text, do a web search on it etc. Would we be losing that if we added your fix?

And to clarify, it does work on the android app as well as on the browser, correct?

FYI I have a track record of being honest in my bounties, see that one for example

edit: oh I didn't see you were a contributor, then you probably coded it I guess?

@thiswillbeyourgithub commented on GitHub (Apr 13, 2025): Hi! Thanks for the reply. I'm not sure I understood. Did you find a workaround to make the highlighting work from android or did you code it yourself? I do believe it is fair that only the latter qualifies for the bounty. We can debate this of course! Regarding the video example: it seems alright but on android I don't know if the fact that it highlights the text right away is the way to go, normally there is a contextual menu that appears so we can copy the text, do a web search on it etc. Would we be losing that if we added your fix? And to clarify, it does work on the android app as well as on the browser, correct? FYI I have a track record of being honest in my bounties, [see that one for example](https://github.com/thiswillbeyourgithub/SleepTk_pinetime_sleep_tracker/issues/15) edit: oh I didn't see you were a contributor, then you probably coded it I guess?

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@thiswillbeyourgithub commented on GitHub (Apr 18, 2025):

Hi @Mxrk any update on this?

@thiswillbeyourgithub commented on GitHub (Apr 18, 2025): Hi @Mxrk any update on this?

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@Mxrk commented on GitHub (Apr 19, 2025):

Hi @Mxrk any update on this?

Yeah, it needs UI updates as it seems buggy in certain scenarios. So no, I don't have a complete solution. I will add my current knowledge and ideas soonish as it could need some discussion with others.

@Mxrk commented on GitHub (Apr 19, 2025): > Hi @Mxrk any update on this? Yeah, it needs UI updates as it seems buggy in certain scenarios. So no, I don't have a complete solution. I will add my current knowledge and ideas soonish as it could need some discussion with others.

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@Mxrk commented on GitHub (Apr 20, 2025):

First off, why doesn't this feature work on mobile? Currently inside BookmarkHtmlHighlighter.tsx we can see the following line:

github.com/karakeep-app/karakeep@1d9fc9bbd3/apps/web/components/dashboard/preview/BookmarkHtmlHighlighter.tsx (L336)

onMouseUp doesn't perfectly work on mobile and is easily fixable using onPointerUp. This introduces some other nitpicks but it seems to be working fine on the devices and emulators I tested, at least to trigger the current highlight menu. I know that some browsers have internal fixes to support mouseup but pointer is probably the way to go.

Now the current "problem" where I need input. On mobile we always have the native context menu popping up above the selected text on iOS and android (maybe there are some android versions where it's somewhere else but most have it above). Easy fix would be to either move the highlight menu above the context menu, or below the selected text. I have implemented the same feature in another app and there was no problem with having it below - but it could maybe lead to accessibility issues. Besides that, we would also have to adjust the web UI or simply have that it opens above on web and below on mobile. Or keep it for both, but again - would be a design change.
We could also just block the whole context menu but this seems weird and I don't think this is the way to go.

Another idea would be to have an icon in the menu bar. This would add a new design element and would change the design for mobile and web, not sure if that's too much. In general the apps also have other possibilities, but (again) not sure if that's something we should aim for as the design would greatly differ to the web version.

Maybe there are also other ideas I didn't think about yet.

@Mxrk commented on GitHub (Apr 20, 2025): First off, why doesn't this feature work on mobile? Currently inside [BookmarkHtmlHighlighter.tsx](https://github.com/karakeep-app/karakeep/blob/1d9fc9bbd3b83c9bcde6374b3620abcbb82108ae/apps/web/components/dashboard/preview/BookmarkHtmlHighlighter.tsx#L336) we can see the following line: https://github.com/karakeep-app/karakeep/blob/1d9fc9bbd3b83c9bcde6374b3620abcbb82108ae/apps/web/components/dashboard/preview/BookmarkHtmlHighlighter.tsx#L336 `onMouseUp` doesn't perfectly work on mobile and is easily fixable using [onPointerUp](https://developer.mozilla.org/en-US/docs/Web/API/Element/pointerup_event). This introduces some other nitpicks but it seems to be working fine on the devices and emulators I tested, at least to trigger the current highlight menu. I know that some browsers have internal fixes to support mouseup but pointer is probably the way to go. Now the current "problem" where I need input. On mobile we always have the native context menu popping up above the selected text on iOS and android (maybe there are some android versions where it's somewhere else but most have it above). Easy fix would be to either move the highlight menu above the context menu, or below the selected text. I have implemented the same feature in another app and there was no problem with having it below - but it could maybe lead to accessibility issues. Besides that, we would also have to adjust the web UI or simply have that it opens above on web and below on mobile. Or keep it for both, but again - would be a design change. We could also just block the whole context menu but this seems weird and I don't think this is the way to go. Another idea would be to have an icon in the menu bar. This would add a new design element and would change the design for mobile and web, not sure if that's too much. In general the apps also have other possibilities, but (again) not sure if that's something we should aim for as the design would greatly differ to the web version. Maybe there are also other ideas I didn't think about yet.

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Apr 20, 2025):

@Mxrk Thanks for the detailed summary! I think showing the highlight menu at the bottom on mobiles sounds like a simple way around the problem? Do we have a reliable way of detecting that the client is a mobile phone?

@MohamedBassem commented on GitHub (Apr 20, 2025): @Mxrk Thanks for the detailed summary! I think showing the highlight menu at the bottom on mobiles sounds like a simple way around the problem? Do we have a reliable way of detecting that the client is a mobile phone?

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@Mxrk commented on GitHub (Apr 20, 2025):

@Mxrk Thanks for the detailed summary! I think showing the highlight menu at the bottom on mobiles sounds like a simple way around the problem? Do we have a reliable way of detecting that the client is a mobile phone?

Could simply use the window width or height? Should be one hook and it would be available everywhere. Could also use a conditional check inside that component if resize events aren't important.

const [width, setWidth] = useState<number>(window.innerWidth);

function handleWindowSizeChange() {
    setWidth(window.innerWidth);
}
useEffect(() => {
    window.addEventListener('resize', handleWindowSizeChange);
    return () => {
        window.removeEventListener('resize', handleWindowSizeChange);
    }
}, []);

const isMobile = width <= 768;

https://stackoverflow.com/questions/39435395/reactjs-how-to-determine-if-the-application-is-being-viewed-on-mobile-or-deskto

@Mxrk commented on GitHub (Apr 20, 2025): > [@Mxrk](https://github.com/Mxrk) Thanks for the detailed summary! I think showing the highlight menu at the bottom on mobiles sounds like a simple way around the problem? Do we have a reliable way of detecting that the client is a mobile phone? Could simply use the window width or height? Should be one hook and it would be available everywhere. Could also use a conditional check inside that component if resize events aren't important. ```js const [width, setWidth] = useState<number>(window.innerWidth); function handleWindowSizeChange() { setWidth(window.innerWidth); } useEffect(() => { window.addEventListener('resize', handleWindowSizeChange); return () => { window.removeEventListener('resize', handleWindowSizeChange); } }, []); const isMobile = width <= 768; ``` https://stackoverflow.com/questions/39435395/reactjs-how-to-determine-if-the-application-is-being-viewed-on-mobile-or-deskto

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Apr 20, 2025):

@Mxrk sure, looks good to me 👍

@MohamedBassem commented on GitHub (Apr 20, 2025): @Mxrk sure, looks good to me 👍

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@thiswillbeyourgithub commented on GitHub (Apr 20, 2025):

Great to see this moving forward! Thank you both a lot.

Regarding the phone detection, have you thought about if this won't cause issue for vertical computer screens or phone in landscape mode? I would have thought user agents might be more reliable no?

Also would the code change make the highlight available on the android app OR the android browser or both? Because I just opened issue #1285 to track the current state of screen utilization on android browser, which might impact the highlighting UI if addressed.

@thiswillbeyourgithub commented on GitHub (Apr 20, 2025): Great to see this moving forward! Thank you both a lot. Regarding the phone detection, have you thought about if this won't cause issue for vertical computer screens or phone in landscape mode? I would have thought user agents might be more reliable no? Also would the code change make the highlight available on the android app OR the android browser or both? Because I just opened issue #1285 to track the current state of screen utilization on android browser, which might impact the highlighting UI if addressed.

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@Mxrk commented on GitHub (Apr 20, 2025):

Regarding the phone detection, have you thought about if this won't cause issue for vertical computer screens or phone in landscape mode? I would have thought user agents might be more reliable no?

User agent check would lead to the same problem if a touch device is being used with a non mobile user agent. Using a max width from e.g. the biggest iPad / Android tablet should include most devices, same with the user agent. There will probably always be some edge cases I think.

Maybe checking for touch device would be smart as we don’t care about the size but the input device? (pointer: coarse)

@Mxrk commented on GitHub (Apr 20, 2025): > Regarding the phone detection, have you thought about if this won't cause issue for vertical computer screens or phone in landscape mode? I would have thought user agents might be more reliable no? User agent check would lead to the same problem if a touch device is being used with a non mobile user agent. Using a max width from e.g. the biggest iPad / Android tablet should include most devices, same with the user agent. There will probably always be some edge cases I think. Maybe checking for touch device would be smart as we don’t care about the size but the input device? (pointer: coarse)

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@thiswillbeyourgithub commented on GitHub (Apr 20, 2025):

Possibly relevant: https://stackoverflow.com/questions/4817029/whats-an-optimal-or-efficient-way-to-detect-a-touch-screen-device-using-javas

@thiswillbeyourgithub commented on GitHub (Apr 20, 2025): Possibly relevant: https://stackoverflow.com/questions/4817029/whats-an-optimal-or-efficient-way-to-detect-a-touch-screen-device-using-javas

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@Mxrk commented on GitHub (Apr 20, 2025):

Possibly relevant: https://stackoverflow.com/questions/4817029/whats-an-optimal-or-efficient-way-to-detect-a-touch-screen-device-using-javas

These answers are what I mean in my last paragraph - checking for input device. With this check we would also adjust the UI for desktop devices using a touchscreen.

@Mxrk commented on GitHub (Apr 20, 2025): > Possibly relevant: https://stackoverflow.com/questions/4817029/whats-an-optimal-or-efficient-way-to-detect-a-touch-screen-device-using-javas These answers are what I mean in my last paragraph - checking for input device. With this check we would also adjust the UI for desktop devices using a touchscreen.

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@thiswillbeyourgithub commented on GitHub (May 2, 2025):

Hi!

I was wondering if there was any news on this front as I have tons of reading to catch up in the summer :)

Thanks!

PS: Of course the bounty is still up

@thiswillbeyourgithub commented on GitHub (May 2, 2025): Hi! I was wondering if there was any news on this front as I have tons of reading to catch up in the summer :) Thanks! PS: Of course the bounty is still up

kerem commented

2026-03-02 11:52:48 +03:00

Author

Owner

@Mxrk commented on GitHub (May 2, 2025):

Hi!

I was wondering if there was any news on this front as I have tons of reading to catch up in the summer :)

Thanks!

PS: Of course the bounty is still up

Hi!

As mentioned here https://github.com/karakeep-app/karakeep/issues/1220#issuecomment-2817100002, it's in theory really easy to add that feature to the web version, it's only left how to decide when we switch between showing the box above or below.

But the main problem are the mobile apps as this whole "engine" isn't existing there. In my opinion the best way to do that would be to have a separate js package which builds e.g. the highlighting engine which then can be injected into the Webview in the apps and can be used in the web package. That would imo. be a clean solution and is extendable with other features.

Having two "engines" would imo be bad for future bug fixes or even feature extensions. It would still be possible to have e.g. mobile only features which can be injected besides the main stuff.

@Mxrk commented on GitHub (May 2, 2025): > Hi! > > I was wondering if there was any news on this front as I have tons of reading to catch up in the summer :) > > Thanks! > > PS: Of course the bounty is still up Hi! As mentioned here https://github.com/karakeep-app/karakeep/issues/1220#issuecomment-2817100002, it's in theory really easy to add that feature to the web version, it's only left how to decide when we switch between showing the box above or below. But the main problem are the mobile apps as this whole "engine" isn't existing there. In my opinion the best way to do that would be to have a separate js package which builds e.g. the highlighting engine which then can be injected into the Webview in the apps and can be used in the web package. That would imo. be a clean solution and is extendable with other features. Having two "engines" would imo be bad for future bug fixes or even feature extensions. It would still be possible to have e.g. mobile only features which can be injected besides the main stuff.

kerem commented

2026-03-02 11:52:49 +03:00

Author

Owner

@thiswillbeyourgithub commented on GitHub (May 2, 2025):

Note: for some reason I think I sound pushy and entitled in this message but I'm really not I promise. And the bounty thing is not me being disrespectful of anyone's time I swear!

Thanks for the quick and helpful reply.

I'm not sure I understand what you mean by "having two engines": do you mean that we should not implement touch highlights to the web version until the mobile app has its own highlight engine?

The ability to support touch on the web version seems like a "necessity" because not all touch device that have a browser have a the ability to install apps (corporate phones and tablets, linux phones and tablets, old device with a broken playstore, kindles and other einks devices that have touch but a locked down app store, computers with touch screens, browser only device like remarkable, etc etc). Especially if you say it's "really easy". Unless I'm missing something?
If it's that easy to add, I'm guessing it's about as easy to remove later, once we have the proper highlight engine on mobile, no? This would be a good argument towards having this bandaid fix asap and proper engines later.
Similarly, the patch could be turned off when using device with known engines that interfere, as they get developed. But I think that's what you are referring to when you say "It would still be possible to have e.g. mobile only features which can be injected besides the main stuff."
My proposed bounty explicitly states that if the ability to highlight on mobile is only for the web version and not the app, it's fine for me.
If you happen to have a draft PR I would certainly be interested in giving it a go. There's a non zero change I'll try to LLM-enhance it and contribute myself.

So yeah in conclusion I did not understand if your message roughly states "Once I know wether to put the box above or below I will make a PR for the web version and we'll see later for the mobile app" or "I don't think it's wise to allow touch highlighting on devices in the web version and we should rather wait to have a proper highlight engine on the mobile app".

Have a nice day.

@thiswillbeyourgithub commented on GitHub (May 2, 2025): *Note: for some reason I think I sound pushy and entitled in this message but I'm really not I promise. And the bounty thing is not me being disrespectful of anyone's time I swear!* Thanks for the quick and helpful reply. I'm not sure I understand what you mean by "having two engines": do you mean that we should not implement touch highlights to the web version until the mobile app has its own highlight engine? 1. The ability to support touch on the web version seems like a "necessity" because not all touch device that have a browser have a the ability to install apps (corporate phones and tablets, linux phones and tablets, old device with a broken playstore, kindles and other einks devices that have touch but a locked down app store, computers with touch screens, browser only device like remarkable, etc etc). Especially if you say it's "really easy". Unless I'm missing something? 2. If it's that easy to add, I'm guessing it's about as easy to remove later, once we have the proper highlight engine on mobile, no? This would be a good argument towards having this bandaid fix asap and proper engines later. 3. Similarly, the patch could be turned off when using device with known engines that interfere, as they get developed. But I think that's what you are referring to when you say "It would still be possible to have e.g. mobile only features which can be injected besides the main stuff." 4. My proposed bounty explicitly states that if the ability to highlight on mobile is only for the web version and not the app, it's fine for me. 5. If you happen to have a draft PR I would certainly be interested in giving it a go. There's a non zero change I'll try to LLM-enhance it and contribute myself. So yeah in conclusion I did not understand if your message roughly states "Once I know wether to put the box above or below I will make a PR for the web version and we'll see later for the mobile app" or "I don't think it's wise to allow touch highlighting on devices in the web version and we should rather wait to have a proper highlight engine on the mobile app". Have a nice day.

kerem commented

2026-03-02 11:52:49 +03:00

Author

Owner

@thiswillbeyourgithub commented on GitHub (May 3, 2025):

Thanks a lot @Mxrk for the PR. It looks really nice. Unfortunately I was not able to quickly get the branch to build so if I don't find the time to make it work I'll have to wait for the next release. Do you mind waiting until I get to try it until I give you the bounty? I would also gladly add $10-20 to any substantial progress on #1285

Edit: I now have seriously tried to make the docker build work but it's beyond me so I really won't be able to check it out before the next release.

@thiswillbeyourgithub commented on GitHub (May 3, 2025): Thanks a lot @Mxrk for the PR. It looks really nice. Unfortunately I was not able to quickly get the branch to build so if I don't find the time to make it work I'll have to wait for the next release. Do you mind waiting until I get to try it until I give you the bounty? I would also gladly add $10-20 to any substantial progress on #1285 Edit: I now have seriously tried to make the docker build work but it's beyond me so I really won't be able to check it out before the next release.

kerem commented

2026-03-02 11:52:49 +03:00

Author

Owner

@thiswillbeyourgithub commented on GitHub (May 18, 2025):

This is done thanks to #1348 by @Mxrk , the bounty will be sent to them. I am not rich but I know I needed that feature, let that be a good example of how to support the open source ecosystem :)

@thiswillbeyourgithub commented on GitHub (May 18, 2025): This is done thanks to #1348 by @Mxrk , the bounty will be sent to them. I am not rich but I know I needed that feature, let that be a good example of how to support the open source ecosystem :)

Rows
Columns

[GH-ISSUE #1220] FR: [bounty $50] support for highlights on android #795

Describe the feature you'd like

Describe the benefits this would bring to existing Hoarder users

Can the goal of this request already be achieved via other means?

Have you searched for an existing open/closed issue?

Additional context