[tbb-dev] Problems getting a nsIChannel reference

[tordevmuc at encambio.com]

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-283f7c6.patch

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3527 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20150115/09bf5703/attachment.bin>