New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 662878 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

wrong selectionStart and selectionEnd value

Reported by sebco...@gmail.com, Nov 7 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce the problem:
1. create input field
2. set cursor with touchend
3. read selectionStart or SelectionEnd Value

What is the expected behavior?

What went wrong?
when you set cursor a la touch to position 1. value 1 is saved in e.target.selectionStart. But when you access to this value with the function selectionStart or SelectionEnd, you get the previous value (like 3) and not the value 1.

Did this work before? N/A 

Chrome version: 54.0.2840.71  Channel: n/a
OS Version: 14.4
Flash Version: Shockwave Flash 23.0 r0
 

Comment 1 by kochi@chromium.org, Nov 7 2016

Components: -Blink Blink>Forms>Text

Comment 2 by tkent@chromium.org, Nov 8 2016

Labels: Needs-Feedback
Please provide a reproducible HTML.

Comment 3 by tkent@chromium.org, Nov 8 2016

NextAction: 2016-11-22

Comment 4 by sebco...@gmail.com, Nov 9 2016

<html>

	<head>
		<style>
			.username {
			    width: 360px;
			    position: absolute;
			    left: 0;
			    top: 0;
			    padding-left: 17px;
			    line-height: 50px;
			    color: #2a2a2a;
			    font-family: "Arial";
			    font-size: 16px;
			    text-align: left;
			    position: absolute;
			}
		</style>

	</head>

	<body>

		<input ng-keydown="functionX($event);" 
		textselect="" ng-keypress="functionY($event);" 
		ng-keyup="loginKey($event);" 
		id="field123" class="username ng-isolate-scope" 
		type="text" ng-focus="setFocus($event);" 
		style="z-index: 1;">

	</body>

	<script>
		var elem = document.getElementById('field123');
			elem.addEventListener('touchstart', function(e) {
				console.log('startSelection target: '+e.target.selectionStart);
				console.log('endSelection target: '+e.target.selectionEnd);
				console.log('startSelection elem: '+elem.selectionStart);
				console.log('endSelection elem: '+elem.selectionEnd);
			});
	</script>
</html>


Comment 5 by tkent@chromium.org, Nov 11 2016

I couldn't reproduce the problem with Google Chrome 54 stable on Android.
Test page: https://jsfiddle.net/int32_t/01qvkq8o/2/

e.target and elem had identical selectionStart/End.
Note that they should return the previous selection position because the browser changes the selection after touchstart event handlers.

Comment 6 by sebco...@gmail.com, Nov 11 2016

I dont test it on Android. I am developing under Ubuntu 14.04, use Chromium with responsive mode.
And I test it on a touchscreen device (not a smartphone), where Chromium is running as well, and it didnt work.

Comment 7 by tkent@chromium.org, Nov 11 2016

Labels: Needs-TestConfirmation
Wow, Linux + touch screen is a rare configuration.

Labels: TE-NeedsTriageFromMTV
Adding TE-NeedsTriageFromMTV as we dont have Linux touch screen here.

MTV@ Could any one please look into this issue.

Thanks,

Comment 9 by sebco...@gmail.com, Nov 14 2016

you dont need a touch screen. You can use Chromium in Touch-Mode-Modus (toogle device toolbar)
Labels: -TE-NeedsTriageFromMTV -Needs-Feedback Needs-Triage-M54 M-54
Cc: sureshkumari@chromium.org
Labels: -Needs-TestConfirmation -Needs-Triage-M54 OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on windows-7, Mac-10.11.6 and Linux Ubuntu-14.04 using chrome stable version 54.0.2840.99 and latest canary 57.0.2926.0 .

This is non-regression issue observed from M-35 # 35.0.1853.0.  Hence marking it as Untriaged to get it addressed.
Please find the attached screen-cast for reference.

Thanks.
issue-662878.mp4
882 KB View Download
NextAction: ----
Owner: tkent@chromium.org
Status: WontFix (was: Untriaged)
Re: Comment 11.  The video means we didn't reproduce the problem. Two paris of startSelection and endSelection were always identical.

I also checked on Linux, and couldn't reproduce the problem.

Closing because we can't reproduce the problem.


The problem is NOT that startSelection and endSelection are always identical.

The problem IS: the value of them is the PREVIOUS value!
> The problem IS: the value of them is the PREVIOUS value!

It's an expected behavior.  User's event hander is executed before the system event handler, which changes selection.

Sign in to add a comment