Closed Bug 818716 Opened 12 years ago Closed 12 years ago

Remove filename hack from CanAccessNativeAnon

Categories

(Core :: XPConnect, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla20

People

(Reporter: bholley, Assigned: bholley)

References

Details

Attachments

(1 file)

This is a much better way to do it.
Summary: Remove CanAccessNativeAnon and replace it with AccessCheck::callerIsXBL → Remove filename hack from CanAccessNativeAnon
Given the obscene load on the linux32 test boxes, I've cancelled that push and repushed as linux64. https://tbpl.mozilla.org/?tree=Try&rev=7b06693a78f6
Depends on: 820666
Arg, this was bitrotted by bug 810082. Trying again: https://tbpl.mozilla.org/?tree=Try&rev=7d8c080fe064
I'll just leave this here: 3.14 + MOZ_ASSERT(cx = nsContentUtils::GetCurrentJSContext());
(In reply to :Ms2ger from comment #5) > I'll just leave this here: > > 3.14 + MOZ_ASSERT(cx = nsContentUtils::GetCurrentJSContext()); Doh! Thanks Ms2ger. That explains the lone orange. ;-)
Actually, it's still an issue, because sometimes cx is the safe JS context. I'll fix that.
This should do it. Flagging mrbkap for review.
Attachment #691517 - Flags: review?(mrbkap)
Comment on attachment 691517 [details] [diff] [review] Move XBL detection into nsContentUtils and remove filename hack. v3 Review of attachment 691517 [details] [diff] [review]: ----------------------------------------------------------------- I'm so happy to see this code die. ::: content/base/public/nsContentUtils.h @@ +199,5 @@ > static JSContext* GetContextFromDocument(nsIDocument *aDocument); > > static bool IsCallerChrome(); > + static bool IsCallerXBL(); > + Nit: nuke the extra newline here.
Attachment #691517 - Flags: review?(mrbkap) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Depends on: 821676
Depends on: 823279
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: