398893 - Error: uncaught exception: Permission denied to set property Window.status

Status: NEW

(Core :: General, defect)

Description

[bht237]

Attachment: Simple testcase

The JavaScript error breaks legacy code that worked with older versions of Mozilla/Firefox.


How to reproduce:

- Load the testcase
- Open the error console
- Hover with the mouse over the text "Mouse over test"



This seems to be independent of:

Advanced JavaScript Settings
Allow scripts to:
Change status bar text unchecked or checked - no difference


In older versions of Mozilla, I was able to reproduce this problem only with an entry in user.js as follows:

user_pref("capability.policy.default.Window.status","noAccess");

Important: We have seen the same error even on pages WITHOUT any code that sets window.status. So there are yet unknown other scenarios where this error is thrown. We know this because we are logging all browser JavaScript errors on the server via window.onerror handlers.

We have also seen only very recently new errors such as

Permission denied to get property HTMLDocument.body
Permission denied to get property Window.DOM Constructor.prototype

possibly in the same context.

Comment 1

[Mats Palmgren (inactive)]

WFM, Firefox 2.0.0.7 and 2.0.0.8-rc1 on Linux with a clean profile.

Comment 2

[bht237]

I can show you how to reproduce this:

I found the setting 
user_pref("capability.policy.default.Window.status", "noAccess");
in my prefs.js

I don't know how it gets there. I remember only that I had put into user.js for the purpose of reproducing the error and that I removed it later.

The bug does not reproduce after removal of the line.

Or in other words if you add this line then it is likely that you will see the bug.

################## Question: ####################

Is it possible that the browser REMOVES or IGNORES any such setting because
it appears that there is now a NEW setting that takes care of this permission:

user_pref("dom.disable_window_status_change", false);

This seems to be supported by the GUI.

Comment 3

[Jesse Ruderman]

That aspect of user.js is confusing :(

Comment 4

[Jesse Ruderman]

And of course it's not a bug that setting "capability.policy.default.Window.status" to "noAccess" causes window.status = 'foo' to throw.  That's what CAPS does, and it's why we implemented another way to stop web pages from setting status text that doesn't throw.

Comment 5

[bht237]

Jesse,

Please accept my apologies for re-opening this bug. Unfortunately, this bug is not fixed at all by the duplicate Bug 398893 which has been closed without changing the software.

The sad reality for our Firefox users is that about 5% of of them get this error while no other browser has any such issue at all. This is enormous.


We have to realise that I am raising this issues quasi on behalf of many users that are not represented here individually. We are collecting every single incident and we are producing statistics about them from multiple web sites.

Some of these Firefox users are getting the error on pages that do not at all set window.status.


How can this happen?

I have no idea really. It could mean that the brower triggers the error via the normal event where it shows the window status internally, normally - but in some strange ways. That will be hard to reproduce as anything that we get reported in our log files, but the fact is that our users are getting these errors, and we have no way of ignoring them technically because we depend on JavaScript.

This high percentage of errors cannot be explained away.

There must be a strange mechanism by which this preference setting is generated or was generated (e.g. when inheriting an old profile), a way that does not require user interaction. I cannot imagine that so many users edit these settings in hte prefs files. Very unlikely. I would think they don't even know how to do it.

Again, I am proposing to remove support for this setting entirely because the user has full control via the GUI.

What would be the benefit of doing harm to the users by throwing an Exception that breaks web pages?

Would you please elaborate.

What is the benefit to break sites and annoy users who don't have an idea why their web experience is disrupted?

I thought that modern programming methods are cooperative not aggressive as in this case, so would you please explain why are getting aggressive here.

Comment 6

[Jesse Ruderman]

The user.js issue (comment 2) is a duplicate of bug 50038.

You have a good point about the old annoying-content prefs that used CAPS.  I filed bug 399301 to see if we can do something about the throwing for those cases.  (Most other CAPS prefs will probably continue to throw; I think that's more sane than having all blocked function calls and getters return |null| and turning setter uses into no-ops.)

It's interesting to hear about what you're finding with onerror; that's a neat trick.  Unfortunately, there isn't enough information here for a bug report; there seem to be multiple unrelated issues and not enough information to figure out what the bugs in Firefox are (if any).

You'll probably have to ask the visitors in question about their Firefox extensions, Greasemonkey scripts, and settings.  But answers to these questions might help me guess what's going on:

* How many of the errors are "Permission denied to set Window.status", how many are other permission-denied errors, and how many are non-permission-related errors?  I'd love to see your detailed statistics.

* Do you get more "Permission denied to set Window.status" errors on pages that do set window.status, or are those errors evenly distributed across sites/pages?

* When you look at the URL and line-number arguments to your onerror function, how much sense do they make?  Are they lines of your script that look like they could be related to the error message, or are they complete nonsense (e.g. blank lines or lines without script)?  I'm especially interested in the values for "Permission denied to set Window.status" errors that happen on pages without window.status setting code.

* Are visitors reporting that things aren't working?  Or do the pages work fine despite the onerror handler firing?

Btw, you can probably use try..catch around your window.status uses now as a workaround.  Netscape 4 has been dead for a while :)