fullscreenRequest on "embedding world"

UNCONFIRMED
Unassigned

Status

()

Toolkit
General
UNCONFIRMED
a year ago
a year ago

People

(Reporter: e.jorge, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

Make a DOM element fullscreen using javascript script like :elem.webkitRequestFullScreen, or elem.mozRequestFullScreen or elem.requestFullScreen


Actual results:

Nothing happens.


Expected results:

Unfortunaly for us, nsGlobalWindow::SetFullscreenInternal method, does not allow a requestFullscreen on non-chrome window:

if (mDocShell->ItemType() != nsIDocShellTreeItem::typeChrome)
    return NS_ERROR_FAILURE;

Could you tell me if there is a workaround to intercept fullscreen request on "embedding world" that is, when implementing a IWebBrowserChrome?

Prior to Gecko 41, we was able to intercept fullscreenchange/mozfullscreenchange event using a nsIDOMEventListener (nsIDOMEventListener::HandleEvent), but from Gecko 41, this event is no more triggered...


Regards.
Flags: needinfo?(xidorn+moz)
I'm not the expert on this API, and I don't know the details of your embedding, but I wonder if it's possible to set your root docshell's item type to typeChrome (if you're loading trusted content into it).

In any case, I see that Xidorn has requested needinfo from himself, and perhaps he'll have a better idea.  In the meantime, I'm moving this bug to the Toolkit component, as nsIWebBrowserChrome has recently moved into it.
Component: Embedding: APIs → General
Product: Core → Toolkit
The check of chrome window is a pretty old code which I have no idea what it is designed for. That may worth investigating whether we should keep it around. But I'm not familiar with docshell item type, so probably cannot help there.

Before Gecko 41 we probably fire those events before we actually fullscreen the window, but later it is changed to fire after the change gets done. If your content runs in a content process (XRE_GetProcessType() == GeckoProcessType_Content), you can probably listen to MozDOMFullscreen:Request event from privilege code, but otherwise I guess there is no way to capture that... The best thing you can do, then, is probably to replace Element.prototype.requestFullscreen() etc. with your own hook function.
Flags: needinfo?(xidorn+moz)
(Reporter)

Comment 3

a year ago
Turning process type into GeckoProcessType_Content and setting docShell item type to nsIDocShellTreeItem::typeChrome may produce undefined behaviours.
I'm going to investigate the third proposition, that is, override Element.prototype.requestFullscreen.
You need to log in before you can comment on or make changes to this bug.