HTMLImageElement x and y coordinates are 0 if its parent container has position: relative
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: ksenia, Assigned: mrobinson)
References
()
Details
Attachments
(4 files)
As reported in https://github.com/webcompat/web-bugs/issues/52738
STR:
- Visit https://chintglobal.com/products/nm8n-moulded-case-circuit-breaker-8-1057 in Firefox and try to hover over the image
Expected:
Can hover over the top part of the product image to see the details
Actual:
Can't hover over the top part of the image
One of the properties the site is relying on for calculations is the y coordinate of the image:
i = u.clientY - this.main_image.y - this.mengban.clientHeight / 2;
I've attached a reduced test case, it seems that the fact that a parent container of the image has position: relative is affecting the coordinates, however that doesn't happen in Chrome.
|
||
Comment 1•5 years ago
|
||
Yeah, that's wrong per spec, https://drafts.csswg.org/cssom-view/#extensions-to-the-htmlimageelement-interface:
The x attribute, on getting, must return the x-coordinate of the left border edge of the first CSS layout box associated with the element, relative to the initial containing block origin, ignoring any transforms that apply to the element and its ancestors, or zero if there is no CSS layout box.
|
|
||
Comment 2•5 years ago
|
||
That being said it seems like the page is also super clunky in Chrome, it doesn't seem to behave as expected either.
|
||
Comment 3•5 years ago
|
||
Does PresShell()->GetRootFrame() returns the "initial containing block", or should it be obtained from nsCSSFrameConstructor?
|
|
||
Updated•5 years ago
|
|
|
||
Comment 4•5 years ago
|
||
Per https://drafts.csswg.org/cssom-view/#extensions-to-the-htmlimageelement-interface:
The x attribute, on getting, must return the x-coordinate of the left
border edge of the first CSS layout box associated with the element,
relative to the initial containing block origin, ignoring any
transforms that apply to the element and its ancestors, or zero if
there is no CSS layout box.
But we were using GetClosestLayer which stops at the first abspos
containing block or scroll frame.
|
|
||
Comment 5•5 years ago
|
||
Yeah, I had a patch doing just that that I posted. But it's not clear whether that matches other browsers in presence of transforms etc, and there's no wpt that started passing / failing with it.
Depending on what other browsers do we might want to use GetRootScrollableFrame or something instead.
|
Assignee | |
Comment 6•3 years ago
|
||
I was looking at content-visibility failures and I noticed that this change now fixes tests/css/css-contain/content-visibility/content-visibility-img.html in the css-contain suite. I also verified that this has the same behavior as Chromium and WebKit when there is a transform between the image and the ICB.
|
Reporter | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 7•3 years ago
|
||
I've uploaded an updated version of the fix for this.
|
|
Assignee | |
Comment 8•3 years ago
|
||
Per https://drafts.csswg.org/cssom-view/#extensions-to-the-htmlimageelement-interface:
The x attribute, on getting, must return the x-coordinate of the left
border edge of the first CSS layout box associated with the element,
relative to the initial containing block origin, ignoring any
transforms that apply to the element and its ancestors, or zero if
there is no CSS layout box.
But we were using GetClosestLayer which stops at the first abspos
containing block or scroll frame.
|
||
Updated•3 years ago
|
|
||
Comment 10•3 years ago
|
||
| bugherder | ||
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
||
Comment 13•3 years ago
|
||
Reproduced the issue with Firefox 84.0a1 (20201112212842) on Windows 10x64 using the webpage link from comment 0. The image hover selection cannot be moved on the top side of the image.
The issue is verified fixed with Firefox 104.0b2 (20220726185717) on Windows 10x64, Ubuntu 20.04 and macOS 11. The image can be hovered as expected.
Description
•