487597 - developer.yahoo.com/yui/ - YUI library incorrectly expects getBoundingClientRect() to return only integer results

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect)

Description

[Çağrı Ağdaş]

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:1.9.0.8) 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.

Comment 1

[Ria Klaassen (not reading all bugmail)]

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.

Comment 2

[Daniel.S]

Attachment: reduced testcase

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.

Comment 3

[Çağrı Ağdaş]

sorry to ask but is that a bug, right?

Comment 4

[Ria Klaassen (not reading all bugmail)]

(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.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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?

Comment 7

[Daniel.S]

(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.

Comment 8

[Daniel.S]

Attachment: getBoundingClientRect() results

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 10

[Daniel.S]

(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.

Comment 11

[Mats Palmgren (inactive)]

Per comment 9, fractional results in getBoundingClientRect is intended.

=> Tech Evang.

Comment 12

[Chris Lawson (gone)]

Er, what does this bug have to do with Yahoo?

Comment 13

[Mats Palmgren (inactive)]

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.

Comment 14

[Chris Lawson (gone)]

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?

Comment 15

[Karl Dubost💡 :karlcow]

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.