Closed Bug 816160 Opened 12 years ago Closed 12 years ago

hasXPConnectImpls should imply that both arguments and return values might not be new binding objects

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla20

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Don't require 'castable':False for prefable bindings with hasXPConnectImpls, and don't require hasXPConnectImpls bindings to be prefable.
(deleted), patch
peterv
: review+
Details | Diff | Splinter Review 
Right now any time hasXPConnectImpls is set we also have to set prefable to true to make return values work and we have to set castable to false to make arguments work because we don't allow prefable castable arguments.

But we already handle non-new-binding castable arguments when hasXPConnectImpls, so there's no need to fail prefable castable arguments if hasXPConnectImpls is set.  And we can similarly use hasXPConnectImpls for the return values instead of actually making things prefable, which speeds up Wrap() a tad.

Patch coming up that does just that.
Blocks: ParisBindings
Attachment #686175 - Flags: review?(peterv) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/f9764b2ccbac
Flags: in-testsuite-
Whiteboard: [need review]
Target Milestone: --- → mozilla20
https://hg.mozilla.org/mozilla-central/rev/f9764b2ccbac
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: