Hello list,
Regarding #9701, on Monday's meeting we talked about this method:
DataStruct::SetData (nsISupports* aData, uint32_t aDataLen) { // Try to get a nsIChannel here }
And a helpful comment was 'get the channel from the top level chrome window.' I tried a few things:
nsCOMPtr<nsIDOMChromeWindow> aWin(do_QueryInterface(aData, &rv)); nsCOMPtr<nsILoadContext> aCtx(do_QueryInterface(aData, &rv));
These calls set rv == NS_NOINTERFACE in every case. Am I missing another way to get the top chrome window? Is there a global mTopwin?
SetData gets called like this:
nsCOMPtr<nsISupportsString> aString; SetData (aString, <some-number>)
By the way, another suggestion to use the JavaScript module PrivateBrowsingUtils.jsm requires a nsILoadContext pointer, failing with rv == NS_NOINTERFACE in the same way.
Looks like this is not going to make it in the 4.5 alpha 3 release.
(No) Cheers, Michael
Hi Michael,
Could you add a flag to DataStruct::SetData, like `DataStruct::SetData (nsISupports* aData, uint32_t aDataLen, bool private)`
and then change calls to SetData to look like `data.SetData (aData, aDataLen, mPrivateData);`
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
Best regards, Arthur
On Wed, Jan 14, 2015 at 5:16 PM, tordevmuc@encambio.com wrote:
Hello list,
Regarding #9701, on Monday's meeting we talked about this method:
DataStruct::SetData (nsISupports* aData, uint32_t aDataLen) { // Try to get a nsIChannel here }
And a helpful comment was 'get the channel from the top level chrome window.' I tried a few things:
nsCOMPtr<nsIDOMChromeWindow> aWin(do_QueryInterface(aData, &rv)); nsCOMPtr<nsILoadContext> aCtx(do_QueryInterface(aData, &rv));
These calls set rv == NS_NOINTERFACE in every case. Am I missing another way to get the top chrome window? Is there a global mTopwin?
SetData gets called like this:
nsCOMPtr<nsISupportsString> aString; SetData (aString, <some-number>)
By the way, another suggestion to use the JavaScript module PrivateBrowsingUtils.jsm requires a nsILoadContext pointer, failing with rv == NS_NOINTERFACE in the same way.
Looks like this is not going to make it in the 4.5 alpha 3 release.
(No) Cheers, Michael
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
Hi Arthur,
Cool, I was hoping you'd reply.
On Wed., Jan. 14, 2015, Arthur D. Edelstein wrote:
On Wed, Jan 14, 2015 at 5:16 PM, Michael Schloh von Bennewitz wrote:
Regarding #9701, on Monday's meeting we talked about this method:
DataStruct::SetData (nsISupports* aData, uint32_t aDataLen) { // Try to get a nsIChannel here }
[...]
Looks like this is not going to make it in the 4.5 alpha 3 release.
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.
By the way:
tor-browser$ find . -name '*.cpp' -exec grep 'SetData' {} ; -print | wc 883 (!) 2174 49443
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.
All we can do is break binary compatability and hope for the best. It might lower chances of a easy backport to ESR38, but let's see.
Cheers, Michael
Hi Michael,
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?
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
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.
Best regards, Arthur
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
Hi Michael,
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.
Yes, I think Mark and Kathy make very good suggestions. It's great that you've got it working!
Best regards, Arthur
-
Arthur D. Edelstein -
tordevmuc＠encambio.com