Issue 1523 in pdfium: selection shortcuts similar to web

27 views
Skip to first unread message

i… via monorail

unread,
Apr 30, 2020, 8:46:58 AM4/30/20
to pdfiu...@googlegroups.com
Status: Unconfirmed
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 1523 by i...@wis.am: selection shortcuts similar to web
https://bugs.chromium.org/p/pdfium/issues/detail?id=1523

What steps will reproduce the problem?
1. select text
2. press shift + ⬅/➡/⬇/⬆ arrow
or press ctrl + ⬅/➡/⬇/⬆ arrow
or press ctrl + shift + ⬅/➡/⬇/⬆ arrow
or shift + Home/End



What is the expected output? What do you see instead?

match chromium's web renderer's behavior. here's a table with complete descriptions for all selection states and shortcuts behavior for your development pleasure :) :
| shortcut \ cursor/selcetion-state | `start` cursor is before `end` cursor (forward selection) | `start` cursor is after `end` cursor (reverse selection) | `start` == `end` (no selection *) |
|-----------------------------------|--------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|-------------------------------------|
| shift + ⬅ | unselect last char | select next char after `end` (appears at the beginning of selection) | select character before cursor |
| shift + ➡ | select next char | unselect char before `end` (appears at the beginning of selection) | select character after cursor |
| shift + ⬇ | extend selection forward (down) until char below `end` cursor | shrink selection backward (down) until char vertically adjacent to `end` in the next line (visually, unrelated to newline) | select down until char below cursor |
| shift + ⬆ | shrink selection backward (up) until char above `end` cursor | extend selection forward (up) until char in the previous line that's vertically adjacent to `end` (visually, ..) | select up until char above cursor |
| ctrl + shift + ⬅ | unselect word/part-of-a-word at the end | select next word/part-of-a-word after `end` (appears at the beginning of selection) | select previous word/part-of-word |
| ctrl + shift + ➡ | extend selection from end to include next word/part-of-last-word | unselect last word/part-of-a-word of before `end` (appears at the beginning of selection) | select next word/part-of-word |
| ctrl + shift + ⬇ | extend selection forward (down) until next block's nearest char that's vertically adjacent to `end` | 1. remove reverse selection 2. select from `start` until next block's nearest char that's vertically adjacent to `end` | <- same as 2 |
| ctrl + shift + ⬆ | shrink selection backward (up) until previous block's nearest char that's vertically adjacent to `end` | extend selection forward (up) until next block's nearest character that's vertically adjacent to `end` | <- same but no extending |
| ctrl + ⬅ | | | move cursor to beginning of word |
| ctrl + ➡ | | | move cursor to end of word |
| ctrl + ⬇ | | | move cursor to previous block |
| ctrl + ⬆ | | | move cursor to next block |
| shift + End | extend selection from `end` until end of line | extend selection from `start` until end of line | <- same |
| shift + Home | multi-line: unselect last half-selected line, single-line: select from `start` until beginning of line | extend selection from `end` to beginning of line | <- same |
| End | | | move cursor to end of line |
| Home | | | move cursor to beginning of line |* `start` == `end` cursor position means nothing is selected but the cursor has a position, it could be set if a text has been clicked, the behavior described in the last column is only in contenteditable, otherwise nothing happens.

What version of the product are you using? On what operating system?

copied and pasted from chrome://version:

