Re: Nightly Only Containers Feature

[Karl Dubost]

Tanvi,

Le 16 juin 2016 à 11:42, Tanvi Vyas  a écrit :
> This week we enabled the Containers feature for testing in Nightly.

Just wonderful. It ties to another previous thread.
https://groups.google.com/forum/#!topic/mozilla.dev.platform/fmJ1UEENbfM


> [1] Take this 2-minute survey or email contain...@mozilla.com.
> https://docs.google.com/forms/d/1oQN14TUnqj-MDErp8MKxH_v7YttOASVdER4lwCgbGKY/viewform?c=0&w=1


I'll give it a try and send some comments. 

Some topics (I can open individual bugs):

* add-ons for one or more containers but not others (think ublock, umatrix for 
a container)
* renaming the containers
* create as many containers as you need
* "Hide the others"/"Hide this container" Not showing the tabs attached to one 
specific container. (think hiding apps in MacOS.)
* … (more to come)

-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[smaug]

On 06/16/2016 06:40 PM, smaug wrote:

On 05/24/2016 08:33 AM, jww...@mozilla.com wrote:

For

RefPtr GetFoo() {
   RefPtr foo;
   // ...
}

should we:

1. return foo and expect RVO to kick in to eliminate additional AddRef/Release
2. return foo.forget()
3. return Move(foo)

Which one is preferred?

ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is also 
true for other compilers.



Can we somehow guarantee that RVO kicks in? It feels quite error prone to rely 
on compiler optimization when dealing with
possibly slow Addref/Release calls.
https://en.wikipedia.org/wiki/Return_value_optimization#Compiler_support hints 
that there are cases when RVO might not happen.



I've been told we can't guarantee RVO to kick in, which means, I think, that we 
should assume we don't have RVO ever and need to
rely on other coding patterns which are guaranteed to optimize out extra 
addref/release.
Currently having already_AddRefed as the return type is one such pattern.

What are the other options?


At least we can't start using RefPtr as return type before we know it won't 
be causing performance regressions.
So I would recommend using already_AddRefed for now.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Nightly Only Containers Feature

[Gabriela Montagu]

Hello,

I am a long time QA Nightly tester. I usually have my 3 gmail accounts open
in pinned tabs on the same browser without any issues. If you could please
tell me how Containers will improve my user experience, I would greatly
appreciate it!

I'll be happy to test this featured anyway!

Best regards,
Gabriela
On 17 Jun 2016 05:27, "Karl Dubost"  wrote:

> Tanvi,
>
> Le 16 juin 2016 à 11:42, Tanvi Vyas  a écrit :
> > This week we enabled the Containers feature for testing in Nightly.
>
> Just wonderful. It ties to another previous thread.
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/fmJ1UEENbfM
>
>
> > [1] Take this 2-minute survey or email contain...@mozilla.com.
> >
> https://docs.google.com/forms/d/1oQN14TUnqj-MDErp8MKxH_v7YttOASVdER4lwCgbGKY/viewform?c=0&w=1
>
>
> I'll give it a try and send some comments.
>
> Some topics (I can open individual bugs):
>
> * add-ons for one or more containers but not others (think ublock, umatrix
> for a container)
> * renaming the containers
> * create as many containers as you need
> * "Hide the others"/"Hide this container" Not showing the tabs attached to
> one specific container. (think hiding apps in MacOS.)
> * … (more to come)
>
> --
> Karl Dubost, Mozilla
> http://www.la-grange.net/karl/moz
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Nightly Only Containers Feature

[Alessio Placitelli]

Gabriela, I think in your case it works because you "Added" the other
accounts to your main account.

In general, if you open a gmail account and then try to open another,
unconnected gmail account in another tab, it opens the former again.

With containers, you will be able to open different, unconnected gmail
accounts in different containers (which is kind of cool IMHO!)


2016-06-17 15:53 GMT+02:00 Gabriela Montagu :

