Closed Bug 178291 Opened 22 years ago Closed 14 years ago

using window.fullScreen causes scripts to stop

Categories

(SeaMonkey :: Preferences, defect, P4)

Product:
SeaMonkey
Component:
Preferences
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: cokaw, Assigned: caillon)

Details

Attachments

(1 file, 1 obsolete file)

No pref. Just block if caller is not chrome.
1.54 KB, patch
security-bugs
: review+
jst
: superreview+
Details | Diff | Splinter Review 
Using the following code, which works across the whole IE range, and NS 4.xx 
and NS 6, Netscape 7 refuses to handle the following code.

It produces the error message :-
Error: uncaught exception: Permission denied to set property Window.fullScreen
Basically it spawns a new window that is fullscreen, and places some HTML in 
the current window.

<html>
	<head>
		<title>Redirecting to full screen</title>
		<meta http-equiv="Content-Type" content="text/html; charset=UTF-
8"/>
		<script language="JavaScript>
function fullScreen() {
	var location = "home.html";
	var wf = "";
	var fullWin = "";
	
	window.name = "PAGE_FULLSCREEN";
	if (screen.availWidth<800) {
		location = "error_resolution.html";
		window.location.href=location;
	} else {
			window.location.href = "fullscreen.html";
    		var wf = "";  
			wf 
= "width="+window.screen.availWidth+",height="+window.screen.availHeight+"',resi
zable=no,scrollbars=auto,menubar=no," 
+"fullscreen=yes,toolbar=no,directories=no,location=no,status=no," 
+"top="+window.screen.availTop+",left="+window.screen.availLeft;      
			fullWin = window.open(location,"NewFullScren",wf);
			fullWin.focus();
			}
	}
</script>
</head>
<body onLoad="fullScreen();">
<P>Opening fullscreen</P>
</body>
</html>
Definitely not a blocker. 
Severity -> normal
Severity: blocker → normal
Browser, not engine ---> Browser-General

Kevin: in your Mozilla directory, check for a file named either
"all.js", "user.js", or "prefs.js". Do you have a line like this?

  pref("capability.policy.default.Window.fullScreen", "noAccess");

If so, that is what's causing the warning. Changing this to "allAccess"
should make the problem go away -
Assignee: rogerl → asa
Component: JavaScript Engine → Browser-General
QA Contact: pschwartau → asa
Hi yes, I've looked into this and have seen it mentioned somewhere else that 
this is set by default to noAccess ? This is a freshly installed version of NS 
7 that I have downloaded in order to test my site. Therefore I would assume 
that other people who come to the site will experience the same problem.

Is there a javascript command I can use to remedy this problem in order to 
ensure that browsers can view the site, as this appears to be a problem with 
the permissions of the browser?
Reassigning to Prefs component for the time being.

Kevin:

1. Did you in fact have that line in your prefs files somewhere?
   pref("capability.policy.default.Window.fullScreen", "noAccess");
   Because if you don't, we have a different problem that needs
   looking into.

2. Did you install Netscape 7 on top of a previous installation?
   If so, older preferences are preserved and may have included 
   this one. People in the Prefs component or the Installer 
   component will know more about that than I -
Assignee: asa → ben
Component: Browser-General → Preferences
QA Contact: asa → sairuh
> I've looked into this and have seen it mentioned somewhere else that 
> this is set by default to noAccess ?

Good point. Regardless of previous installations, if the default value
of |capability.policy.default.Window.fullScreen| is "noAccess", that will
cause a problem for your site. 

The Prefs component can answer that -
Fullscreen mode is disabled from being used by websites because of some security
issues with it.  One simple solution from the scripter's viewpoint is to wrap
the window.fullScreen access in a try/catch (unfortunately, that would make the
script not run in NS4, which does not support try/catch).

Another solution is not to not open the window fullscreen (at least in Gecko
browsers).

That said, just using the fullscreen=yes option should not be triggering the
error you are seeing, should it?  Are you actually assigning to
window.fullScreen somewhere?
This was a conscious decision -- see bug 127405.

However, one of the downsides of using caps to do this sort of thing is that it
stops script execution instead of no-oping the offending call.

The only security issue is that it hides the lock icon.  So users have no way of
knowing whether or not they are on a secure site.  This is a _major_ issue for
many of our consumers though, banks in particular.
Also, note that the function (in the global scope) is called fullScreen.  So I
wonder if just having a function fullScreen is causing caps to complain....