Chromium 81.0.4044.129 (Official Build) Arch Linux (64-bit)
Revision 3d71af9f5704a40b85806f4d08925db24605ba25-refs/branch-heads/4044@{#979}
OS Linux
JavaScript V8 8.1.307.31
Flash (Disabled)
User Agent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36
Command Line /usr/lib/chromium/chromium --flag-switches-begin --flag-switches-end --disable-webrtc-apm-in-audio-service
Executable Path /usr/lib/chromium/chromium
Profile Path /home/wis/.config/chromium/Default


Please provide any additional information below.

in normal web mode there's no blinking cursor to show the cursor's position, however in conteneditable mode you can see a blinking cursor,
which is very useful for reading with a screen-reader, I read the web in contenteditable mode by moving the cursor with the arrow keys,
and these shortcuts to select text for my screen-reader to read out for accessibility reasons.
I would really appreciate it if you include the blinking cursor mode feature similar to the web's contenteditable mode, without the ability to edit of-course, it's a pdf after-all, just the blinking cursor,
it could be toggled with a key press or a shortcut that the embedded pdfium viewer listens to.

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

i… via monorail

unread,
Apr 30, 2020, 9:15:23 AM4/30/20
to pdfiu...@googlegroups.com

Comment #1 on issue 1523 by i...@wis.am: selection shortcuts similar to web
https://bugs.chromium.org/p/pdfium/issues/detail?id=1523#c1

sorry, the markdown table turned out missed up, I can't edit my post, so here's a link to a web page of the table published with sheets:
https://docs.google.com/spreadsheets/d/e/2PACX-1vSmcoBDTriB8W4xX_JuZJr3es6yWGr5SY_tnjysdys_NwcTsO3F2P8nBVBRl-z91cTALQaW0nMJxsUM/pubhtml?gid=428820659&single=true

Attachments:
table.png 322 KB
table - table.csv 2.3 KB

dh… via monorail

unread,
May 1, 2020, 1:41:21 PM5/1/20
to pdfiu...@googlegroups.com
Updates:
Labels: -Type-Defect Type-Enhancement

Comment #2 on issue 1523 by dh...@chromium.org: selection shortcuts similar to web
https://bugs.chromium.org/p/pdfium/issues/detail?id=1523#c2

(No comment was entered for this change.)

thes… via monorail

unread,
May 1, 2020, 1:57:04 PM5/1/20
to pdfiu...@googlegroups.com
Updates:
Status: Available

Comment #3 on issue 1523 by the...@chromium.org: selection shortcuts similar to web
https://bugs.chromium.org/p/pdfium/issues/detail?id=1523#c3

Thanks for filing this bug and trying to draw the ASCII table.

In general, if the issue is about the Chromium PDF Viewer, it's best to just file this as a Chromium bug, rather than try to guess whether the issue is in the Chromium PDF Viewer or the PDFium library. They are two distinct, though closely related projects. No worries though. Let's keep this as is.

I vaguely remember there's an existing Chromium bug about improving keyboard behavior in forms, but I can't seem to find it.

wesam… via monorail

unread,
Nov 10, 2020, 4:45:43 AM11/10/20
to pdfiu...@googlegroups.com

Comment #4 on issue 1523 by wesam...@gmail.com: selection shortcuts similar to web
https://bugs.chromium.org/p/pdfium/issues/detail?id=1523#c4

I've been ecstatic since I've found out that Chromium now has native caret browsing[1], I've used it 100% of the time and I've found it much better than the Caret browsing extension By Google[2] because it works in chrome:// and chrome-extension:// pages, not just in web pages that extensions have access to, but it does not work in pdfs (same as the extension), can you please share (or make and share) your plans for adding caret browsing/navigation to pdfium as a first step towards tackling this issue?

I've mentioned caret browsing in the original post and commenting this now asking this because selection shortcuts and caret browsing share the dependency on a single piece of program state, the position (probably of start and end) of the caret cursor.

I'm very excited and grateful for the increased focus on accessibility by the folks who work on Chromium, from Google and Microsoft.

[1] https://techdows.com/2020/08/chrome-86-adds-caret-browsing-tests-new-tab-modules-incognito-mode-desktop-shortcut.html
[2] https://chrome.google.com/webstore/detail/caret-browsing/fklpgenihifpccgiifchnihilipmbffg?hl=en

i… via monorail

unread,
Nov 10, 2020, 4:51:08 AM11/10/20
to pdfiu...@googlegroups.com

Comment #5 on issue 1523 by i...@wis.am: selection shortcuts similar to web
https://bugs.chromium.org/p/pdfium/issues/detail?id=1523#c5


I've been ecstatic since I've found out that Chromium now has native caret browsing[1], I've used it 100% of the time and I've found it much better than the Caret browsing extension By Google[2] because it works in chrome:// and chrome-extension:// pages, not just in web pages that extensions have access to, but it does not work in pdfs (same as the extension), can you please share (or make and share) your plans for adding caret browsing/navigation to pdfium as a first step towards tackling this issue?

I've mentioned caret browsing in the original post and commenting this now asking this because selection shortcuts and caret browsing share the dependency on a single piece of program state, the position (probably of start and end) of the caret cursor.

I'm very excited and grateful for the increased focus on accessibility by the folks who work on Chromium, from Google and Microsoft.

[1] https://techdows.com/2020/08/chrome-86-adds-caret-browsing-tests-new-tab-modules-incognito-mode-desktop-shortcut.html
[2] https://chrome.google.com/webstore/detail/caret-browsing/fklpgenihifpccgiifchnihilipmbffg?hl=en

(I deleted the comment I made from my personal account and re-posted from the account I made with my professional email, since I mentioned the original post)
Reply all
Reply to author
Forward
0 new messages