> Hello,
>
> I am a long time QA Nightly tester. I usually have my 3 gmail accounts
> open in pinned tabs on the same browser without any issues. If you could
> please tell me how Containers will improve my user experience, I would
> greatly appreciate it!
>
> I'll be happy to test this featured anyway!
>
> Best regards,
> Gabriela
> On 17 Jun 2016 05:27, "Karl Dubost"  wrote:
>
>> Tanvi,
>>
>> Le 16 juin 2016 à 11:42, Tanvi Vyas  a écrit :
>> > This week we enabled the Containers feature for testing in Nightly.
>>
>> Just wonderful. It ties to another previous thread.
>> https://groups.google.com/forum/#!topic/mozilla.dev.platform/fmJ1UEENbfM
>>
>>
>> > [1] Take this 2-minute survey or email contain...@mozilla.com.
>> >
>> https://docs.google.com/forms/d/1oQN14TUnqj-MDErp8MKxH_v7YttOASVdER4lwCgbGKY/viewform?c=0&w=1
>>
>>
>> I'll give it a try and send some comments.
>>
>> Some topics (I can open individual bugs):
>>
>> * add-ons for one or more containers but not others (think ublock,
>> umatrix for a container)
>> * renaming the containers
>> * create as many containers as you need
>> * "Hide the others"/"Hide this container" Not showing the tabs attached
>> to one specific container. (think hiding apps in MacOS.)
>> * … (more to come)
>>
>> --
>> Karl Dubost, Mozilla
>> http://www.la-grange.net/karl/moz
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

WebRTC connections do not trigger content policies. Should they?

[Paul Ellenbogen]

At the moment, WebRTC does not check if connections are okay by content
policies

.

WebRTC data channels as a side channel around content policy has potential
for abuse. For example, ad blockers use content policy to block ads, so
advertisers may be able to load their ads on a page using data channels
where the traditional methods would be blocked.

Two possible solutions other than checking WebRTC connections against
content policies exist:

   - Require a doorhanger prompt for all data channel connections.
   - Require ad blockers and other extension developers to create a wrapper
   around PeerConnection or RTCDataChannel. This is what uBlock Origin does
   on chrome  for WebSockets.

Are there opinions or thoughts on the pros/cons of including WebRTC
connections in content policies?

Paul Ellenbogen
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[Gerald Squelart]

On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote:
> On 06/16/2016 06:40 PM, smaug wrote:
> > On 05/24/2016 08:33 AM, jw...@mozilla.com wrote:
> >> For
> >>
> >> RefPtr GetFoo() {
> >>RefPtr foo;
> >>// ...
> >> }
> >>
> >> should we:
> >>
> >> 1. return foo and expect RVO to kick in to eliminate additional 
> >> AddRef/Release
> >> 2. return foo.forget()
> >> 3. return Move(foo)
> >>
> >> Which one is preferred?
> >>
> >> ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is 
> >> also true for other compilers.
> >>
> >
> > Can we somehow guarantee that RVO kicks in? It feels quite error prone to 
> > rely on compiler optimization when dealing with
> > possibly slow Addref/Release calls.
> > https://en.wikipedia.org/wiki/Return_value_optimization#Compiler_support 
> > hints that there are cases when RVO might not happen.
> >
> 
> I've been told we can't guarantee RVO to kick in, which means, I think, that 
> we should assume we don't have RVO ever and need to
> rely on other coding patterns which are guaranteed to optimize out extra 
> addref/release.
> Currently having already_AddRefed as the return type is one such pattern.
> 
> What are the other options?
> 
> 
> At least we can't start using RefPtr as return type before we know it 
> won't be causing performance regressions.
> So I would recommend using already_AddRefed for now.

>From what *I* understand, RVO is guaranteed (or at least supported 
>everywhere?) when there is only one stack variable that is returned, e.g.:
C foo()
{
  C rv;
  // ... (put stuff in rv)
  return rv;
}
In this case, the caller function stack can host 'rv' directly, no copies 
needed.

RVO won't happen when there may be multiple variables in the function, only one 
of which will be returned, e.g.:
C foo()
{
  C rv1, rv2; bool b;
  // ... (assign a value to b)
  return b ? rv1 : rv2;
}
The caller cannot know which of rv1 or rv2 will be returned, so no return value 
can be lifted.

(Any actual expert who knows the truth?)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[Gerald Squelart]

On Friday, June 17, 2016 at 3:57:01 PM UTC+1, Gerald Squelart wrote:
> On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote:
> > On 06/16/2016 06:40 PM, smaug wrote:
> > > On 05/24/2016 08:33 AM, jw...@mozilla.com wrote:
> > >> For
> > >>
> > >> RefPtr GetFoo() {
> > >>RefPtr foo;
> > >>// ...
> > >> }
> > >>
> > >> should we:
> > >>
> > >> 1. return foo and expect RVO to kick in to eliminate additional 
> > >> AddRef/Release
> > >> 2. return foo.forget()
> > >> 3. return Move(foo)
> > >>
> > >> Which one is preferred?
> > >>
> > >> ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is 
> > >> also true for other compilers.
> > >>
> > >
> > > Can we somehow guarantee that RVO kicks in? It feels quite error prone to 
> > > rely on compiler optimization when dealing with
> > > possibly slow Addref/Release calls.
> > > https://en.wikipedia.org/wiki/Return_value_optimization#Compiler_support 
> > > hints that there are cases when RVO might not happen.
> > >
> > 
> > I've been told we can't guarantee RVO to kick in, which means, I think, 
> > that we should assume we don't have RVO ever and need to
> > rely on other coding patterns which are guaranteed to optimize out extra 
> > addref/release.
> > Currently having already_AddRefed as the return type is one such pattern.
> > 
> > What are the other options?
> > 
> > 
> > At least we can't start using RefPtr as return type before we know it 
> > won't be causing performance regressions.
> > So I would recommend using already_AddRefed for now.
> 
> From what *I* understand, RVO is guaranteed (or at least supported 
> everywhere?) when there is only one stack variable that is returned, e.g.:
> C foo()
> {
>   C rv;
>   // ... (put stuff in rv)
>   return rv;
> }
> In this case, the caller function stack can host 'rv' directly, no copies 
> needed.
> 
> RVO won't happen when there may be multiple variables in the function, only 
> one of which will be returned, e.g.:
> C foo()
> {
>   C rv1, rv2; bool b;
>   // ... (assign a value to b)
>   return b ? rv1 : rv2;
> }
> The caller cannot know which of rv1 or rv2 will be returned, so no return 
> value can be lifted.
> 
> (Any actual expert who knows the truth?)
(sorry for the spam)

If I'm correct, then the question becomes: Can we trust developers to always 
make the right choice? Or better: Can we write static analyzers that will catch 
RVO-hostile code?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Nightly Only Containers Feature

[Gabriela Montagu]

Alessio,
Many thanks for answering me so quickly, I greatly appreciate it! You're
right of course! I agree,it will be cool! I'll try this as soon as I can as
I am now recovering from a broken elbow and surgery.

Best regards,
Gabriela
On 17 Jun 2016 11:22, "Alessio Placitelli"  wrote:

> Gabriela, I think in your case it works because you "Added" the other
> accounts to your main account.
>
> In general, if you open a gmail account and then try to open another,
> unconnected gmail account in another tab, it opens the former again.
>
> With containers, you will be able to open different, unconnected gmail
> accounts in different containers (which is kind of cool IMHO!)
>
>
> 2016-06-17 15:53 GMT+02:00 Gabriela Montagu :
>
>> Hello,
>>
>> I am a long time QA Nightly tester. I usually have my 3 gmail accounts
>> open in pinned tabs on the same browser without any issues. If you could
>> please tell me how Containers will improve my user experience, I would
>> greatly appreciate it!
>>
>> I'll be happy to test this featured anyway!
>>
>> Best regards,
>> Gabriela
>> On 17 Jun 2016 05:27, "Karl Dubost"  wrote:
>>
>>> Tanvi,
>>>
>>> Le 16 juin 2016 à 11:42, Tanvi Vyas  a écrit :
>>> > This week we enabled the Containers feature for testing in Nightly.
>>>
>>> Just wonderful. It ties to another previous thread.
>>> https://groups.google.com/forum/#!topic/mozilla.dev.platform/fmJ1UEENbfM
>>>
>>>
>>> > [1] Take this 2-minute survey or email contain...@mozilla.com.
>>> >
>>> https://docs.google.com/forms/d/1oQN14TUnqj-MDErp8MKxH_v7YttOASVdER4lwCgbGKY/viewform?c=0&w=1
>>>
>>>
>>> I'll give it a try and send some comments.
>>>
>>> Some topics (I can open individual bugs):
>>>
>>> * add-ons for one or more containers but not others (think ublock,
>>> umatrix for a container)
>>> * renaming the containers
>>> * create as many containers as you need
>>> * "Hide the others"/"Hide this container" Not showing the tabs attached
>>> to one specific container. (think hiding apps in MacOS.)
>>> * … (more to come)
>>>
>>> --
>>> Karl Dubost, Mozilla
>>> http://www.la-grange.net/karl/moz
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[Gabriele Svelto]

