Switch to debug-only security checks in DOMWindowUtils

RESOLVED FIXED in mozilla32

Status

()

defect
RESOLVED FIXED
5 years ago
2 months ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

unspecified
mozilla32
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Assignee

Description

5 years ago
I think after bug 1017820, these checks serve no purpose, but I'm not brave enough yet to remove them completely.
Assignee

Updated

5 years ago
Attachment #8431954 - Flags: review?(bobbyholley)
Assignee

Updated

5 years ago
Assignee: nobody → ehsan
Assignee

Updated

5 years ago
Depends on: 1017820
Comment on attachment 8431954 [details] [diff] [review]
Switch to debug-only security checks in DOMWindowUtils

Review of attachment 8431954 [details] [diff] [review]:
-----------------------------------------------------------------

Can we just make these MOZ_RELEASE_ASSERT? I doubt any of these are all that perf-sensitive, and I'm sure we'd sleep easier. :P
Attachment #8431954 - Flags: review?(bobbyholley) → review+
Backed out in http://hg.mozilla.org/integration/mozilla-inbound/rev/ccff275d96a9 because pretty much everything was hitting an assertion failure: nsContentUtils::IsCallerChrome(), and crashing in nsDOMWindowUtils::AreDialogsEnabled(bool*).
https://hg.mozilla.org/mozilla-central/rev/4069a4392eb6
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Assignee

Comment 7

5 years ago
Should I file bugs about the places in our C++ code where we call into nsIDOMWindowUtils APIs which just fail because of the IsCallerChrome checks and the caller is oblivious to that because they don't check the return value?
Probably, yes!
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.