Shitf + Click to Select Content Range Fails when new a position:fixed; popup element suddenly adds in
Reported by
ctengc...@gmail.com,
Mar 15 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Example URL: http://www.infoq.com/cn/ Steps to reproduce the problem: 1. First, navigate to any new article on infoq 2. Double click the article's title's start part 3. Scroll the page down, and try to Shift+Click to selec the whole article content range What is the expected behavior? Should be able to select What went wrong? While, a sudden position:fixed; (plus z-index: 10001 ?) popup appeared on the right-bottom corner of page, this causes range select operation to fail Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? N/A Chrome version: 56.0.2924.87 Channel: n/a OS Version: OS X 10.12.3 Flash Version: Shockwave Flash 24.0 r0
,
Mar 15 2017
Sorry for the type & the tense which may be misuse!
,
Mar 15 2017
,
Mar 15 2017
Remove Blink>DOM>Events
,
Mar 16 2017
,
Mar 31 2017
,
Apr 3 2017
Unable to reproduce the issue in MacBook Pro (Retina, 15-inch, Mid 2014), 10.12.3 and Win-10 using chrome reported version #56.0.2924.87, chrome beta #58.0.3029.41 and latest canary #59.0.3061.0. Following are the steps followed to reproduce the issue. ------------ 1. Navigated to a new article on http://www.infoq.com/cn/ 2. Double clicked the article's title's start part. 3. Scrolled the page down, and tried to Shift+Click to select the whole article content range. 4. Observed that range select operation happened without any issues. Attaching screen cast for reference. ctengctsh@ - Could you please check this issue on latest chrome beta #58.0.3029.41 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
Apr 5 2017
Please check my prev attached video again: i scrolled the page down to end, and the key point is: infoq popups a special position:fixed; layer, which i guess, causes the problem. If InfoQ now has no longer used this popup, then sure, you cannot reproduce the problem i met with. Hope i have time to make a html test case file, but i have no time now.
,
Apr 5 2017
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 6 2017
Unable to reproduce the issue in Mac 10.12.3 and Win-10 using latest stable #57.0.2987.133 and latest canary #59.0.3063.0. Attached a screen cast for reference. Following are the steps followed to reproduce the issue. ------------ 1. Navigated to a new article on http://www.infoq.com/cn/ 2. Double clicked the article's title's start part. 3. Scrolled the page down till the infoq pop up appeared in the right-bottom corner of page, and tried to Shift+Click to select the whole article content range. 4. Observed that range select operation happened without any issues. ctengctsh@ - Could you please check this issue on latest stable #57.0.2987.133 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
Apr 6 2017
Verified on #57.0.2987.133, Due to InfoQ currently doesn't popup new position:fixed; layer, this problem cannot reproduce now, needs manual test case... 2017-04-06 17:13 GMT+08:00 krajsh… via monorail < monorail+v2.208823224@chromium.org>:
,
Apr 6 2017
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 6 2017
Hi, i made a simple test case to see if it's the sudden position:fixed;
layer caused Shift+Select to be invalid:
<!DOCTYPE html>
<html>
<head>
<style>
.paragraph {
width:100%;
height: 200px;
background: #ccc;
margin: 10px;
}
</style>
</head>
<body style="width:100%">
<h1>标题行</h1>
<div class=paragraph>
段落内容
</div>
<div class=paragraph>
段落内容
</div>
<div class=paragraph>
段落内容
</div>
<div class=paragraph>
段落内容
</div>
<div class=paragraph>
段落内容
</div>
<div class=paragraph>
段落内容
</div>
<script>
window.addEventListener('scroll', function(e) {
document.querySelectorAll(".popup").forEach((e) =>
e.parentNode.removeChild(e));
var popup = document.createElement("DIV");
popup.setAttribute("class", "popup");
popup.style.position="fixed";
popup.style.background = "red";
popup.style.left="30%";
popup.style.top="50%";
popup.style.width="100%";
popup.style.height="60%";
popup.innerHTML = "popup";
popup.style.zIndex = 1000;
document.body.appendChild(popup);
});
</script>
</body>
</html>
But i cannot reproduce using this test case. Perhaps the problem is the
timing when the new "position:fixed;" popup layer shows up
2017-04-06 17:44 GMT+08:00 sheriff… via monorail <
monorail+v2.4164592774@chromium.org>:
,
Apr 7 2017
,
Apr 7 2017
Unfortunately I don't think we can do anything about this. It's not very surprising to me that inserting DOM content in the middle of a selection operation would cause an unexpected selection outcome. The correct approach is probably having the web site do something more sensible, and apparently they are now doing that. Re-open if you can find a reproduction example. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by ctengc...@gmail.com
, Mar 15 201712.7 MB
12.7 MB Download