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.
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.