Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non/less flashing text layer during selection. #6591

Merged
merged 1 commit into from
Nov 5, 2015

Conversation

yurydelendik
Copy link
Contributor

If we place entire-text-layer div after the content, it will make selection flash in different way: bottom-right part instead of left-top.

-moz-user-select fixes flashing for Firefox. (-webkit-user-select has no effect -- just added it for company).

@timvandermeij
Copy link
Contributor

This makes text selection much more smooth in my opinion. Nice work!

@Rob--W
Copy link
Member

Rob--W commented Nov 3, 2015

Which steps should I follow to observe the undesiredflashing behavior in Chrome?

I've tried to select text and it is much better than before, but I don't see any other issues (perhaps my steps are wrong? E.g. I select the title and move the mouse downwards, before the change only the first letter is selected, after this commit multiple lines are selected).

@yurydelendik
Copy link
Contributor Author

STR:

  • Open PDF.js viewer app on default tracemonkey pdf;
  • Set page 1 at 200% and top-left corner at the top-left corner of the window;
  • Click and hold in the middle of "Rick Reitmaier#, Michael Bebenita+";
  • Move mouse slowly towards "University of California, Irvine+"

(Without fix) notice flashing of the text at the top and left.

@yurydelendik
Copy link
Contributor Author

Which steps should I follow to observe the undesiredflashing behavior in Chrome?

We still have flashing of the bottom-right text on other browsers but Firefox.

@Rob--W
Copy link
Member

Rob--W commented Nov 3, 2015

Nice find. Is this user-select behavior guaranteed by any standard, or is it an accidental implementation detail? In this specific case, Firefox's result is obviously more desirable, but I cannot really formulate what exactly is wrong with Chrome (and how it can be fixed).

@yurydelendik
Copy link
Contributor Author

Is this user-select behavior guaranteed by any standard,

Based on https://developer.mozilla.org/en-US/docs/Web/CSS/user-select it is not a standard, so it will be hard to find a documented behavior. Looks like FF just ignores any selection action, but other browsers are trying to work around of non-selectable element.

@Rob--W
Copy link
Member

Rob--W commented Nov 3, 2015

I found an issue with your patch. If you start with the selection in the blank space between "Just-in-Time" and the authors, then move the mouse down, then:

  • In Firefox nothing gets selected.
  • In Chrome all text after the text is selected (until the end of the document).

In both Chrome and Firefox (without patch), the above action results in a text selection starting at the top of the page and ending at the location of the cursor.

So, the behavior for a selection that starts inside text is better, but the result for a selection that starts outside the range is worse.

@yurydelendik
Copy link
Contributor Author

So question: shall I keep patch as is, remove user-select or close entire PR? Voting is opened :)

@Rob--W
Copy link
Member

Rob--W commented Nov 4, 2015

Is it an option (= no performance loss and no negative side effects) to insert the element only when the user clicks on a text layer item (via a mousedown event)? That would probably fix Firefox's bug.

Even without the additional fixes, I'm currently in favor of merging the patch because it has better results for the common case (start a selection in the text and move elsewhere).

@Snuffleupagus
Copy link
Collaborator

To summarize what I wrote on IRC:

  • It's currently not possible to "cancel" the text-selection by clicking on an empty part of a page. (You need to click on either: a piece of text, or outside of the pages.)
    As far as I'm concerned, given the negative UX implications of it, this issue needs to be fixed.
  • The text-selection cursor is permanently displayed, when the cursor is positioned over a page (regardless if it's over selectable text, or not).
  • It's no longer possible to start the text-selection just outside of the text. This can make it much more difficult to e.g. select the text contents of a link, unless there is "normal" text surrounding it.
    For example, try selecting the text of the vertical link on the first page of http://arxiv.org/pdf/1112.0542v1.pdf, with/without this patch.
    This could probably be considered a minor issue, but since I noticed it, I at least wanted to mention it.

@yurydelendik
Copy link
Contributor Author

/botio-windows preview

How about now? Used spin on Rob's idea to insert div only when mouse clicked.

@yurydelendik
Copy link
Contributor Author

Now fixed for useCssZoomOnly

/botio-linux preview

Addresses "the selection gets reversed" concern expressed at #5545 and #4843.

div.addEventListener('mouseup', function (e) {
var end = div.querySelector('.endOfContent');
if (!end) {
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing return; before }?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Thanks

@Snuffleupagus
Copy link
Collaborator

The last version seems to address all of my comments from #6591 (comment), nicely done!


.textLayer .endOfContent.active {
top: 0px;
bottom: 0px;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this line actually necessary, since it shouldn't change anything given that bottom: 0px; was already set above?

@timvandermeij
Copy link
Contributor

/botio-linux preview

@pdfjsbot
Copy link

pdfjsbot commented Nov 4, 2015

From: Bot.io (Linux)


Received

Command cmd_preview from @timvandermeij received. Current queue size: 0

Live output at: http://107.21.233.14:8877/5cf13a1f0fe544c/output.txt

* This reduces flickering of the content if mouse slowly dragged down/up.
* @private
*/
_bindMouse: function () {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename anonymous function to TextLayerBuilder_bindMouse.

@Rob--W
Copy link
Member

Rob--W commented Nov 4, 2015

In Chrome: if you press the mouse at any blank space and move the pointer upwards, then the whole document is selected. Moving by just a few pixels is already enough to trigger this unwanted behavior, so it can already happen if the user just wants to click on the document.

The new _bindMouse logic has made the patch a bit worse. Please disable the body of _bindMouse in every browser except for Firefox (unless you've tested the browser and it showed good results).

@yurydelendik
Copy link
Contributor Author

@Rob--W Most of the logic in _bindMouse for other browsers, especially "set top" part. I cannot reproduce behavior you described above on Chrome for Mac OSX -- in fact the "set top" part suppose to help to remove that.

@Rob--W
Copy link
Member

Rob--W commented Nov 4, 2015

@yurydelendik I can trigger the bug at 100% zoom in Chrome 46 (Linux, OS X and Windows).

@yurydelendik
Copy link
Contributor Author

Sorry it's actually fixing the case when selection started from text. Not sure how to address your issue yet -- by removing to above you shall get the same effect but when you are moving down (try http://107.21.233.14:8877/5ce984c56a4c940/web/viewer.html, click empty space and move down)

@Rob--W
Copy link
Member

Rob--W commented Nov 4, 2015

@yurydelendik The difference between the previous version and the last version is that in the previous version you had to move over text, whereas in the last version just moving the cursor by a few pixels is already enough.

When I click on the blank space as a user (e.g. to focus the window?), then it is very realistic that the mouse moves by a few pixels. When that happens I don't want the whole document to be selected.

@yurydelendik
Copy link
Contributor Author

@Rob--W okay, suppressed this logic when selection starts at empty space. Is this better?

/botio-windows preview

@pdfjsbot
Copy link

pdfjsbot commented Nov 4, 2015

From: Bot.io (Windows)


Received

Command cmd_preview from @yurydelendik received. Current queue size: 0

Live output at: http://107.22.172.223:8877/58bd91f15157c48/output.txt

@Rob--W
Copy link
Member

Rob--W commented Nov 4, 2015

👍 !

Snuffleupagus added a commit that referenced this pull request Nov 5, 2015
Non/less flashing text layer during selection.
@Snuffleupagus Snuffleupagus merged commit 8079bdd into mozilla:master Nov 5, 2015
@Snuffleupagus
Copy link
Collaborator

Looks good, thanks for the patch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants