Hello Arthur,
On Thurs., janv. 15, 2015, Arthur D. Edelstein wrote:
Could you add a flag to DataStruct::SetData, like `DataStruct::SetData (nsISupports* aData, uint32_t aDataLen, bool private)`
Yes, per my suggestion 'changing the API' at the meeting. This breaks binary compatability, but it might not be as bad as I thought, since the interface isn't exposed in IDL.
What binary compatibility are you concerned about?
If XPCOM has a CreateInstance(<classid>, outPtr) equivalent, then the binary compatibility problem involves a consumer of the returned outPtr. The consumer has not recompiled with the new interface code, and dereferences a vtable entry that might not exist.
It's possible that Mozilla has not implemented this COM feature, so if that's the case there's no concern with binary compatability.
I'm still digging through docs to make 100% sure about this.
By the way:
tor-browser$ find . -name '*.cpp' -exec grep 'SetData' {} ; -print | wc 883 (!) 2174 49443
It looks to me like the DataStruct::SetData function is only called by nsTransferable::GetTransferData and nsTransferable::GetAnyTransferData. You can click on "GetData" here and choose "Find callers": https://dxr.mozilla.org/mozilla-central/source/widget/nsTransferable.cpp#75
'SetData': //dxr.mozilla.org/mozilla-central/source/widget/nsTransferable.cpp#57
That's my hope too, but a lingering suspicion is that other SetData's could be caching to disk. That was the gist behind the 'by the way' comment.
The nsTransferable::mPrivateData field seems to indicate if the data came from a private browsing load context: https://dxr.mozilla.org/mozilla-central/source/widget/nsTransferable.cpp#234
mPrivateData is a protected member of another class, so dead end.
But nsTransferable is calling DataStruct::SetData, so, if you add the extra argument to SetData, you can pass the value of mPrivateData, even though it is a protected member of nsTransferable.
Saying 'dead end' implied not changing the DataStruct signature but it doesn't seem to be an option, so your idea is a good one.
I did a variant of it [1], leaving the original SetData alone and adding an overloaded method integrating the PBM flag. I did that expecting to ease a Mozilla backport OK, but Mark and Kathy (maybe you too?) prefer changing the existing SetData for other reasons.
[1] https://trac.torproject.org/projects/tor/attachment/ticket/9701/msvb9701-283...
Cheers, Michael