Closed Bug 487597 Opened 11 years ago Closed 5 years ago
.yahoo .com/yui/ - YUI library incorrectly expects get Bounding Client Rect() to return only integer results
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.0.30618; .NET CLR 3.5.30729; OfficeLiveConnector.1.3; OfficeLivePatch.0.0) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; tr; rv:220.127.116.11) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) well. first of all sorry for my english. I 'm working on somekind overlay image preview. I think I found a bug. When over icon, image overlay should be display. But there is a mistake on top and on left, 1px more positioning. I tested on IE 6 - 7 - 8 RC 1, Firefox 2 - 3, Opera 9.2 - 9.6, Safari 3 - 4 Beta, Netscape 8.1 - 9. No browser doing that but Firefox 3. Even firefox 2 doesnt. The explaination is too bad ha?:) Here is the example: http://www.yonca-ad.com/developer/ff3bug/ Reproducible: Always Steps to Reproduce: 1. Just over F icon with Mouse 2. 3.
Regression range: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1180563300&maxdate=1180565399 There is a bug Bug 174397 and a Bug 382289.
Here is a more reduced testcase. I possibly ripped out too much, but I think you can get what the problem is. There's the rectangle when hovered and when not hovered. In Fx 3 and higher there are two problems compared to Fx 2: 1. the blue rect shifts 1 px to the left when hovered (in the original testcase it shifted 1 px right) 2. A rounding problem I think: In Fx2 the table consists of 2px, blue rect and 3px; In Fx 3 it's 3px, blue rect and 2px.
sorry to ask but is that a bug, right?
(In reply to comment #3) > sorry to ask but is that a bug, right? The problem is an unintended result or a side effect of a fix in the past.
Could somebody more familiar with this bug give the bug a Summary field that reflects our understanding of the problem? The current Summary is not specific enough to help understand what the bug is.
(In reply to comment #2) > In Fx 3 and higher there are two problems compared to Fx 2: > 1. the blue rect shifts 1 px to the left when hovered (in the original testcase > it shifted 1 px right) Well, if I look at the markup in the simplified testcase, it looks like it ought to be positioned 0.5px to the left. Why would you expect it at the same place? > 2. A rounding problem I think: In Fx2 the table consists of 2px, blue rect and > 3px; In Fx 3 it's 3px, blue rect and 2px. Why do you expect the Fx2 behavior?
(In reply to comment #6) > Well, if I look at the markup in the simplified testcase, it looks like it > ought to be positioned 0.5px to the left. Why would you expect it at the same > place? My thoughts went backwards in this case, I didn't expect it because none of the other engines round that way. The testcase was created for you to find out whether it is a bug or not. > Why do you expect the Fx2 behavior? Same answer, but I took a deeper look at the testcase. As I thought, I cut out too much in my reduced testcase. The problem is, that getBoundingClientRect() returns float numbers (12.5 and 28.5 in this case) while the IE and Opera implementation returns integers. It could be a TechEvang issue, since the Yahoo Library used by the reporter doesn't expect float numbers (it uses getBoundingClientRect to calculate the coordinates for the image). On the other hand, the MSDN documentation about getBoundingClientRect() says: > Returns a TextRectangle object. Each rectangle has four *integer* properties > (top, left, right, and bottom) that represent a coordinate of the rectangle, > in pixels.
Summary: There is a mistake while Element positioning → getBoundingClientRect() return float numbers instead of integers
Returning fractional results in getBoundingClientRect is intended and allowed by the CSSOM draft spec. It gives more useful information than rounding in the browser; scripts can round the values manually if they want. But if the testcase in comment #2 is really a reduced testcase of the original testcase, how can this bug be about getBoundingClientRect?
(In reply to comment #9) > But if the testcase in comment #2 is really a reduced testcase of the original > testcase, how can this bug be about getBoundingClientRect? In the original testcase, a script including getBoundingClientRect is used to calculate the coordinates for the image. Note that it's always positioned next to the blue rect independently of where that is positioned. To create the reduced testcase I simply did 'View Selection Source'. This way I ignored the script, except for using its calculated values. As a result, I only noticed the difference in rounding, although the real problem is, that the script can't cope with results like 12.5px.
Per comment 9, fractional results in getBoundingClientRect is intended. => Tech Evang.
Assignee: nobody → english-us
Component: Layout → English US
OS: Windows Vista → All
Product: Core → Tech Evangelism
QA Contact: layout → english-us
Hardware: x86 → All
Summary: getBoundingClientRect() return float numbers instead of integers → yahoo.com - getBoundingClientRect() return float numbers instead of integers
Version: Trunk → unspecified
Er, what does this bug have to do with Yahoo?
I got the impression it is the YUI library http://developer.yahoo.com/yui/ that expects integer results from getBoundingClientRect and per comment 9 fractional results is allowed by the draft spec, so it is YUI that needs to be fixed. Please correct me if I'm mistaken.
Thanks, Mats. Re-summarizing to reflect what the actual issue is. Do we have any idea who to talk to at Yahoo to get this fixed?
Summary: yahoo.com - getBoundingClientRect() return float numbers instead of integers → developer.yahoo.com/yui/ - YUI library incorrectly expects getBoundingClientRect() to return only integer results
If it's an issue with the YUI library, it has been possibly fixed. Since 2009, they had a few versions. Note also they completely stopped support for the future as of August 2014. The test provided has also since been removed.
Assignee: english-us → nobody
Status: NEW → RESOLVED
Closed: 5 years ago
Component: English US → Desktop
Resolution: --- → INVALID
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.