20066 - sched: Rewrite null termination semantics for clipboard/D&D api's

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[Mike Pinkerton (not reading bugmail)]

The clipboard and d&d api's have just grown up with conflicting assumptions about
when data is and is not null terminated. Before we assumed that it wasn't so
length params are provided to all routines, but since the switch to the primitive
objects, it becomes unclear if they are necessary and where the null termination
should be done (if at all).

Also, data with embedded nulls (image data, etc) might fall pray to the current
handling of this data as nsISupportsWString primitives since length checking
there might return incorrect results. Should probably switch those to a different
primitive (never did because of time constraints...figured i'd go back and do it
when someone actually had some non-text data).

This bug is a scheduling placeholder for me.

Comment 1

[Mike Pinkerton (not reading bugmail)]

P1, M12.

Comment 2

[Mike Pinkerton (not reading bugmail)]

I've decided we need to keep the length parameters since data cannot always be
null terminated (image data, for example). for text data, when it comes out of
the primitives, it will be null terminated since that is just how the primitives
work. the length in the transferable reflects the length of the data, not
including the null. this allows it to be consistant with binary data.

adding/removing null termination for text strings is handled at the native
platform boundary, but the primitives take care of most of the work for us (esp
with the new setDataWithLength() method on nsISupports[W]String.

regarding the issue of assuming nsISupportsWString for binary data, i'm punting
here until we actually get some ;)

Comment 3

[Paul MacQuiddy]

placeholder, marking verified