Supposed we have something like: typedef (DOMString or unsigned long) DataStoreKey; dictionary DataStoreChangeEventInit : EventInit { DataStoreKey id = 0; }; When we do: DataStoreChangeEventInit eventInit; eventInit.mId = aId; where |aId| is a String type. This assignment will assert because the OwningStringOrUnsignedLong union value initialized by DataStoreChangeEventInit is always set to a UnsignedLong type by default. This will fail the later assignment when the type of value we want to assign is actually String. A work-around is to call: eventInit.mId.~OwningStringOrUnsignedLong(); before the assignment.

See bug 958540. > eventInit.mId.~OwningStringOrUnsignedLong(); I would much prefer you used eventInit.mId.DestroyString() as the workaround, since that doesn't look like you're using an object after calling its destructor.....

(In reply to Boris Zbarsky [:bz] from comment #1) > See bug 958540. > > > eventInit.mId.~OwningStringOrUnsignedLong(); > > I would much prefer you used eventInit.mId.DestroyString() as the > workaround, since that doesn't look like you're using an object after > calling its destructor..... Thanks for the input. :) I guess you're saying eventInit.mId.DestroyUnsignedLong()? because it's initialized as 0 in the WebIDL. If it's initialized as "", then we have to use eventInit.mId.DestroyString(). However, both DestroyString() and DestroyUnsignedLong() are private functions called by ~OwningStringOrUnsignedLong() which is public, so I'd still use ~OwningStringOrUnsignedLong() as work-around for now.

> However, both DestroyString() and DestroyUnsignedLong() are private functions Ugh. Please add a nice comment before the destructor call referencing bug 958540?

Sure!

I just landed a fix for bug 958540, so this should work now, I would think.

I apologize for not cleaning this up when landing bug 949325... These codes was supposed to be removed.

Comment on attachment 8415145 [details] [diff] [review] Patch r=so-many-minuses-it-must-be-good. ;)