Closed Bug 768561 Opened 12 years ago Closed 12 years ago

Prevent windows opened by <iframe mozapp>'s window.open from going full-screen

Categories

(Firefox OS Graveyard :: General, defect, P2)

Product:
Firefox OS Graveyard
Component:
General
Type:
defect

Tracking

(blocking-kilimanjaro:+)

Status:
RESOLVED WONTFIX
Project Flags:
blocking-kilimanjaro +

People

(Reporter: justin.lebar+bug, Unassigned)

References

Details

Suppose an <iframe mozapp> calls window.open.  We show a new window as an <iframe mozapp> which sits above the original iframe.  The new window has an X button, so it can be closed.

That new window had better not go full-screen, otherwise we can't close it!  Note that the window runs with all the permissions of the app, so it has full-screen permission, with no prompts.

We could solve this by adding a "nofullscreen" attribute to the mozapp that the embedder can set as appropriate.  Or we could hardcode this mozapp popup --> no fullscreen limitation into Gecko.  I think the former is probably better.
Blocks: 742944
OS: Mac OS X → All
Hardware: x86 → All
Depends on: 684620
How about not setting mozallowfullscreen on the new app window? Provided we don't allow mozapp to override mozallowfullscreen this should work?
I really have no idea how this particular permission works at the moment, so perhaps you can educate me!

Our goal is for app permissions to only be in effect when the app is at its "natural" origin.  For example, if I have <iframe mozapp="http://my.manifest.co"> at a my.manifest origin, then it has no-prompt full-screen privileges, but if it navigates to evil.com, it would no longer have that privilege.  (Yes, the plan is that <iframe mozapp> can navigate away from its "natural" origin without spawning a popup window.  Bizarre, I know...)

Anyway, is mozallowfullscreen a permission on top of this per-origin permission?  That is, if an iframe doesn't have mozallowfullscreen set on it, nothing inside the iframe can go full-screen, regardless of its origin?  If so, that would work.

How would mozapp potentially override this?
I think we should give permissions to go fullscreen to the the tuple {app, origin} when the app is installed. For the moment, it is not the case but that has to be fixed.
For the window.open() behavior, you want to prevent those popups to go fullscreen even if they are in the the app origin?
Comment 1 doesn't work. You can peal the full screen property of the outer window and pass it to JS in the dialog since its same origin. You have to do the security check inside the full screen function or setter.
> For the window.open() behavior, you want to prevent those popups to go fullscreen even if they are in
> the the app origin?