We should probably have a dom.disable_window_fullscreen pref, like we do for
other things.  I can take this on, if we decide to do that.

Other points:

Should this have a UI?  If we do have a configurable UI, what do we want the
default to be?  What do we want the UI text to say?
Assignee: ben → caillon
Summary: Javascript problem using Netscape 7. → using window.fullScreen causes scripts to stop
Oh, duh!  Trying to define a function called "fullScreen" will attempt to write
to window.fullScreen (to bind the function) and caps will stop it cold.

So Kevin, just renaming the function will fix this issue for you.....
We've really got to stop naming new window properties with initial alphas,
there's always a good chance someone, somewhere, has a variable of that name on
an existing site that we'll conflict with.

I'd say this is confirmed, no?
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: sairuh → claudius
Found that renaming the function name to something else eliminates the problem. 
Sorted, thanks
anything left to do in this bug, or can this be resolved per comment 11?
I know that renaming the function works.  But see comment 8.  Others can
encounter this and we should not hurt them too.  I should have a patch shortly.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.3alpha
Attached patch Backend patch (obsolete) — — Splinter Review 
I wish that CAPS would not throw exceptions for things like this, but since it
does, we should do something like this.... This adds a hidden pref to stop
scripts from messing with fullScreen settings, though I left reading them alone
which I think is harmless for a site to read (does anyone disagree?  Should I
patch GetFullScreen as well?).
Attachment #107511 - Flags: superreview?(jst)
Attachment #107511 - Flags: review?(mstoltz)
Comment on attachment 107511 [details] [diff] [review]
Backend patch

I'd rather you used a new caps pref instead of a "dom" pref. Take a look at
NavigatorImpl::Preference() in nsGlobalWindow.cpp for an example of how to do
this. That way, caps can do the IsCallerChrome check implicitly, and also check
for other special cases as appropriate.
Attachment #107511 - Flags: review?(mstoltz) → review-
I don't think we want fullScreen to be allAccess -- there's no need for other
domains to be able to touch it. And I don't know why you want a pref to
disable/enable scripts to do it -- it's just a problem, if it's not chrome don't
allow it.
Comment on attachment 107511 [details] [diff] [review]
Backend patch

Ahh.  hmm, interesting..  looking into that then.
Attachment #107511 - Flags: superreview?(jst)
Shouldn't we make fullScreen sameOrigin which is the default? IOW, just remove
the capabilities entry from prefs.js for it and add the code that checks if the
method is called from chrome or if the special pref (which's suggested name was
fine with me, it goes nicely along the line we've started for other similar
methohds). I'd sr the attached patch if you'd simply take out the capabilities
pref in the patch.
I'm not sure I like the CAPS pref idea.  It seems like an awful lot of work to
do for setting fullscreen mode, which is already doing quite a bit of work.  So
for now, I'll leave it alone, and just make a patch without the pref.  I chose
the dom pref because that's what we've done in the past, and it seemed to fit
in.  But this should do the job of not throwing if someone tries to set
fullScreen from js.
Attachment #107511 - Attachment is obsolete: true
Attachment #107549 - Attachment description: No pref. Just block if caller is chrome. → No pref. Just block if caller is not chrome.
Attachment #107549 - Flags: superreview?(jst)
Attachment #107549 - Flags: review?(mstoltz)
Comment on attachment 107549 [details] [diff] [review]
No pref.  Just block if caller is not chrome.

sr=jst
Attachment #107549 - Flags: superreview?(jst) → superreview+
Comment on attachment 107549 [details] [diff] [review]
No pref.  Just block if caller is not chrome.

Using a CAPS pref and a "fullScreenInternal" security check would allow for
more flexibility down the line, such as allowing Mozilla embeddors or users to
grant the fullScreen ability to particular hosts or signers. A simple check for
IsCallerChrome doesn't allow any of this flexibility - content will never be
able to use fullscreen mode. If by "a lot of work" you mean you're concerned
about performance, the impact should be negligible - the security check is
quite fast. I would prefer we use a CAPS security check, but I won't insist on
it; the choice is up to you. r=mstoltz on the current patch.
Attachment #107549 - Flags: review?(mstoltz) → review+
Target Milestone: mozilla1.3alpha → mozilla1.5beta
Target Milestone: mozilla1.5beta → ---
Priority: P2 → P4
QA Contact: claudius → ian
Product: Browser → Seamonkey
Christopher,
Are you still working on this ?
no reply, so incomplete.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: