We should log messages to console when we deny requests for full-screen with the DOM full-screen API, and why full-screen has been exited. This will make it easier for developers to figure out why it's not working. Use nsContentUtils::ReportToConsole() to log messages to console, add messages to http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/dom/dom.properties so they can be localized. Not sure how to ensure they are actually localized yet though.

(In reply to Chris Pearce (:cpearce) (Mozilla Corporation) from comment #0) > Use nsContentUtils::ReportToConsole() to log messages to console, add > messages to > http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/dom/ > dom.properties so they can be localized. Not sure how to ensure they are > actually localized yet though. If we add something to that file, the l10n teams will see it in there dashboards.

Log error messages to console to describe why a request for full-screen was denied, and also when we drop out of full-screen mode due to adding a windowed plugin or removing the full-screen element from document.

Comment on attachment 574756 [details] [diff] [review] Patch v1 Replace "user pref" with "user preference" and looks good.

A couple of doubts about these strings FullScreenDeniedIframeDisallowed=Request for full-screen was denied because at least one of the document's containing iframes does not have a "mozallowfullscreen" attribute. I'm not sure about that "containing". Is "document's contaning frames" equal to "frames contained in the document"? FullScreenDeniedNotInputDriven=Request for full-screen was denied because Element.mozRequestFullScreen() was not called from inside a short running user-generated event handler. Can someone explain to a non developer the meaning of the last part of this sentence?

Thanks for looking at this. These strings are supposed to help developers, rather than end-users, so will be a bit more technical in nature. (In reply to flod (Francesco Lodolo) from comment #6) > A couple of doubts about these strings > > FullScreenDeniedIframeDisallowed=Request for full-screen was denied because > at least one of the document's containing iframes does not have a > "mozallowfullscreen" attribute. > > I'm not sure about that "containing". Is "document's contaning frames" equal > to "frames contained in the document"? No. The "document's contaning frames" are the iframes which contain/surround the document (the document's parent/ancestors), and the "frames contained in the document" are the iframes which are contained/surrounded *by* the document (the document's children and descendents). It's kind of like boxes inside boxes. When you open a box, it can contain another box, which in turn can contain another box, etc, but in this instance we're talking about documents (web pages) instead of boxes. Take a look at my page at http://pearce.org.nz/full-screen/ . The bit of the web page with a light blue background is the main "document", and the region with a scroll bar and a red background is an iframe which is contained by the blue document. Everything inside the scroll bar is the red document. The red document in turn contains an iframe with a scroll bar and a yellow background which is another document. This yellow document is contained by the red document. Hopefully that makes contained/containing a bit clearer. > FullScreenDeniedNotInputDriven=Request for full-screen was denied because > Element.mozRequestFullScreen() was not called from inside a short running > user-generated event handler. > > Can someone explain to a non developer the meaning of the last part of this > sentence? Requests for full-screen are only granted when they're requested while running in a user-generated event handler. A user generated event handler is a bit of code which runs when the users performs some input, like clicking a mouse button, or pressing a key on the keyboard. If the code in the event handler runs for more than one second before requesting full-screen, the request is also denied. Let me know if you have any more questions.

Thanks a lot Chris, a lot clearer now ;-)

Another localizer question. FullScreenDeniedMovedDocument=Request for full-screen was denied because requesting element has moved document. What does it mean that an element "has moved document"? The code that logs this message has this condition: if (aElement->OwnerDoc() != this)

(In reply to Marek Stępień :marcoos from comment #9) > What does it mean that an element "has moved document"? It means the region of page which was full-screen has been taken out of the web page and moved into another web page (or sub-web page). For example in my page at http://pearce.org.nz/full-screen/ if the video (which is in the blue web page ("document")) was made full-screen, but script moved the video into the red or yellow sub-web-page ("subdocument"), we will exit full-screen.

The following error is being fired on Fennec 14.0 (Android, Tablet) in the absolutely correct situation (e.g. it works on desktop Firefox and full-screen mode is requested on user click). Can be replicated on the above mentioned page as well: http://pearce.org.nz/full-screen/ "Request for full-screen was denied because Element.mozRequestFullScreen() was not called from inside a short running user-generated event handler."

Oleksly: Thanks for letting us know. Fullscreen works fine for me on "Fennec Native" Firefox 15 (i.e. Firefox on Android *phones*). On tablets we're using "XUL" builds, not Fennec Native. We're going to move from XUL to Fennec Native for tablets in Firefox 15. So since fullscreen works on Fennec Native we can probably assume fullscreen should work on tablets once 15 ships, so please can you either test a Nightly build (which should be using Native), or wait for Firefox 15 and then retest then?

Hi Chris, Have tried with Firefox 15 and noticed that it works fine for registered 'click' event and fails with the message above for 'touchstart' event. Is it correct?

My guess is that we're not reporting 'touch' events as user-generated. It seems intuitive that we should... I filed bug 779324 for this issue.