Fullscreen API bug fixes

[Ali Alabbas]

Hello Matt,

 

I heard that you were in the know when it came to the fullscreen API for Chrome. So hopefully this e-mail is relevant to you, if not I would appreciate it if you could direct me to the right person.

 

The IE team has been looking at the interoperability of the fullscreen API, especially how fullscreen elements are styled and displayed. We noticed that Chromium does not quite follow the spec in this area – for example, if the width/height are specified on the fullscreen element it will respect those styles and cause the fullscreen element to be centered.

 

We were curious whether there are any plans to align Chromium’s implementation with the spec? We didn’t notice anything on crbug that implies things will be changing, but wanted to double-check as this is an area we’re looking into improving IE’s interoperability and we don’t want move in the wrong direction.

 

Thank you,

Ali

[Ali Alabbas]

​Ping?

---

From: Ali Alabbas
Sent: Monday, December 1, 2014 10:08 AM
To: fal...@chromium.org
Cc: Jacob Rossi; blin...@chromium.org
Subject: Fullscreen API bug fixes

 

[Jochen Eisinger]

Hey

sorry for the delay.

As far as I know, nobody is actively working on this part of the fullscreen API currently. I would expect that WebKit has the same differences from the spec as blink has? If not, we could try to port the changes over.

best

-jochen

[Matt Falkenhagen]

Hi Ali,

Sorry I missed this mail and thanks for reaching out. You are right that Chrome's fullscreen implementation has some layout behavior that doesn't match the spec. But I think the goal is still to match the spec. Last year I attempted to do so, particularly by implementing the "top layer" part of the spec. The intent to ship is here:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/yJUanvg7d40/UungudcjD-UJ

Unfortunately, nothing actually shipped, as I wasn't able to make the changes without regressing behavior with plugins (http://crbug.com/240576). But since then Philip Jägenstedt and Julien Chaffraix seem to be working on Fullscreen. They may have more information.

[Julien Chaffraix]

Hey Ali,

Sorry for the delay, I was in the process of understanding our implementation.

> Sorry I missed this mail and thanks for reaching out. You are right that
> Chrome's fullscreen implementation has some layout behavior that doesn't
> match the spec. But I think the goal is still to match the spec. Last year I
> attempted to do so, particularly by implementing the "top layer" part of the
> spec. The intent to ship is here:
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/yJUanvg7d40/UungudcjD-UJ
>
> Unfortunately, nothing actually shipped, as I wasn't able to make the
> changes without regressing behavior with plugins (http://crbug.com/240576).
> But since then Philip Jägenstedt and Julien Chaffraix seem to be working on
> Fullscreen. They may have more information.

Matt is right about reviving the old patch, I still have a couple of
failures from the change but it's looking fine so far. This change
should align our implementation with the specification: we should use
top layer and follow what the specification puts into the UA
stylesheet.

Outside that effort, I don't think anyone is actively looking at
improving the interoperability of our implementation.

Thanks,
Julien

[Philip Jägenstedt]

I have unfinished work on syncing with the spec in order to unprefix
the Fullscreen API, which I've been meaning to pick up for a few
months now. My focus there was mostly the DOM API and the event
timing, I haven't yet in detail at the CSS changes because I realized
they'll need to move fullscreen to the top layer.

Ali, is the specific problem you'd like to see addressed the
"*|*:not(:root):fullscreen { width:100% !important; height:100%
!important; }" bit of the spec? We already force width and height to
100% for video:-webkit-full-screen, audio:-webkit-full-screen and
iframe:-webkit-full-screen, so doing it for all elements seems likely
to work out, Web-compat-wise. It's a rather trivial change that I
think could be attempted even before :fullscreen is added as an alias
of :-webkit-full-screen, because in practice things will be painful if
the styles for those two aren't the same.

Are there any other incompatibilities you've found? Anything
non-trivial should probably block unprefixing
<https://crbug.com/383813> to avoid making the interop mess worse than
it already is.

Philip

[Ali Alabbas]

Hi Philip and team,

Thank you for all the comments and attention to this topic. We are pleased to hear that you are moving in this direction and we hope to do the same with the prospect of a more interoperable Fullscreen API.

Philip, to answer your first question, that seems to be correct understanding of the underlying issue. As for your second question, I will look more into other interoperability issues we've encountered with Chrome and report back if I can think of or find any.

Thank you,
Ali

[Philip Jägenstedt]

Hi Ali,

The very good news is that Julien has submitted a CL to move
fullscreen to the top layer, which fixes the size/centering problem:
https://codereview.chromium.org/788073004/

