Deny HTML fullscreen requests on display:none elements

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
7 years ago
7 years ago

People

(Reporter: cpearce, Unassigned)

Tracking

11 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

We should really deny fullscreen requests from elements that are display:none...
What do you want to do in the case of a fullscreen element, which wasn't display:none, being changed to display:none?  Drop out of fullscreen?
I don't think we should change this. There are lots of ways to make invisible elements fullscreen or otherwise do things that "don't make sense", and it's futile, complicated and confusing to try to prevent them.

We don't allow elements not in the document to be fullscreen, because that lets us GC elements that are accessible only through the fullscreen stack, but let's leave it at that.
I hit a version of this today doing Pointer Lock, where an element was in fullscreen with display:none, but since I needed its frame, I crashed trying to access it.  smaug suggested that we simply refuse to lock if the element has no frame, and guard against assuming it exists.
(Reporter)

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
(In reply to David Humphrey (:humph) from comment #3)
> I hit a version of this today doing Pointer Lock, where an element was in
> fullscreen with display:none, but since I needed its frame, I crashed trying
> to access it.  smaug suggested that we simply refuse to lock if the element
> has no frame, and guard against assuming it exists.

What do you need its frame for?
For mouse coords within it.
Do you need its size or just its position?
I'm basically doing this:

in content/events/src/nsEventStateManager.cpp

nsIntPoint
nsEventStateManager::GetMouseCoords()
{
  NS_ASSERTION(sPointerLockedElement, "sPointerLockedElement is null in GetMouseCoords!");

  nsIFrame* frame = sPointerLockedElement->GetPrimaryFrame();
  NS_ASSERTION(frame, "sPointerLockedElement->GetPrimaryFrame() was null!");

  nsIntRect screenRect = frame->GetScreenRect();

  return nsIntPoint((screenRect.width/2) + screenRect.x,
                    (screenRect.height/2) + screenRect.y);
}
I don't think you really want to drop the pointer lock just because the element or one of its ancestors became display:none (possibly temporarily). That's some work to detect, and actually falls down badly if the author does something like this:
  element.style.display = 'none';
  element.style.display = 'block';
In all browsers, style resolution is lazy so we won't detect that the element went through a state of being 'display:none'. But it's undefined what actually triggers style resolution (and different browsers differ), so you won't be able to define exactly under what circumstances the pointer lock would be lost.

In your code above, do you really intend to ignore all but the first frame? E.g. if an element breaks horizontally (line breaking) or vertically (column breaking), do you want to take all parts of the element into account? I think the best way forward here would be to define this in terms of getBoundingClientRect: http://dev.w3.org/csswg/cssom-view/#the-getclientrects-and-getboundingclientrect-methods
That means a display:none element would be treated as being a 0x0 box at the top-left of its document's viewport.

BTW, what do you want to happen if the element is transformed or perhaps even in a document in a transformed IFRAME? You probably want to take the transform into account.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #8)
> I don't think you really want to drop the pointer lock just because the
> element or one of its ancestors became display:none (possibly temporarily).
Locking for example <head> doesn't make much sense to me.
Mouse events go only to visibly elements. Why should locking change that?

Perhaps locking should work in document level, not element level.
(In reply to Olli Pettay [:smaug] from comment #9)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #8)
> > I don't think you really want to drop the pointer lock just because the
> > element or one of its ancestors became display:none (possibly temporarily).
> Locking for example <head> doesn't make much sense to me.

The problem is, if we add special cases just to catch things that "don't make sense", we could add complexity to the Web platform for no real benefit.

> Mouse events go only to visibly elements. Why should locking change that?

Well, the whole point of locking is to make mouse events go where they wouldn't normally go :-).

> Perhaps locking should work in document level, not element level.

Maybe.
You need to log in before you can comment on or make changes to this bug.