1095153 - Make image <map> event handling account for an image being offset by "object-fit" and "object-position"

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

In bug 624647, I'm implementing "object-fit" and "object-position", which will mean that for the first time, an <img> element's upper-left content-box-corner  does *not* necessarily correspond to the upper-left corner of the actual image data.

Image <map> coordinates are defined as being in units of CSS pixels, with respect to "the left edge of the image and  ... the top edge of the image" (i.e. the image's upper-left corner).
https://html.spec.whatwg.org/multipage/embedded-content.html#processing-model-2

It's not clear to me whether this is supposed to be with respect to (A) the <img> content-box, or (B) the actual rect for the rendered image-data (which is impacted by object-fit/object-position). 

I emailed the WHATWG for clarification:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0058.html

Chrome does (A), and (A) is also what falls naturally out of our implementation "for free", if I do nothing <map>-specific. However, I think (B) probably makes more sense and is closer to what the spec calls for.

So, I'm filing this bug on implementing (B), assuming there's agreement on the WHATWG list. I *think* we'll just have to adjust "TranslateEventCoords" to use the actual rendered image-rect (using "ComputeObjectRenderRect", which I'm adding in bug 624647), instead of using "GetInnerArea()" as it does now.

http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsImageFrame.cpp?rev=35011c4e3e29#1659

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)
> It's not clear to me whether this is supposed to be with respect to (A) the
> <img> content-box, or (B) the actual rect for the rendered image-data (which
> is impacted by object-fit/object-position). 

Actually -- on reflection, it seems like the spec already makes these coordinates relative to the <img> content-box (at least in terms of sizing), so I think we should leave them relative to the <img> content-box in terms of positioning the origin, as well. (regardless of "object-position")

More details in my response to dbaron:
 http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0064.html
and annevk:
 http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0066.html
on the list.

Simon Pieters (from Opera) replied & said he agreed with my analysis (and there haven't been any other thoughts), so if there aren't any other comments on the list, I'm going to assume that (A) is correct -- which means we don't need any changes, because these properties shouldn't actually influence our image <map> behavior. Hence, resolving this as INVALID.