Closed Bug 122866 Opened 23 years ago Closed 3 years ago

Annoying-content controls should not stop script execution

Categories

(Core :: Security, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: security-bugs, Assigned: dveditz)

References

Details

When we use security policies to filter annoying content like pop-ups or window resizing, we currently assume a security violation and throw an exception, which stops the script. This is probably wrong. We should ahve the option to simply no-op the annoying call and continue the script execution. Of course, if the script expects a window to be created and we don't create a window, the script may fail later on anyway, but for some features, like focus and resizing, it's completely safe to simply no-op.
*** Bug 121331 has been marked as a duplicate of this bug. ***
See also bug 117707, Disabling "Change status bar text" for JS breaks application, which includes a lot of general discussion about this problem.
*** Bug 129822 has been marked as a duplicate of this bug. ***
*** Bug 128936 has been marked as a duplicate of this bug. ***
Depends on: 117707
This is an easy test case: <html> <script> resizeTo(1000,700); document.writeln("test"); </script> </html> The word "test" never appears if resizing is disabled for javascript.
I would also like to request a mechanism for no-opping javascript functions and having it tied to CSP. Maybe something like 'noExecute'
Target Milestone: --- → Future
*** Bug 169072 has been marked as a duplicate of this bug. ***
Isn't this a dupe of bug 117707? That one is fixed, but see comment 93 in it: http://bugzilla.mozilla.org/show_bug.cgi?id=117707#c93 for instructions on how to "activate" the fix by editing your prefs.js.
*** Bug 183150 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
Since noone replied to comment 8, I'll assume there are no objections to marking this a dupe. If you disagree, feel free to reopen, add a comment or mail me. *** This bug has been marked as a duplicate of 117707 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
This bug is much more general then bug 117707. But the example from comment #5 works fine now.
Jens (or anyone), can you give an example of what is covered by this bug but not fixed by bug 117707? I don't see the difference. Sorry if I'm missing something.
> Jens (or anyone), can you give an example of what is covered by this bug but not > fixed by bug 117707? I also assumed that this bug was more general, but I tested a few things (document.open/close and history "go") not explicitly mentioned in bug 117707 and they worked.
I don't believe this is a dupe. All security check failures result in an exception which stops the script if not caught, so anyone using the security checks to stop annoying content will cause scripts to stop.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Mitchell: No, they don't, _if_ you have the right settings. Please do read bug 117707 comment 93. Probably you have stale settings from the time when that bug wasn't resolved. If you can give an example of what doesn't work even after changing those settings, then yes, this bug may be valid. But I don't think so.
Vaclav, There are some other (undocumented) content control features that aren't linked to the Scripts and Plugins pref panel, which will still exhibit this problem. In any case, I meant this bug as a reminder to myself of future refactoring work, so please do not mark it as a dupe yet.
In that case, sure, I'm shutting up now. Sorry for being too agile. ;-)
*** Bug 196291 has been marked as a duplicate of this bug. ***
Adding myself to CC:
This bug is specific to the "capability.policy" prefs, right?
*** Bug 229449 has been marked as a duplicate of this bug. ***
*** Bug 174660 has been marked as a duplicate of this bug. ***
Assignee: security-bugs → dveditz
Status: REOPENED → NEW
QA Contact: bsharma → toolkit
See also bug 399301, "Old annoying-content prefs (set using Firefox<1.0) still halt script execution", which is more specific than this bug. Many of the bugs marked as dups of this bug would be covered by that one.
Status: NEW → RESOLVED
Closed: 22 years ago3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.