There has been a «design decision» to disable links when text selection mode is enabled. This is extremely unintuitive A lot of user get confused when hyperlinks don't work as they would expect and there is no hint why hyperlinks don't work. Best solution: Reenable hyperlinks even in text selection mode. Other possibility: At least show a message on the document (e.g. as hover-text on the hyperlinks) saying that hyperlinks were disabled due to text selection mode an that they'll work again as soon as the user reverts to browser mode. As you can see in https://bugs.kde.org/show_bug.cgi?id=305592 people are confused and don't understand why links don't work. Reproducible: Always Steps to Reproduce: 1. open document with links 2. chose text selection mode 3. click an link (try all three mouse buttons, even with shift/controlm/alt-key) Actual Results: nothing happens Expected Results: jump to the link target
*** Bug 334476 has been marked as a duplicate of this bug. ***
I second the opinion that this behavior is counterintuitive in particular given the fact that most other pdf viewers do follow links in text selection mode. BTW, also the zoom mode disables links.
This needs to be fixed. A coworker sent me a PDF today for proofreading and I told him to check the hyperref configuration in LaTeX, because links didn't work to me. Fortunately, I found Bug 305592 some minutes later and learnt about this issue, so I didn't waste too much of his time. This decision doesn't make sense, and it's almost impossible to figure out on your own that it happens because you have text-selection or zoom mode activated. It can lead you to spend a very frustrating long time fiddling with your document source. I normally have a good instinct to find and fix these kind of things, but I wouldn't have figured this one out in a million years. It's just not intuitive.
Setting aside the irate users demanding their "rights", I'm emberassed to admit I've fallen for this before too, and it took me months until I realized what the cause is---by mistake. I think this would be a good change from a UX pov, though of course the choice might have been due to reasons I'm unaware of. Still, if all that's been stopping this from happening was paucity of patch... https://git.reviewboard.kde.org/r/124723/
Albert, any thoughts about changing the behavior as suggested? If you're against, it'd be helpful to get your take on the merits of the current behavior because it's probably safe to say that it's confusing to many users (me included), while the patch fixes the problem without disrupting (afaict) usage for users who don't have a problem.
Yes yes, i know, i have stuff to review, sorry i'm busy, trying to go through stuff as fast as i can.
Rebased against master: https://git.reviewboard.kde.org/r/124961/
There's no need to open a new review request, next time just update the diff of the existing one.
Well, how does review board handle history rewrites? I assumed it wouldn't like it.
Gentle reminder, Albert. I've been using a patched version daily for over a month now with no issues. Of course, there may be bugs, but If so they're probably subtle and will surface only when more users switch to it. I'm not sure what the release sched is but since your reviewboard comments have been positive,can we make sure this makes it in to the next release? Users have been asking for this change for at least two years.
Git commit 6d7403ff13871b068a121cd0afbb1ee1157ff375 by Albert Astals Cid, on behalf of Renato Araujo Oliveira Filho. Committed on 11/10/2017 at 13:03. Pushed by aacid into branch 'master'. Interact with hyperlinks in TextSelect mode Allow user to click on url while on any selection mode Based on https://git.reviewboard.kde.org/r/124961/ by Jake Linder <JakeLinder@mail.com> Includes several autotests to try to minimize possible regressions as much as possible REVIEW: 130246 A +- -- autotests/data/pdf_with_links.pdf M +484 -10 autotests/parttest.cpp M +201 -104 ui/pageview.cpp M +4 -0 ui/pageview.h https://commits.kde.org/okular/6d7403ff13871b068a121cd0afbb1ee1157ff375