Please let us know if there's any other non-standard behavior in
fullscreen (or anywhere else) that's causing particular trouble for
you.

Philip

> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

By the way, this sounds like you are changing the behavior (to the standardized one, which is good! :)). Is it only for the standard API, or is the vendor prefixed API affected as well (no centering anymore)? If the latter, it should be announced somewhere (and YouTube/other known users should be noted).

☆PhistucK

[Julien Chaffraix]

On Tue, Dec 16, 2014 at 2:42 AM, PhistucK <phis...@gmail.com> wrote:
> By the way, this sounds like you are changing the behavior (to the
> standardized one, which is good! :)). Is it only for the standard API, or is
> the vendor prefixed API affected as well (no centering anymore)? If the
> latter, it should be announced somewhere (and YouTube/other known users
> should be noted).

It will be all usage of fullscreen.

The new change is covered under [1] as it's basically the same change.
The change has quite some history and hopefully we can land it for
good (but it's stuck on re-attaching plugins, which I thought solved
since the change landed). The change won't impact <video> dramatically
as we include a styling similar to what specification mandates for all
elements for <video> ATM [2]. It definitely has some potential impact
for non-video cases so I will make sure it will get noted in Chrome's
release notes.

Julien

[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/yJUanvg7d40
[2] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/fullscreen.css&q=fullscreen.css&sq=package:chromium&type=cs&l=24

[Ali Alabbas]

I was just wondering if anyone from the Chrome dev team has an update on fixing "*|*:not(:root):fullscreen { width:100% !important; height:100% !important; }" for the Fullscreen API? Is this still being planned to be fixed in Chrome in the near future or has this work been delayed?

Also, I found that in Chrome webkitCurrentFullScreenElement is not the same as webkitFullscreenElement. The differences are:
- webkitCurrentFullScreenElement is updated when firing the fullscreen change event, so it is updated asynchronously, while webkitFullscreenElement is updated synchronously
- webkitCurrentFullScreenElement always returns the fullscreen element in the primary markup

These differences make for some strange behavior. There are several bugs for fixing the differences in Chrome:
- https://code.google.com/p/chromium/issues/detail?id=402421
- https://code.google.com/p/chromium/issues/detail?id=396575 (Actual tracking bug: https://code.google.com/p/chromium/issues/detail?id=402376)

Would you say there is a plan for making webkitCurrentFullScreenElement an alias of webkitFullscreenElement in the near future?

Thank you,
Ali

-----Original Message-----
From: jchaf...@google.com [mailto:jchaf...@google.com] On Behalf Of Julien Chaffraix
Sent: Tuesday, December 16, 2014 8:22 AM
To: PhistucK
Cc: Philip Jägenstedt; Ali Alabbas; Matt Falkenhagen; Jochen Eisinger; Jacob Rossi; blin...@chromium.org; Israel Hilerio
Subject: Re: [blink-dev] Re: Fullscreen API bug fixes

[Philip Jägenstedt]

Hi Ali,

I'm not on the Chrome team, but anyway:

On Sun, Feb 15, 2015 at 11:20 AM, Ali Alabbas <al...@microsoft.com> wrote:
>
> I was just wondering if anyone from the Chrome dev team has an update on fixing "*|*:not(:root):fullscreen { width:100% !important; height:100% !important; }" for the Fullscreen API? Is this still being planned to be fixed in Chrome in the near future or has this work been delayed?

This would be https://codereview.chromium.org/788073004/ which I hope
can land soonish. If that isn't possible, the width/height fix could
be done separately. Do you know of any compat problems that could
arise, or are you "just" tracking all differences?

> Also, I found that in Chrome webkitCurrentFullScreenElement is not the same as webkitFullscreenElement. The differences are:
> - webkitCurrentFullScreenElement is updated when firing the fullscreen change event, so it is updated asynchronously, while webkitFullscreenElement is updated synchronously
> - webkitCurrentFullScreenElement always returns the fullscreen element in the primary markup
>
> These differences make for some strange behavior. There are several bugs for fixing the differences in Chrome:
> - https://code.google.com/p/chromium/issues/detail?id=402421
> - https://code.google.com/p/chromium/issues/detail?id=396575 (Actual tracking bug: https://code.google.com/p/chromium/issues/detail?id=402376)
>
> Would you say there is a plan for making webkitCurrentFullScreenElement an alias of webkitFullscreenElement in the near future?

Yes, this is a pretty terrible, and something I am still hoping to
(continue to) work on as part of a spec sync prior to shipping the
unprefixed API. While the difference is observable to Web content, it
shouldn't be observable in the most obvious ways of using the API,
i.e. when checking these properties before requesting fullscreen or in
the fullscreenchange event. Is there a specific problem you're having
with this discrepancy? If so that could also be prioritized.

Philip

[Julien Chaffraix]

On Mon, Feb 16, 2015 at 3:13 AM, Philip Jägenstedt <phi...@opera.com> wrote:
> Hi Ali,
>
> I'm not on the Chrome team, but anyway:
>
> On Sun, Feb 15, 2015 at 11:20 AM, Ali Alabbas <al...@microsoft.com> wrote:
>>
>> I was just wondering if anyone from the Chrome dev team has an update on fixing "*|*:not(:root):fullscreen { width:100% !important; height:100% !important; }" for the Fullscreen API? Is this still being planned to be fixed in Chrome in the near future or has this work been delayed?
>
> This would be https://codereview.chromium.org/788073004/ which I hope
> can land soonish.

Unfortunately this change is stuck on another bug: switching renderers
to top layer will reattach plugins, which makes them restart. I
wrongly thought that this bug was fixed when I updated an earlier
change. We know the solution to the issue (we need to keep the plugins
around during reattaching) but I haven't made much progress on that.
https://codereview.chromium.org/23618022 was a good start but some
testing showed that it breaks some plugins so it's not a good basis
for the work.

> If that isn't possible, the width/height fix could
> be done separately. Do you know of any compat problems that could
> arise, or are you "just" tracking all differences?

I haven't heard data about the potential for damage from that. We were
already on board with doing the change but it would be unfortunate not
to fix our flex-box based implementation as it will probably yield to
other incompatibilities.

Julien

[Ali Alabbas]

Julien, thank you for your response and update! At the moment, I'm tracking the work item (https://codereview.chromium.org/788073004/) to know if it's still part of your near future plans. The sooner it can be done, the better it would be to help with interoperability. As you mentioned, it looks like this is being held up by changes to fix another bug, so perhaps it would make sense to incorporate the change separately?

Philip, as for the discussion on webkitCurrentFullScreenElement and webkitFullscreenElement, I don't have a specific problem with the discrepancy, I was just wondering if there is an eventual plan to make the two behave and return the same element. We are trying to support the webkit-prefixed fullscreen APIs and wanted to know if it would be make sense to make webkitCurrentFullScreenElement as an alias of webkitFullscreenElement with the future in mind.

Thank you,
Ali

-----Original Message-----
From: jchaf...@google.com [mailto:jchaf...@google.com] On Behalf Of Julien Chaffraix
Sent: Wednesday, February 25, 2015 4:53 PM
To: Philip Jägenstedt
Cc: Ali Alabbas; PhistucK; Matt Falkenhagen; Jochen Eisinger; Jacob Rossi; blin...@chromium.org; Israel Hilerio
Subject: Re: [blink-dev] Re: Fullscreen API bug fixes

[Philip Jägenstedt]

Hi again Ali,

I agree, it would make sense to make some of these fixes without
waiting for the larger move to top layer. Next week I'll do things:

1. Move width/height (including min/max) up to :-webkit-full-screen.
Shipping :fullscreen would be even better, but small steps I guess.
2. Take another look at webkitCurrentFullScreenElement vs.
webkitFullscreenElement. If it seems safe enough I'll try to alias
them immediately, otherwise I'll add a UseCounter to see how often the
discrepancy is observed on actual Web content.

Let us know if you have any other issues!

Phiip

[Ali Alabbas]

Awesome, thank you for driving this effort Philip!

-----Original Message-----
From: Philip Jägenstedt [mailto:phi...@opera.com]

[Philip Jägenstedt]

A small update on these issues.

The width/height issue has been resolved by making our Fullscreen UA style sheet a lot more similar to the spec:

https://codereview.chromium.org/974783002

Notably, we still only support :-webkit-full-screen, implementing :fullscreen and actually shipping it is tracked by:

• Add the :fullscreen pseudo-class and UA style sheet
• Unprefix the Fullscreen API

As for the difference webkitCurrentFullScreenElement and webkitFullscreenElement, I came to the conclusion that neither is sufficiently similar to the spec to make the other an alias. This is the situation:

• Per spec, Document.fullscreenElement (the top of the fullscreen element stack) is updated right before the first animation frame after the viewport has been resized. This makes good sense.
• Document.webkitFullscreenElement is the top of the fullscreen element stack, but the fullscreen element stack is updated synchronously in webkitRequestFullscreen().
• Document.webkitCurrentFullScreenElement is updated when the viewport has been resized without synchronizing with the next animation frame. It's maintained separately from the fullscreen element stack, so they disagree in the interim.

The relevant bugs:

• Make Document.webkitCurrentFullScreenElement an alias of Document.fullscreenElement
  
• The fullscreenchange event should be synchronized with animation frames
  
• Sync requestFullscreen() and exitFullscreen() with the spec
  

I would like to get back on track working towards shipping the unprefixed Fullscreen API, and these issues are the next to tackle. If anyone wants to work on this that would be awesome, otherwise I'll make it my priority within a few months.

Philip

[Philip Jägenstedt]

Oops, I linked to the wrong bug, this is the "Unprefix the Fullscreen
API" tracking bug:
https://code.google.com/p/chromium/issues/detail?id=383813

The plan is to work through the blocking bugs and then ship the
unprefixed Fullscreen API, but I dare not suggest a date for shipping.
I hope that the only difference between the prefixed and unprefixed
API will be the events. Unfortunately this isn't limited to the name
of the events, the prefixed events are also fired at the element
instead of the document, and they bubble.

I'm not sure whether or not shipping should be blocked on the top layer rewrite:
https://codereview.chromium.org/788073004/

Without it we can't support the :fullscreen::backdrop bit of the
Fullscreen UA style sheet, but it's proven hard to fix so far.

Once we manage to ship the unprefixed Fullscreen API, trying to get
rid of the prefixed one will be a lot of work too. If the event target
turns out to be a big part of the problem, we should consider changing
the spec instead I think.

Philip

On Tue, Mar 17, 2015 at 6:04 AM, Ali Alabbas <al...@microsoft.com> wrote:
> What is the plan for implementing unprefixed fullscreenElement? Also, will
> you be changing the behavior of webkitFullscreenElement? Developers
> currently follow the pattern of checking for the unprefixed Fullscreen API
> and using the prefixed version if it is unavailable. Having different
> behavior between the two will cause inconsistency when checking for the
> fullscreen element right after the fullscreen request is made.
>
>
>
> Thanks,
>
> Ali

[Ali Alabbas]

Hi Philip,

Thank you for all the insight you've provided!

I was wondering if you were aware of an issue where a video is allowed to go into fullscreen in an iframe regardless if the allowfullscreen attribute is specified. This means that if allowfullscreen is not set, a video in an iframe can still go to fullscreen. This appears to be different from what the spec defines as the behavior for allowfullscreen.

Thanks,
Ali

[Philip Jägenstedt]

For anyone finding this thread later, the question of the
allowfullscreen exemption was continued in a separate Intent to Remove
that exemption:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/3NukIuOaU4c

[Ali Alabbas]

Hi Philip,

Thank you for taking care of that!

We seem to have found another issue: It appears that CSS transforms (e.g. -webkit-transform) do not apply on elements that are fullscreened. The spec doesn’t seem to explicitly mention this to be the expected behavior. Do you happen to know if this behavior is intended and if it will continue to be this way, or do you expect that this will be changed in the near future?

[Ali Alabbas]

Hi Philip,

I just wanted to follow-up on this: it seems that transforms specifically do not work on <video> when they are fullscreened. Do you know if this behavior is intended, or will it be changed in the near future?

Thanks,
Ali

-----Original Message-----
From: Ali Alabbas
Sent: Tuesday, April 14, 2015 10:06 AM
To: 'Philip Jägenstedt'
Cc: Julien Chaffraix; PhistucK; Matt Falkenhagen; Jochen Eisinger; Jacob Rossi; blin...@chromium.org; Israel Hilerio

Subject: RE: [blink-dev] Re: Fullscreen API bug fixes

Hi Philip,

Thank you for taking care of that!

We seem to have found another issue: It appears that CSS transforms (e.g. -webkit-transform) do not apply on elements that are fullscreened. The spec doesn’t seem to explicitly mention this to be the expected behavior. Do you happen to know if this behavior is intended and if it will continue to be this way, or do you expect that this will be changed in the near future?

[Philip Jägenstedt]

Hi Ali,

The transform:none is part of the Fullscreen UA style sheet:

https://fullscreen.spec.whatwg.org/#user-agent-level-style-sheet-defaults

That is a fairly recent change, so make sure you're not looking at a snapshot of the spec since this is not the only recent change.

Also, some bad news. My changes to the Fullscreen UA style sheet caused a number of regressions and I wasn't able to fix all of them quickly, so I reverted the changes until I get the time to investigate those issues:

https://codereview.chromium.org/1058083003/

Philip