*IF* we want fullscreen to be available to all apps without any security UI being displayed (we currently have something less than a prompt, but more than nothing), then while setting up the profile for the XULRunner app, we should set the appropriate settings in the permissions manager. Specifically, we need to set the "fullscreen" permission to nsIPermissionManager.ALLOW_ACTION for the origin of the app.

Lucas: do we want fullscreen to be available to all apps without any security UI being displayed, or do we want some different behavior (f.e. a user prompt)?

Given that we know this bug is causing the full-screen API to not work within the web runtime, should the priority of this bug be increased above a P3?

Nominating for k9o - This is a feature part of gecko that the web runtime needs to support (i.e. the web runtime cannot block functionality that gecko provides).

I think per previous discussions with Jonas we should allow full-screen for all installed apps without a prompt or warning. Note that UX is still trying to reconcile fullscreen mode with security notifications in general, but that's a separate problem.

Marking for re-triage - this is a k9o blocker, and see comment 3 as well. Probably should be at least a P2.

Given the decision to allow fullscreen for all installed apps without authorization by the user, is this bug now a duplicate of bug 760102?

(In reply to Lucas Adamski from comment #5) > Note that UX is still > trying to reconcile fullscreen mode with security notifications in general, > but that's a separate problem. And can you please tell whomever in UX is looking at this to loop me into the discussion? I tried several times to get feedback from UX, but no one gave me any feedback. I found this very frustrating.

Hi Chris, Josh from Gaia UX here. Lucas was kind enough to give me a heads up on this thread. Just an FYI that unfortunately, hours in the day being what they are, no one from our small team is following Bugzilla or dev-b2g threads. So if you want to get UX feedback on an issue, best channel is direct, or dev-gaia. Re: fullscreen, Lucas has it rigt: ". . . we should allow full-screen for all installed apps without a prompt or warning." No prompts for fullscreen.

Thanks for getting in contact Josh, I'll reply directly with some specific questions.

See also bug 760102.

Filepe: Best to hold off working here. I'm currently trying to get consensus from the various stakeholders as to what behaviour we want for fullscreen in apps (and B2G), I'll CC you on that thread. My current proposal is to allow fullscreen in apps (without prompts or warnings) in documents in the app's origin, and behave as normal otherwise. So something like the approach in bug 760102 I think is closer to what we should do rather than setting fullscreen permissions when loading web apps.

Alright, let me know when to proceed. Is there a new patch coming for bug 760102? The current patch there (with r+) is more distant from what you propose afaict, as IsPartOfApp() doesn't seem to take into account the document uri. Also it's more targeted to b2g where things are running in an hierarchy of frames, whereas on desktop we have a separate profile so setting the fullscreen permission for the app's domain is easy and will get the exact behavior you propose.

(In reply to Felipe Gomes (:felipe) from comment #13) > setting the fullscreen permission for the app's domain is easy and will get > the exact behavior you propose. I hadn't read the thread before posting, I see there's still discussion on what is the permission scope (the domain or something else)

Could we possibly implement a short-term fix to at least enable full-screen per Jonas's originally spec and have a follow-up item to address the issues Chris has brought up? Talking in the triage today, it's better to have something than not have anything, as right now, full-screen does not work at all in the desktop runtime. And we need to make the FF 16 train this time.

(In reply to Jason Smith [:jsmith] from comment #15) > Could we possibly implement a short-term fix to at least enable full-screen > per Jonas's originally spec and have a follow-up item to address the issues > Chris has brought up? Talking in the triage today, it's better to have > something than not have anything, as right now, full-screen does not work at > all in the desktop runtime. And we need to make the FF 16 train this time. Oh, change that. I see Chris has a patch out in bug 760102 to solve this problem.

Duping against the underlying bug where the tracking is going on.