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
QA Contact: pschwartau → asa
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
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
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
Created attachment 107511 [details] [diff] [review] Backend patch 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?).
16 years ago
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.
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.
Created attachment 107549 [details] [diff] [review] No pref. Just block if caller is not chrome. 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
16 years ago
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+
15 years ago
Target Milestone: mozilla1.3alpha → mozilla1.5beta
Christopher, Are you still working on this ?
no reply, so incomplete.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.