1285964 - Allow author to specify different object-fit value for fullscreen element

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect, P2)

Description

[griffing]

Attachment: FF Fullscreen.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36

Steps to reproduce:

I've a canvas object which I set to full screen.  Prior to V46, when a canvas element was made full screen, the canvas was stretched to fill the full X/Y screen with the top left coordinate (via getBoundingClientRec ) as 0,0.


Actual results:

In V46 & later versions, it seems to want to maintain screen X/Y ratio in full screen;  in my case this results in vertical bands on both left & right sides of the screen, though the top left location (via getBoundingClientRec) is still claimed to be 0,0.  Need method to get the true top left corner X/Y location and corner coordinates of the visible display, or again stretched to fill.


Expected results:

I'd either expect that the canvas is stretched again, or have an accurate way to acquire the coordinates of the canvas within the surround bands.

Comment 1

[Loic]

Could you attach a testcase and detail the steps to reproduce, please?

Comment 2

[Benjamin Smedberg]

This was changed in bug 1215365. I believe the change is intentional and per the specification (and matches Chrome's behavior). You can override the behavior using the object-fit CSS property. Please see prior discussion in bug 761099.

Xidorn, can you please confirm/resolve this bug, and also look to see if bug 761099 is now FIXED?

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

I think everything here works as expected.

So basically, <canvas> has two sets of dimensions: one is its internal size, which is set via width/height attributes of the element, and the other is its visual size, which is what CSS would give it. The size of the canvas (where you draw things on) is the internal size, while the element itself is displayed in its visual size, which is what you get via getBoundingClientRect.

When the visual size and the internal size do not match, depending on the value of CSS property object-fit, there are different behaviors. Currently, in the Fullscreen API spec, we have "object-fit: contain !important" on fullscreen elements, so you would always see the content be stretched but the aspect ratio is preserved.

It makes me wonder why we apply "object-fit: contain !important" to fullscreen element... I think we could just do "object-fit: contain", so that authors can override the value of object-fit to make content fill the whole screen, if they really desire that. So I raised an issue to the Fullscreen API spec [1]. If people agree that we do not need to apply "!important" there, we could remove it from our code in this bug.


[1] https://github.com/whatwg/fullscreen/issues/44

Comment 4

[griffing]

Attachment: Test example as requested.

Not a perfect duplication of my issue, but close.  Will log top/left coordinates.

Comment 5

[Xidorn Quan [:xidorn] UTC+10]

Changing the summary of this bug to reflect what I'm going to do here.

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

Attachment: Bug 1285964 - Remove !important from object-fit for fullscreen element.

Review commit: https://reviewboard.mozilla.org/r/64130/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/64130/

Comment 7

[Cameron McCormack (:heycam)]

Comment on attachment 8770775 [details]
Bug 1285964 - Remove !important from object-fit for fullscreen element.

https://reviewboard.mozilla.org/r/64130/#review61208

Looks fine, given the spec editor agrees with the change.  (The page author will still need to opt in to a stretched <canvas> I suppose.)

Comment 8

[Xidorn Quan [:xidorn] UTC+10]

The spec editor is acutally annevk... foolip is the current maintainer of the Fullscreen API impl of Blink. I don't think annevk would disagree, but let me ni? him in case foolip and I missed something.

Comment 9

[Xidorn Quan [:xidorn] UTC+10]

And yes, the page author will still need to opt in to get a stretched <canvas>.

Comment 10

[Anne (:annevk)]

Go ahead, I'll update the standard per your issue.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c6d15a3e7637
Remove !important from object-fit for fullscreen element. r=heycam

Comment 12

[griffing]

Is there any guesstimate when this change will make it into the standard release cycle?  

When it is available, then it is up to me to over-ride with "object-fit: fill" setting?

Comment 13

[Xidorn Quan [:xidorn] UTC+10]

(In reply to griffing from comment #12)
> Is there any guesstimate when this change will make it into the standard
> release cycle?

I think it would land in Firefox 50, and I guess it can be uplifted to 49, as it doesn't seem to be risky, if you think that helps.

> When it is available, then it is up to me to over-ride with "object-fit:
> fill" setting?

Yes.

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c6d15a3e7637

Comment 15

[griffing]

If the fix could be uplifted to mozilla49 (or earlier) it would be great.

Comment 16

[griffing]

The technique of 
    canvas.style.objectFit = "fill";
is verified as working in Nightly build.  Using this gets me around my issue.

Any chance the other part of the issue (getBoundingClientRect) will be addressed?

Comment 17

[Xidorn Quan [:xidorn] UTC+10]

There is no issue with getBoundingClientRect. See comment 3.