On 17/06/2016 16:57, Gerald Squelart wrote:
> From what *I* understand, RVO is guaranteed (or at least supported 
> everywhere?) when there is only one stack variable that is returned, e.g.:
> C foo()
> {
>   C rv;
>   // ... (put stuff in rv)
>   return rv;
> }
> In this case, the caller function stack can host 'rv' directly, no copies 
> needed.

Sounds like the compiler needs visibility into the called function for
this to work so it'll either be limited to functions compiled as part of
the same invocation or when LTO is enabled. Also what about non-leaf
calls? I.e.

C foo()
{
  C rv;
  // ... (put stuff in rv)
  return rv;
}

C bar()
{
  // ...
  return foo();
}

Would it still work? Do we care about it?

> (Any actual expert who knows the truth?)

That's most likely dependent on a combination of the actual code,
compiler, compiler version and flags used when compiling (and possibly
even target dependent if it interacts with other things like register
promotion of stack variables, etc...).

 Gabriele




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[smaug]

On 06/17/2016 04:01 PM, Gerald Squelart wrote:

On Friday, June 17, 2016 at 3:57:01 PM UTC+1, Gerald Squelart wrote:

On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote:

On 06/16/2016 06:40 PM, smaug wrote:

On 05/24/2016 08:33 AM, jw...@mozilla.com wrote:

For

RefPtr GetFoo() {
RefPtr foo;
// ...
}

should we:

1. return foo and expect RVO to kick in to eliminate additional AddRef/Release
2. return foo.forget()
3. return Move(foo)

Which one is preferred?

ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is also 
true for other compilers.



Can we somehow guarantee that RVO kicks in? It feels quite error prone to rely 
on compiler optimization when dealing with
possibly slow Addref/Release calls.
https://en.wikipedia.org/wiki/Return_value_optimization#Compiler_support hints 
that there are cases when RVO might not happen.



I've been told we can't guarantee RVO to kick in, which means, I think, that we 
should assume we don't have RVO ever and need to
rely on other coding patterns which are guaranteed to optimize out extra 
addref/release.
Currently having already_AddRefed as the return type is one such pattern.

What are the other options?


At least we can't start using RefPtr as return type before we know it won't 
be causing performance regressions.
So I would recommend using already_AddRefed for now.


 From what *I* understand, RVO is guaranteed (or at least supported 
everywhere?) when there is only one stack variable that is returned, e.g.:
C foo()
{
   C rv;
   // ... (put stuff in rv)
   return rv;
}
In this case, the caller function stack can host 'rv' directly, no copies 
needed.

RVO won't happen when there may be multiple variables in the function, only one 
of which will be returned, e.g.:
C foo()
{
   C rv1, rv2; bool b;
   // ... (assign a value to b)
   return b ? rv1 : rv2;
}
The caller cannot know which of rv1 or rv2 will be returned, so no return value 
can be lifted.

(Any actual expert who knows the truth?)

(sorry for the spam)

If I'm correct, then the question becomes: Can we trust developers to always 
make the right choice?

No. And reviewers won't catch it either.


Or better: Can we write static analyzers that will catch RVO-hostile code?



So this is the question.


And what then when the code is RVO hostile? developer is forced to write possibly uglier but non-RVO-hostile code? I could live with that I guess, 
hoping that it happens rarely.



-Olli

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebRTC connections do not trigger content policies. Should they?

[Jan-Ivar Bruaroey]

Data channels are modeled on web sockets, and I see we do this for web 
sockets. https://bugzil.la/692067


However, data channels are typically opened to other *clients*, not servers.

What would the ContentLocation URI be in this case? The (dynamic) IP 
used to reach the other client?


This seems easily circumvented by routing data through another client 
that doesn't use content policy.


.: Jan-Ivar :.

On 6/17/16 10:28 AM, Paul Ellenbogen wrote:

At the moment, WebRTC does not check if connections are okay by content
policies

.

WebRTC data channels as a side channel around content policy has potential
for abuse. For example, ad blockers use content policy to block ads, so
advertisers may be able to load their ads on a page using data channels
where the traditional methods would be blocked.

Two possible solutions other than checking WebRTC connections against
content policies exist:

   - Require a doorhanger prompt for all data channel connections.
   - Require ad blockers and other extension developers to create a wrapper
   around PeerConnection or RTCDataChannel. This is what uBlock Origin does
   on chrome  for WebSockets.

Are there opinions or thoughts on the pros/cons of including WebRTC
connections in content policies?

Paul Ellenbogen



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform