Old versions of Firefox (before 1.0) had annoying-content preferences hooked up to CAPS, e.g. setting capability.policy.default.Window.status to noAccess. The exceptions generated by CAPS broke scripts by throwing exceptions, so in bug 117707, new preferences were introduced and the UI was redirected to use the new preferences. It seems like a significant number of users still have the old prefs, and it's leading to sites breaking. For example, see bug 165692 comment 2. More than a few bugs complaining about this issue have been duped to bug 122866, but based on mstoltz's comments there I think that bug is too vague/general. email@example.com uses onerror to gather statistics about exceptions seen on his sites, and errors related to setting window.status seem to be among the more common errors. (Some of these errors are mysterious, though. See comments in bug 398893 for details.) See bug 117707 comment 93 for a list of CAPS prefs that were set by the old UI. Note that some of them (methods and window.status-related) don't end in ".set", so fixing this isn't a simple matter of making CAPS-blocked assignment be a no-op.
> new preferences were introduced Isn't this a profile migration issue, then? Not sure why this is filed in CAPS. > this isn't a simple matter of making CAPS-blocked assignment be a no-op. Doing that would be bad in any case.
Serving your page using https would take care of those MITM attacks ;)
Is this still a problem, or can this be closed?
You need to log in before you can comment on or make changes to this bug.