Closed Bug 1285964 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: Canvas: 2D, defect, P2)

46 Branch
x86_64
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla50
Tracking Status
firefox50 --- fixed

People

(Reporter: griffing, Assigned: xidorn)

Details

(Keywords: testcase, Whiteboard: [gfx-noted])

Attachments

(3 files)

Attached image 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.
OS: Unspecified → Windows
Hardware: Unspecified → x86_64
Priority: -- → P2
Could you attach a testcase and detail the steps to reproduce, please?
Flags: needinfo?(griffing)
Keywords: testcase-wanted
Component: Untriaged → Canvas: 2D
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?
Flags: needinfo?(griffing) → needinfo?(xidorn+moz)
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
Flags: needinfo?(xidorn+moz)
Not a perfect duplication of my issue, but close.  Will log top/left coordinates.
Changing the summary of this bug to reflect what I'm going to do here.
Summary: FF v46 no longer stretches screen when in fullscreen; getBoundingClientRect wrong? → Allow author specify different object-fit value for fullscreen element
Summary: Allow author specify different object-fit value for fullscreen element → Allow author to specify different object-fit value for fullscreen element
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.)
Attachment #8770775 - Flags: review?(cam) → review+
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.
Flags: needinfo?(annevk)
And yes, the page author will still need to opt in to get a stretched <canvas>.
Assignee: nobody → xidorn+moz
Status: UNCONFIRMED → NEW
Ever confirmed: true
Go ahead, I'll update the standard per your issue.
Flags: needinfo?(annevk)
Pushed by xquan@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c6d15a3e7637
Remove !important from object-fit for fullscreen element. r=heycam
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?
(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.
https://hg.mozilla.org/mozilla-central/rev/c6d15a3e7637
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
If the fix could be uplifted to mozilla49 (or earlier) it would be great.
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?
Status: RESOLVED → VERIFIED
There is no issue with getBoundingClientRect. See comment 3.
You need to log in before you can comment on or make changes to this bug.