boundingClientRect wrongly calculated for text nodes
Reported by
cyril.au...@gmail.com,
Jun 25 2016
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2774.3 Safari/537.36 Example URL: https://jsfiddle.net/pbx78jq1/ Steps to reproduce the problem: 1. https://jsfiddle.net/pbx78jq1/ 2. select "ipsum" (second word) 3. observe the console, and the width and height which are extremely large for that single word selection What is the expected behavior? returns the rect for that selection What went wrong? the rect is wrongly calculated using the span's bound Does it occur on multiple sites: No Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 53.0.2774.3 Channel: dev OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0
,
Jul 2 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 20 2016
,
Jul 22 2016
It returns two rects, one for each part of the word. Both which appear to be correct. What are you seeing?
,
Jul 22 2016
when you select i|p<span>su|m for example, you agree that the bouding rect should be with a width of ~ 25px? on chrome I see 400px (because it takes the whole span into account
,
Jul 22 2016
https://jsfiddle.net/crl/pbx78jq1/1/ corresponding fiddle, (the original is less obsvious)
,
Aug 1 2016
Firefox seems to shows the true selection width.
,
Aug 2 2016
Ok, that seems wrong. Thanks for the clarification.
,
Aug 2 2016
Caused by Range::getBorderAndTextQuads in Range.cpp incorrectly including the entire width of the span element when the range cross the element boundary.
,
Aug 2 2016
,
Aug 16 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7b05ec36906acc9e75c2e06ab68bbd0aa8ba691c commit 7b05ec36906acc9e75c2e06ab68bbd0aa8ba691c Author: eae <eae@chromium.org> Date: Tue Aug 16 16:29:32 2016 Exclude start/end container in Range::getBorderAndTextQuads Change Range::getBorderAndTextQuads to exclude the size of the container elements for either end point. The porition of the element included in a range is accounted for when computing the size for the start & end node. TEST=fast/dom/Range/range-spanning-elements-bounding-client-rect.html BUG= 623301 R=yosin@chromium.org Review-Url: https://codereview.chromium.org/2209513002 Cr-Commit-Position: refs/heads/master@{#412263} [add] https://crrev.com/7b05ec36906acc9e75c2e06ab68bbd0aa8ba691c/third_party/WebKit/LayoutTests/fast/dom/Range/range-spanning-elements-bounding-client-rect.html [modify] https://crrev.com/7b05ec36906acc9e75c2e06ab68bbd0aa8ba691c/third_party/WebKit/Source/core/dom/Range.cpp
,
Aug 16 2016
,
Aug 19 2016
Verified the fix on Windows 10 for Google Chrome Dev Version - 54.0.2832.2 Screen-shot is attached. TE-Verified label is added.
,
Aug 19 2016
great 👍, it works fine now |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by brajkumar@chromium.org
, Jun 27 2016Status: Untriaged (was: Unconfirmed)
Tested this issue on Windows 7 using chrome latest canary M53-53.0.2780.0 by following steps mentioned in the above comment. By copying the word ipsum observed the console displays saying "ClientRect {top: 8, right: 414.125, bottom: 43, left: 8, width: 406.125…}". Tested the same on earlier versions of chrome M50-50.0.2641.0 and observed the same behavior as seen on latest chrome versions. Considering this issue as a non-regression and marking it as untriaged. Thanks!