Closed Bug 939166 Opened 11 years ago Closed 11 years ago

Clean up script global acquisition in CallSetup

Categories

(Core :: DOM: Core & HTML, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla28

People

(Reporter: bholley, Assigned: bholley)

References

Details

(Whiteboard: [qa-])

Attachments

(2 files)

We do a bunch of QIs right now that aren't actually necessary. I can make this stuff quite a bit faster and simpler. :-)
This can all collapse because of the following facts: * Ever since we introduced SandboxPrivate, we never actually use a Window as an SOP for a sandbox. * nsGlobalWindow is actually the only thing that implements nsIScriptGlobalObject.
Attachment #8335080 - Flags: review?(bzbarsky)
Comment on attachment 8335080 [details] [diff] [review] Part 1 - Be more direct in GetStaticScriptGlobal. v1 Hrm. We sure used to have code that depended on finding the window via this codepath for sandboxes! I guess maybe it doesn't anymore. >+ // This assumes that we only have WN window globals. Can we just GetISupportsFromJSObject our way to victory here? Though we'd then need to deal with the nsISupports maybe pointing to an XPCWrappedNative*... Basically, I'd rather we didn't add pitfalls here for the Window conversion to webidl. r=me with that fixed.
Attachment #8335080 - Flags: review?(bzbarsky) → review+
Comment on attachment 8335081 [details] [diff] [review] Part 2 - Stop going through nsIScriptGlobalObject in CallSetup. v2 r=me
Attachment #8335081 - Flags: review?(bzbarsky) → review+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Blocks: 965153
Whiteboard: [qa-]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: