Hi Ehsan,
Before we created the loadInfo object, the use of TYPE_OTHER in Gecko
was close to zero. Now the use of nsIContentPolicy::TYPE_OTHER is
mostly used for internal loads, but it would be good to change that to
TYPE_INTERNAL and use TYPE_OTHER sparsely or change it to something more
sp
On 2015-04-06 1:38 PM, Boris Zbarsky wrote:
On 4/6/15 1:21 PM, Ehsan Akhgari wrote:
Based on this many-to-many mapping
Yeah, that fact that RequestContext stuff is both more _and_ less
fine-grained than nsIContentPolicy is a PITA.
So we could still consider doing something like this:
1) Ext
On 2015-04-06 1:32 PM, Boris Zbarsky wrote:
On 4/6/15 1:29 PM, Ehsan Akhgari wrote:
The current patches do not provide a default value.
Well, they do for callers of newChannel(), right? Which is what
extensions do
Yes, that's correct.
___
dev
On 4/6/15 1:21 PM, Ehsan Akhgari wrote:
Based on this many-to-many mapping
Yeah, that fact that RequestContext stuff is both more _and_ less
fine-grained than nsIContentPolicy is a PITA.
So we could still consider doing something like this:
1) Extend the set of nsIContentPolicy types such
On 4/6/15 1:29 PM, Ehsan Akhgari wrote:
The current patches do not provide a default value.
Well, they do for callers of newChannel(), right? Which is what
extensions do
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https
On 2015-04-03 4:32 AM, ishikawa wrote:
> On 2015年04月03日 13:11, Boris Zbarsky wrote:
>> On 4/2/15 10:27 PM, Ehsan Akhgari wrote:
>>> Note that for the network connections that are used for our own purposes
>>> which do not belong to a specific web page, this value won't be used, so
>>> its value doe
On 2015-04-03 12:11 AM, Boris Zbarsky wrote:
On 4/2/15 10:27 PM, Ehsan Akhgari wrote:
Note that for the network connections that are used for our own purposes
which do not belong to a specific web page, this value won't be used, so
its value doesn't matter in practice, but as convention, please
On 2015-04-03 11:21 AM, Jonas Sicking wrote:
On Fri, Apr 3, 2015 at 4:27 AM, Ehsan Akhgari wrote:
Next week, I'm planning to land the patches to bug 1149853 which enables
Gecko to track which RequestContext [1] a network fetch is being performed
for.
This will enable us to correctly signal the
On Fri, Apr 3, 2015 at 4:27 AM, Ehsan Akhgari wrote:
> Next week, I'm planning to land the patches to bug 1149853 which enables
> Gecko to track which RequestContext [1] a network fetch is being performed
> for.
>
> This will enable us to correctly signal the context for which a given
> request wa
On Fri, Apr 3, 2015 at 4:27 AM, Ehsan Akhgari wrote:
> Next week, I'm planning to land the patches to bug 1149853 which enables
> Gecko to track which RequestContext a network fetch is being performed
> for.
Are you replacing this existing interface by doing that?
https://developer.mozilla.org/e
On 2015年04月03日 13:11, Boris Zbarsky wrote:
> On 4/2/15 10:27 PM, Ehsan Akhgari wrote:
>> Note that for the network connections that are used for our own purposes
>> which do not belong to a specific web page, this value won't be used, so
>> its value doesn't matter in practice, but as convention, p
On 4/2/15 10:27 PM, Ehsan Akhgari wrote:
Note that for the network connections that are used for our own purposes
which do not belong to a specific web page, this value won't be used, so
its value doesn't matter in practice, but as convention, please pass
RequestContext::Internal/"internal".
I
Next week, I'm planning to land the patches to bug 1149853 which enables
Gecko to track which RequestContext [1] a network fetch is being
performed for.
This will enable us to correctly signal the context for which a given
request was made to service workers that intercept the corrresponding
13 matches
Mail list logo
