Closed
Bug 122866
Opened 23 years ago
Closed 3 years ago
Annoying-content controls should not stop script execution
Categories
(Core :: Security, defect)
Core
Security
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.
Reporter | ||
Comment 1•23 years ago
|
||
*** Bug 121331 has been marked as a duplicate of this bug. ***
Comment 2•23 years ago
|
||
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. ***
Comment 4•23 years ago
|
||
*** Bug 128936 has been marked as a duplicate of this bug. ***
Comment 5•23 years ago
|
||
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.
Comment 6•22 years ago
|
||
I would also like to request a mechanism for no-opping javascript functions and
having it tied to CSP. Maybe something like 'noExecute'
Reporter | ||
Updated•22 years ago
|
Target Milestone: --- → Future
*** Bug 169072 has been marked as a duplicate of this bug. ***
Comment 8•22 years ago
|
||
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.
Reporter | ||
Comment 9•22 years ago
|
||
*** Bug 183150 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
OS: Windows 2000 → All
Hardware: PC → All
Comment 10•22 years ago
|
||
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
Comment 11•22 years ago
|
||
This bug is much more general then bug 117707.
But the example from comment #5 works fine now.
Comment 12•22 years ago
|
||
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.
Comment 13•22 years ago
|
||
> 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.
Reporter | ||
Comment 14•22 years ago
|
||
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 → ---
Comment 15•22 years ago
|
||
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.
Reporter | ||
Comment 16•22 years ago
|
||
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.
Comment 17•22 years ago
|
||
In that case, sure, I'm shutting up now. Sorry for being too agile. ;-)
Comment 18•22 years ago
|
||
*** Bug 196291 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
Adding myself to CC:
Comment 20•21 years ago
|
||
This bug is specific to the "capability.policy" prefs, right?
Comment 21•21 years ago
|
||
*** Bug 229449 has been marked as a duplicate of this bug. ***
Comment 22•21 years ago
|
||
*** Bug 174660 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•18 years ago
|
Assignee: security-bugs → dveditz
Status: REOPENED → NEW
QA Contact: bsharma → toolkit
Comment 23•17 years ago
|
||
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.
Assignee | ||
Updated•3 years ago
|
Status: NEW → RESOLVED
Closed: 22 years ago → 3 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•