Yes, ideally.  The system application is drawing the "chrome" here (a close button for the popup, etc), so I don't think the popup should be able to override that.
(In reply to Justin Lebar [:jlebar] from comment #2)
> That is, if an iframe doesn't have mozallowfullscreen set on
> it, nothing inside the iframe can go full-screen, regardless of its origin? 

Yes, if any of the iframes containing the document in which contains the element which is requesting iframe doesn't have the mozallowfullscreen attribute the fullscreen request is denied.

Actually the current requestFullscreen code ignores this check for apps, but we can easily put it back in.


(In reply to Andreas Gal :gal from comment #4)
> Comment 1 doesn't work. You can peal the full screen property of the outer
> window and pass it to JS in the dialog since its same origin. You have to do
> the security check inside the full screen function or setter.

I don't understand what you mean by "pealing the fullscreen property..."... window.fullscreen can only be set inside chrome code, do apps' window.open() windows run with chrome privileges?

...

Hmm, we should probably propagate the mozallowfullscreen attribute across BrowserElement{Parent,Child} boundaries (like we do for the visibility state), so that cross-process subframes can know whether they're allowed to go fullscreen or not...
blocking-basecamp: --- → ?
Security issue, so blocking.
blocking-basecamp: ? → +
Priority: -- → P2
Renom if you think we can't ship a v1 without this.
blocking-basecamp: + → ---
blocking-kilimanjaro: --- → +
(In reply to Andreas Gal :gal from comment #8)
> Renom if you think we can't ship a v1 without this.

I'd generally suggest that if you disagree with a "blocking-basecamp" flag to please set the basecamp flag to a ? mark again for re-triage. Don't unnom it, as we'll lose track of bugs. If we lose that nomination flag, we're bound to thrash on confusion of we originally made decisions on, some of which were very recent.

Different teams also make use of the priority flag in different ways, so I'd find another way to flag "soft-blockers."
blocking-basecamp: --- → ?
Do we have anything like on desktop that asks the user if they're okay with pages requesting fullscreen?
I think this will actually magically work properly once we fix bug 781620.

Then, with the code I just landed in bug 777135, you won't be able to go full-screen if you're within an app but not on the app's origin.
Depends on: 781620, 777135
(In reply to Andrew Overholt [:overholt] from comment #10)
> Do we have anything like on desktop that asks the user if they're okay with
> pages requesting fullscreen?

Yes, I have UI to approve non-app-origin fullscreen requests in Gaia waiting to be merged in https://github.com/mozilla-b2g/gaia/pull/3200 .
So it sounds like this is WONTFIX then. Since we'll have UI allowing the user to break out of fullscreen if this happens out of the blue.

Please reopen and renominate if I'm misunderstanding or otherwise wrong.
Status: NEW → RESOLVED
blocking-basecamp: ? → ---
Closed: 12 years ago
Resolution: --- → WONTFIX
(In reply to Justin Lebar [:jlebar] from comment #11)
> I think this will actually magically work properly once we fix bug 781620.
> 
> Then, with the code I just landed in bug 777135, you won't be able to go
> full-screen if you're within an app but not on the app's origin.

Justin - can you please confirm that the functionality would be as follows
1. MyApp has mozallowfullscreen in MyApp.manifest (i.e. application is allowed full-screen)
2. MyApp has an iFrame (call it iFrame-1) with the 'natural state' set to the app's url (say http://myapp.gaiamobile.org)
3. If iFrame-1, while still in its 'natural state' now requests a full-screen (overlapping myapp's main window), that permission is granted and iFrame-1 can go full-screen
3.1 Question: How does the user close this iFrame-1? Pressing 'Home' will close the iFrame-1 or the MyApp?
4. Now, if the iFrame-1 was tricked to leave its natural state and go to evil.com, which triggers a full-screen, then that request will be denied - right? 
4.1 Will the user be notified of this denial?
4.2 What are the default permissions that iFrame-1 will now have once it is on evil.com? Any visual notification to the user that something is not right? I think it will be good to create one for it
5. Hypothetically, if the iFrame-1 had another iFrame, iFrame-2 will the permissions percolate downwards like a parent-child permission inheritance?

P.S: If this had to go the webapp's list, please let me know; wanted to enlist the possible use-cases and so added to the bug entry.
> 3.1 Question: How does the user close this iFrame-1? Pressing 'Home' will close the iFrame-1 or the 
> MyApp?

I don't understand what you mean; you can't "close" an iframe.

Do you mean, how does the user escape full-screen?  You can press the home button.  I expect that would exit the app.

> 4. Now, if the iFrame-1 was tricked to leave its natural state and go to evil.com, which triggers a 
> full-screen, then that request will be denied - right? 

See 4.1.

> 4.1 Will the user be notified of this denial?

If we're at evil.com, then it's just like a normal webpage (e.g. youtube.com) going full-screen.  It actually goes full-screen, and then you have the option to cancel.

> 4.2 What are the default permissions that iFrame-1 will now have once it is on evil.com? Any 
> visual notification to the user that something is not right? I think it will be good to create one 
> for it

It's just like youtube.com or any other website using the full-screen API, at this point.

> 5. Hypothetically, if the iFrame-1 had another iFrame, iFrame-2 will the permissions percolate 
> downwards like a parent-child permission inheritance?

You have permission if you're on an app origin, regardless of who your parent is.

But unprivileged content should not be able to load content from app://.  That means that you only have permission if there's an unbroken app:// chain from the top-level frame down to you.
Thanks for the responses Justin. Answers inline

(In reply to Justin Lebar [:jlebar] from comment #15)
> > 3.1 Question: How does the user close this iFrame-1? Pressing 'Home' will close the iFrame-1 or the 
> > MyApp?
> 
> I don't understand what you mean; you can't "close" an iframe.
> 
> Do you mean, how does the user escape full-screen?  You can press the home
> button.  I expect that would exit the app.

Yes, I meant escape full-screen. So, the only way out for a user out of a full-screen iFrame is to exit the application - is that right? If so, this can go into the gaia guidelines, so that developers building applications for full-screen are aware of the implications (they can provide the required UI mechanisms to notify users when the home key is pressed).

> 
> > 4. Now, if the iFrame-1 was tricked to leave its natural state and go to evil.com, which triggers a 
> > full-screen, then that request will be denied - right? 
> 
> See 4.1.
> 
> > 4.1 Will the user be notified of this denial?
> 
> If we're at evil.com, then it's just like a normal webpage (e.g.
> youtube.com) going full-screen.  It actually goes full-screen, and then you
> have the option to cancel.

You mentioned this 
"For example, if I have <iframe mozapp="http://my.manifest.co"> at a my.manifest origin, then it has no-prompt full-screen privileges, but if it navigates to evil.com, it would no longer have that privilege."
So, my question was regarding the privileges that are available for the iFrame once it navigates away from the 'natural state'. Also, by 'natural state' I'm assuming the home URL for the webapp (for eg., an iFrame for maps.google.com navigating to maps.bing.com)

> 
> > 4.2 What are the default permissions that iFrame-1 will now have once it is on evil.com? Any 
> > visual notification to the user that something is not right? I think it will be good to create one 
> > for it
> 
> It's just like youtube.com or any other website using the full-screen API,
> at this point.
> 
> > 5. Hypothetically, if the iFrame-1 had another iFrame, iFrame-2 will the permissions percolate 
> > downwards like a parent-child permission inheritance?
> 
> You have permission if you're on an app origin, regardless of who your
> parent is.
> 
> But unprivileged content should not be able to load content from app://. 
> That means that you only have permission if there's an unbroken app:// chain
> from the top-level frame down to you.

Ok. So this means that any child iFrame which moved outside of the 'natural state' will not be able to load app:// URLs. And if it is able to - this means there is some issue - but where? In the app's code? I wouldn't think so, since this should be prevented in gaia/gecko. 

To summarize
1. An iFrame in a webapp gets a mozallowfullscreen permission if the app has that permission
2. If the iFrame enables full-screen, the onus of 'escaping' back to the app's main screen is with the developer. User pressing the home button in this case will close the app - something app developers have to watch out for
3. The 'natural state' state of the iFrame will be the same origin as the webapp. Any change of the domain within the iFrame will result in the iFrame losing its full-screen privileges [not sure on this one]
4. Once the iFrame navigates away from the 'natural state', it won't have access to the app:// URLs (conversely, if the iFrame is in the 'natural state' it will have access to other app:// URLs)
5. If the iFrame gets access to app:// URLs if it has navigated from the 'natural state' - there is an issue in the framework (though this will never happen and the developer can  assume that someone hacking into their domain can't cause irreversible damage on the phone)

Thanks much for going through these questions
> So, the only way out for a user out of a full-screen iFrame is to exit the application - is that 
> right?

I don't know; that's a question for Gaia folks, I think.  Maybe they map the home button to exit-full-screen.  Or perhaps they make the back button map to exit-full-screen, on devices which have back buttons.

I agree that's something that should be clarified, for the purposes of the app-writing docs.

> Ok. So this means that any child iFrame which moved outside of the 'natural state' will not be able 
> to load app:// URLs. And if it is able to - this means there is some issue - but where? In the app's 
> code? I wouldn't think so, since this should be prevented in gaia/gecko. 

Correct; that would be a Gecko bug.

> 3. [...] Any change of the domain within the iFrame will result in the iFrame losing its full-screen 
> privileges [not sure on this one]

If you're outside the app's "natural" domain, then you're just like any other webpage, and normal webpages can go full-screen.  Youtube.com is not an app, but it can go into full-screen.  Apps just get hassled less when they go full-screen.  Exactly what those details are, I'm not sure; it's probably easiest if you experiment with a build.
You need to log in before you can comment on or make changes to this bug.