Re: refcounting - which types to use ?

[Enrico Weigelt, metux IT consult]

On 17.08.2017 04:03, Shih-Chiang Chien wrote:
You should use |forget| to transfer the ownership of the nsIArray from 
list to _retval.


Ok, thanks. Already suspected that (found some similar things in the
code). Could we update the docs (maybe some set of examples) ?

IIRC, there're some places that do it like in my prev mail, which I took
as example (just forget where exactly that was) - should that be fixed ?

By the way: is there a difference between out parameters and rval ?
Or can I just assume, rval's are equivalent to an out parameter ?

OTOH, is there a way to create versions that really return it as rval,
so I conveniently could just call like that ?

   nsCOMPtr list = addrbook->FindRecipients(addr);


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

Re: Proposed W3C Charter: WebVR Working Group

[Eric Rescorla]

On Wed, Aug 16, 2017 at 5:18 PM, Daniel Veditz  wrote:

> On Wed, Aug 16, 2017 at 3:51 PM, L. David Baron  wrote:
>
> > I still think opposing this charter because the group should still
> > be in the incubation phase would be inconsistent with our shipping
> > and promotion of WebVR.
> >
>
> ​I agree that would be exceptionally odd and require a well reasoned
> argument about why formal standardization was inappropriate.
>

This puzzles me as well. Lars, can you explain what the argument against
standardization of a shipping feature is?

-Ekr


>
> I'm troubled that the members of the incubation group seem to feel that
> chairs are being imposed on them who have been less involved (or
> uninvolved?) with leading the feature to the point it's gotten so far. But
> I don't understand the politics of that or whether we could or should get
> involved on that point.
>
> -Dan Veditz
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: refcounting - which types to use ?

[Shih-Chiang Chien]

You should use |forget| to transfer the ownership of the nsIArray from list
to _retval.

/* nsIArray FindRecipients (in AString name); */
NS_IMETHODIMP nsAddrBookService::FindRecipients(const nsAString & addr,
nsIArray * *_retval)
{
nsresult rv = NS_OK;
nsCOMPtr list =
do_CreateInstance(NS_ARRAY_CONTRACTID, );
NS_ENSURE_SUCCESS(rv, rv);

if (NS_FAILED(rv = FillRecipients(addr, list)) {
  return rv;
}

list.forget(_retval);
return NS_OK;
}

On Wed, Aug 16, 2017 at 6:56 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> Hi folks,
>
>
> I'm still a bit confused on which types (nsCOMPtr, ...) to use when
> exactly, in combination w/ IDLs.
>
> Let's consider a case where an nsArray is created and returned
> (as rval, not out-parameter):
>
> IDL:
>
> [scriptable, uuid(ea0d8b3d-a549-4666-82d8-3a82cee2a3f1)]
> interface nsIAddrBookService : nsISupports
> {
> nsIArray FindRecipients(in AString name);
> ...
> }
>
> C++:
>
> /* nsIArray FindRecipients (in AString name); */
> NS_IMETHODIMP nsAddrBookService::FindRecipients(const nsAString & addr,
> nsIArray * *_retval)
> {
> nsresult rv = NS_OK;
> nsCOMPtr list =
> do_CreateInstance(NS_ARRAY_CONTRACTID, );
> NS_ENSURE_SUCCESS(rv, rv);
> *_retval = list;
>
return FillRecipients(addr, list);
> }
>

> I'd assume that do_CreateInstance() returns the object w/ refcnt=1.
> The assignment to nsCOMPtr should increase refcount. Correct ?
> When the function is left, the nsCOMPtr is destroyed, and refcnt
> goes back to 1 (we now have a reference left in the caller's pointer
> field).
>
> Now the caller side: (inspired by various examples ...)
>
> nsCOMPtr list;
> rv = addrBookService->FindRecipients(
> splittedRecipients[j].mEmail,
> getter_AddRefs(list));
>
> I'd guess getter_AddRefs() causes refcnt to be increased again, so
> we're back at 2. That could lead to a leak, when that function returns
> (and doesn't pass the ref anywhere else).
>
> So, should I use dont_AddRef() here ?
>
> Is the situation different when using out parameter instead of rval ?


>
> BTW: what happens when passing nsCOMPtr as a reference (w/o IDL) ?
>
> Assume the following code:
>
> void caller() {
> nsCOMPtr ref;
>
> callee(ref);
> ref->Something();
> }
>
> void callee(nsCOMPtr & outref) {
> nsCOMPtr myref = do_CreateInstance(...);
> ...
> outref = myref;
> }
>
> I'd assume that the last line will fill the caller's ref field w/ the
> pointer and increase the object's refcnt (so it's 2 now), then when
> callee is left, its myref is destroyed and refcnt is back to 1.
>
> Is that correct ?
>
>
> --mtx
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: WebVR Working Group

[Daniel Veditz]

On Wed, Aug 16, 2017 at 3:51 PM, L. David Baron  wrote:

> I still think opposing this charter because the group should still
> be in the incubation phase would be inconsistent with our shipping
> and promotion of WebVR.
>

​I agree that would be exceptionally odd and require a well reasoned
argument about why formal standardization was inappropriate.

I'm troubled that the members of the incubation group seem to feel that
chairs are being imposed on them who have been less involved (or
uninvolved?) with leading the feature to the point it's gotten so far. But
I don't understand the politics of that or whether we could or should get
involved on that point.

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

Re: Proposed W3C Charter: WebVR Working Group

[L. David Baron]

On Wednesday 2017-07-12 12:20 -0700, L. David Baron wrote:
> On Wednesday 2017-07-12 06:48 -0500, Lars Bergstrom wrote:
> > There is some contention in the WebVR community group around the submission
> > of this charter proposal, as there is currently no public support from any
> > of the implementers in making this transition away from a community group:
> > https://lists.w3.org/Archives/Public/public-webvr/2017Jul/0056.html
> 
> That's a little confusing to me given that there has been a good bit
> of movement towards shipping WebVR in release versions of browsers.
> 
> Shipping things to the release channel (as opposed to just users on
> nightly/beta channels or users who turn on experimental features)
> means that Web content could start depending on the features at any
> time, which means we might be stuck with them in their current form.
> 
> That suggests (if my understanding of the state of shipping to
> release users is correct) that it's likely time for the
> standardization process to also admit that it's no longer just
> experimenting, but actually shipping real stuff.
> 
> -David
> 
> > I would certainly not support at this time and, depending on the
> > conversations in that group and timing of the below deadline, may suggest
> > that we oppose.

So the deadline is now approaching.  Is there any update here?

I still think opposing this charter because the group should still
be in the incubation phase would be inconsistent with our shipping
and promotion of WebVR.

-David

> > On Tue, Jul 11, 2017 at 12:23 PM, L. David Baron  wrote:
> > 
> > > The W3C is proposing a new charter for:
> > >
> > >   WebVR Working Group
> > >   https://www.w3.org/2017/07/vr-wg-charter.html
> > >   https://lists.w3.org/Archives/Public/public-new-work/2017Jul/0002.html
> > >
> > > Mozilla has the opportunity to send support, comments, or objections
> > > through Friday, August 18.  If this is work that we want to see
> > > happen at W3C, we should explicitly support it; if there are things
> > > we think should be different about the charter, this is the time to
> > > say so.
> > >
> > > Please reply to this thread if you think there's something we should
> > > say as part of this charter review, or if you think we should
> > > support or oppose it.

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Re: disabled non-e10s tests on trunk

[jmaher]

On Wednesday, August 16, 2017 at 4:03:20 PM UTC-4, Nils Ohlmeier wrote:
> > On Aug 16, 2017, at 07:23, James Graham  wrote:
> > 
> > On 16/08/17 01:26, Nils Ohlmeier wrote:
> >> I guess not a lot of people are aware of it, but for WebRTC we still have 
> >> two distinct implementations for the networking code.
> >> So if I understand the impact here right we just lost test coverage for 
> >> probably a couple of thousand lines of code.
> > […]
> > 
> >> I’m not sure how others do it, but our low level C++ unit tests don’t have 
> >> an e10s mode at all.
> >> Therefore we can’t simply delete the non-e10s WebRTC networking code 
> >> either (without loosing a ton of test coverage).
> > 
> > If the networking code is only covered by C++ unit tests, there is separate 
> > code for non-e10s vs e10s,  and the unit tests don't work in e10s mode 
> > doesn't that mean we currently don't have any test coverage for our 
> > shipping configuration on desktop? What am I missing?
> 
> So we have mochitest-media which works as kind of integration test on a 
> higher level. They execute high level JS API tests, but also try to ensure 
> that the lower level networking pieces (the once which are exposed through 
> JS) match the expectations.
> The mochitest-media got executed for e10s and non-e10s and therefore covered 
> both implementations.
> 
> And then we have C++ unit tests, which cover a lot more corner cases of 
> different scenarios for networking. And yes these only work with non-e10s 
> right now. It would be a lot of work to create the same amount of tests with 
> a higher level test suite like mochitest to get the e10s coverage. Plus these 
> tests would probably take a lot execution time.
> 
> Technically that leaves us with a somewhat blind spot for the coverage of 
> networking corner cases under e10s. I guess if there is a high demand for 
> turning off all non-e10s tests we need to look at how to get our C++ unit 
> tests working with something like e10s.
> But until we can get to that I think we really should keep running 
> mochitest-media with e10s and without it.
> 
> Best
>   Nils Ohlmeier

As a note, C++ tests will continue to run in non-e10s mode (cppunit, gtest)- 
there are no plans to run these as e10s; this is mostly referring to: 
mochitest*, web-platform-test*, reftest*, marionette*
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: disabled non-e10s tests on trunk

[Nils Ohlmeier]

> On Aug 16, 2017, at 07:23, James Graham  wrote:
> 
> On 16/08/17 01:26, Nils Ohlmeier wrote:
>> I guess not a lot of people are aware of it, but for WebRTC we still have 
>> two distinct implementations for the networking code.
>> So if I understand the impact here right we just lost test coverage for 
>> probably a couple of thousand lines of code.
> […]
> 
>> I’m not sure how others do it, but our low level C++ unit tests don’t have 
>> an e10s mode at all.
>> Therefore we can’t simply delete the non-e10s WebRTC networking code either 
>> (without loosing a ton of test coverage).
> 
> If the networking code is only covered by C++ unit tests, there is separate 
> code for non-e10s vs e10s,  and the unit tests don't work in e10s mode 
> doesn't that mean we currently don't have any test coverage for our shipping 
> configuration on desktop? What am I missing?

So we have mochitest-media which works as kind of integration test on a higher 
level. They execute high level JS API tests, but also try to ensure that the 
lower level networking pieces (the once which are exposed through JS) match the 
expectations.
The mochitest-media got executed for e10s and non-e10s and therefore covered 
both implementations.

And then we have C++ unit tests, which cover a lot more corner cases of 
different scenarios for networking. And yes these only work with non-e10s right 
now. It would be a lot of work to create the same amount of tests with a higher 
level test suite like mochitest to get the e10s coverage. Plus these tests 
would probably take a lot execution time.

Technically that leaves us with a somewhat blind spot for the coverage of 
networking corner cases under e10s. I guess if there is a high demand for 
turning off all non-e10s tests we need to look at how to get our C++ unit tests 
working with something like e10s.
But until we can get to that I think we really should keep running 
mochitest-media with e10s and without it.

Best
  Nils Ohlmeier




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

Re: Intent to ship version 4 of the Safe Browsing protocol

[Daniel Veditz]

On Wed, Aug 16, 2017 at 7:20 AM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> Regarding CID vs CONTRACTID - still haven't understood why CIDs are
> random numbers, instead of human-readable names


​Someone in 1999 or 2000 thought it was a good idea and set the pattern.​

And still I find the naming "CID" (class-ID ?) vs "CONTRACTID" quite
> confusing. Why not something like "INTERFACEID" or "PROTOCOLID" vs.
>

​It is what it is and no one wants to go through millions of lines of code
renaming everything.​ Just learn it once and move on to things that matter.

Doesn't need to be that much. Less than hundred should be sufficient,
> and most of them should be orthogonal to the rest.
>

​100 options is 4950 configurations to test. More often than not things
that "should be" independent have subtle unexpected linkages. You can't
handwave away the testing through sheer optimism.

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

Re: disabled non-e10s tests on trunk

[James Graham]

On 16/08/17 19:36, Ben Kelly wrote:

My only thought about windows7-debug is that android is a variant of
linux.  Running a linux platform might be closer to android behavior.  But
I don't have a known specific difference in mind.


Right it seems like there are two use cases here:

1) Tests that are really aimed at Desktop or are cross-product but don't 
run on e10s for (reasons).


2) Tests for features that are run in e10s on Desktop, but exercise 
functional differences in non-e10s and don't run in Android.


For 1) running on Windows makes some sense because that's where most 
users are. For 2) it makes no sense because it's the most different from 
Android. For those cases running on Linux(64) makes more sense (and is 
also usually where we have most capacity, so that helps with infra issues).

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

Re: disabled non-e10s tests on trunk

[Ben Kelly]

On Wed, Aug 16, 2017 at 2:32 PM, Joel Maher  wrote:

> Thanks everyone for chiming in here.  I see this isn't as simple as a
> binary decision and to simplify things, I think turning on all non-e10s
> tests that were running for windows7-debug would give us reasonable
> coverage and ensure that users on our most popular OS (and focus for 57)
> have a stable experience if they choose to go without e10s.
>
> Instead of a date to turn things off, I would like to just focus on each
> framework one at a time and ideally in a few months we would have a clear
> set of requirements (in the form of bugs) to resolve before turning off the
> specific non-e10s tests.
>
> If there is a different configuration other than windows7-debug I would
> like to hear about it.
>

Thank you Joel.

My only thought about windows7-debug is that android is a variant of
linux.  Running a linux platform might be closer to android behavior.  But
I don't have a known specific difference in mind.

It would also be nice to opt and debug since things do differ between them,
but I'll take what I can get.

Thanks.

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

Re: disabled non-e10s tests on trunk

[Joel Maher]

Thanks everyone for chiming in here.  I see this isn't as simple as a
binary decision and to simplify things, I think turning on all non-e10s
tests that were running for windows7-debug would give us reasonable
coverage and ensure that users on our most popular OS (and focus for 57)
have a stable experience if they choose to go without e10s.

Instead of a date to turn things off, I would like to just focus on each
framework one at a time and ideally in a few months we would have a clear
set of requirements (in the form of bugs) to resolve before turning off the
specific non-e10s tests.

If there is a different configuration other than windows7-debug I would
like to hear about it.

Joel


On Wed, Aug 16, 2017 at 12:53 PM, Ehsan Akhgari 
wrote:

> On 08/15/2017 04:29 PM, jma...@mozilla.com wrote:
>
>> I would propose running these above tests on windows7-opt (we don't have
>> these running yet in windows 10, although we are close), and only running
>> specific tests which are not run in e10s mode, turning them off December
>> 29th, 2017.
>>
>> Keep in mind we have had many years to get all our tests running in e10s
>> mode and we have known since last year that Firefox 57 would be the first
>> release that we ship e10s by default to our users- my proposal is a 4 month
>> temporary measure to let test owners finish ensuring their tests are
>> running in e10s mode.
>>
> Hi Joel,
>
> I think Ben is right on here.  Please note that it's not just service
> workers that have a different implementation in e10s vs. non-e10s, many
> other super important parts of the browser are in the same boat.  For
> example, our entire HTTP(S) stack has different code paths in e10s vs.
> non-e10s.  Furthermore, even in places where we share a lot of code in the
> two modes, there are often subtle differences in the behavior in between
> the two modes.  I hope this is convincing in terms of the necessity of
> maintaining the test coverage across the two modes.
>
> To slightly readjust what you stated above from the perspective of the
> Firefox developers, we have known since last years that Firefox 57 would be
> the first release that we ship e10s by default for our *desktop* users, and
> we have also known that Firefox 57 for Android will be shipped without e10s
> for our *mobile* users, so it shouldn't be any surprise why no large scale
> effort has been put into porting all of our tests to run into e10s mode.
> Also please note that some of the test frameworks you have listed above
> like browser-chrome aren't relevant to Android, and some like jsreftests
> aren't relevant to e10s, so we should probably have a more detailed
> conversation about the remaining ones.
>
> I think a better way to think about this problem is perhaps how to get to
> a point where we never end up losing test coverage on code that we ship on
> our tier 1 platforms.  Thinking about this in terms of date-based deadlines
> where we don't have the human power to do the work necessary isn't
> particularly helpful, and would ultimately result us in losing invaluable
> test coverage.  If past history is any lesson for us, regressions will
> creep in as a result, and especially due to the fact that this is mostly
> affecting Firefox for Android where we have the lowest pre-release testing
> population among our tier1 products (AFAIK) makes that extremely risky.
>
> Therefore, I think we should:
>
>  * start running all of the non-e10s tests that can affect Android again
> immediately.
>  * work out a realistic plan between engineering and the automation team
> to address the existing gaps that prevent us from turning off non-e10s
> tests without losing coverage on Android, and execute that plan.
>  * turn non-e10s tests off when the above has been done.
>
> Please let me know what you think!
>
> Thanks,
> Ehsan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: disabled non-e10s tests on trunk

[Ehsan Akhgari]

On 08/15/2017 04:29 PM, jma...@mozilla.com wrote:

I would propose running these above tests on windows7-opt (we don't have these 
running yet in windows 10, although we are close), and only running specific 
tests which are not run in e10s mode, turning them off December 29th, 2017.

Keep in mind we have had many years to get all our tests running in e10s mode 
and we have known since last year that Firefox 57 would be the first release 
that we ship e10s by default to our users- my proposal is a 4 month temporary 
measure to let test owners finish ensuring their tests are running in e10s mode.

Hi Joel,

I think Ben is right on here.  Please note that it's not just service 
workers that have a different implementation in e10s vs. non-e10s, many 
other super important parts of the browser are in the same boat.  For 
example, our entire HTTP(S) stack has different code paths in e10s vs. 
non-e10s.  Furthermore, even in places where we share a lot of code in 
the two modes, there are often subtle differences in the behavior in 
between the two modes.  I hope this is convincing in terms of the 
necessity of maintaining the test coverage across the two modes.


To slightly readjust what you stated above from the perspective of the 
Firefox developers, we have known since last years that Firefox 57 would 
be the first release that we ship e10s by default for our *desktop* 
users, and we have also known that Firefox 57 for Android will be 
shipped without e10s for our *mobile* users, so it shouldn't be any 
surprise why no large scale effort has been put into porting all of our 
tests to run into e10s mode.  Also please note that some of the test 
frameworks you have listed above like browser-chrome aren't relevant to 
Android, and some like jsreftests aren't relevant to e10s, so we should 
probably have a more detailed conversation about the remaining ones.


I think a better way to think about this problem is perhaps how to get 
to a point where we never end up losing test coverage on code that we 
ship on our tier 1 platforms.  Thinking about this in terms of 
date-based deadlines where we don't have the human power to do the work 
necessary isn't particularly helpful, and would ultimately result us in 
losing invaluable test coverage.  If past history is any lesson for us, 
regressions will creep in as a result, and especially due to the fact 
that this is mostly affecting Firefox for Android where we have the 
lowest pre-release testing population among our tier1 products (AFAIK) 
makes that extremely risky.


Therefore, I think we should:

 * start running all of the non-e10s tests that can affect Android 
again immediately.
 * work out a realistic plan between engineering and the automation 
team to address the existing gaps that prevent us from turning off 
non-e10s tests without losing coverage on Android, and execute that plan.

 * turn non-e10s tests off when the above has been done.

Please let me know what you think!

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

Re: disabled non-e10s tests on trunk

[James Graham]

On 15/08/17 21:39, Ben Kelly wrote:

On Tue, Aug 15, 2017 at 4:37 PM, Joel Maher  wrote:


All of the above mentioned tests are not run on Android (well
mochitest-media is to some degree).  Is 4 months unreasonable to fix the
related tests that do not run in e10s?  Is there another time frame that
seems more reasonable?



Last I checked it was your team that told me WPT on android was not an
immediate priority.  The WPT harness itself does not run there.


FWIW the story with wpt/Android is that originally Android didn't 
support the kind of remote control required to run wpt tests (i.e. 
marionette). That has subsequently been fixed, and it's believed to be 
possible incorporate Android into the wpt harness without a significant 
refactoring, but after that there is substantial, time consuming, work 
required to get from "it runs" to "this is a thing we can run in 
production".


I doubt that the work required to implement an Android backend, sort out 
issues with the relative slowness of the android emulator, and green up 
the tests, would be less than one person's work for a quarter. Even once 
this is done there would likely be ongoing problems updating the 
metadata on android for syncs from upstream simply from the additional 
slowness of try runs and probable additional intermittency.


So far there haven't been enough people working on wpt to make this a 
priority relative to other goals. Given the situation with e10s, it 
seems reasonable to reassess this when planning future work, but I 
wouldn't bet on such work being complete by Dec. 29th this year.

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

Re: disabled non-e10s tests on trunk

[James Graham]

On 16/08/17 01:26, Nils Ohlmeier wrote:

I guess not a lot of people are aware of it, but for WebRTC we still have two 
distinct implementations for the networking code.
So if I understand the impact here right we just lost test coverage for 
probably a couple of thousand lines of code.

[…]


I’m not sure how others do it, but our low level C++ unit tests don’t have an 
e10s mode at all.
Therefore we can’t simply delete the non-e10s WebRTC networking code either 
(without loosing a ton of test coverage).


If the networking code is only covered by C++ unit tests, there is 
separate code for non-e10s vs e10s,  and the unit tests don't work in 
e10s mode doesn't that mean we currently don't have any test coverage 
for our shipping configuration on desktop? What am I missing?

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

Re: Intent to ship version 4 of the Safe Browsing protocol

[Enrico Weigelt, metux IT consult]

On 16.08.2017 12:40, Gijs Kruitbosch wrote:


This and other queries like it are best asked and answered on  > 
https://support.mozilla.org/ .


Unfortunately, it only tells how to switch some things off, but
not to remove it entirely. Neither does it tell anything about the
security implications of sending meta data to dubious corporations.

Furthermore, just like with your  > next-most-recent posts (about nsString and printf, and about CIDs), 

the > answer is already documented and easily found using a web search:
If the docs wouldn't answer all my questions, I wouldn't have asked in
the first place. I'd volunteer to update the docs, but obviously I need
the proper information for that first.

https://developer.mozilla.org/en-US/search?q=printf

--> nothing about using printf() here :(

Regarding CID vs CONTRACTID - still haven't understood why CIDs are
random numbers, instead of human-readable names (similar to hierarchical
class names, eg. "org.mozilla.collections.array) ?

And still I find the naming "CID" (class-ID ?) vs "CONTRACTID" quite
confusing. Why not something like "INTERFACEID" or "PROTOCOLID" vs.
"SERVICEID" ?

The term "contract" isn't entirely obvious (to non-moz folks), it's
often used for interface (the way I can talk to something), instead
of a collection of interfaces / a service that might have multiple
interface.

I also believe your reflexive responses along the line of "how can I get  > a version of Firefox that doesn't have X" for every X (you don't 

like) > that happens to come up in this group are unproductive.

This "reflex" comes from the tendency that more and more things are
added - even things that contradict the whole spirit of free software,
like despotic restriction management (even downloads the malware on
its own) - and then we downstreams (packagers, integrators, operators)
have the huge burden of getting these things under control.

Please also consider, that there's more than average John Doe user,
and there're lots of reasons for disabling things (not even compile
them in the first place). Limited resources may be one of them.
Security concerns, managebility, etc, may be others. One's killer
feature can be another one's misfeature. Therefore it's important
that things can be turned off / removed easily (the optimum would
be external components that can be deployed separately).

A bunch of configure options are currently broken, some can't be
easily repaired (w/o touching xpidlgen to add preprocessor).

The answer to that last question is almost invariably "no". There are  > usually prefs while features are being developed, but those will > 
frequently get removed when features are mature enough that we don't > 
think turning them off is web-compatible.


How exactly is "web-compatible" specified here ?
Does it include $megacorp's servers or automatically download
and execute arbitrary binaries or allow tracking users ?

Firefox and Gecko are  > explicitly *not* aiming to have 42,000 build-time defines to remove > 

every conceivable feature that someone might not want.

Doesn't need to be that much. Less than hundred should be sufficient,
and most of them should be orthogonal to the rest.


--mtx

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

Async Iteration rides the trains

[Tooru Fujisawa]

Hi all.

I've landed a patch that enables Async Iteration [1] (async generator and 
for-await-of syntax) on non-nightly and also in chrome code, in bug 1352312 [2].
(that was nightly-only and content-only from bug 1331092 [3])

so now it's available from firefox 57, but I'd suggest waiting for 1-2 cycles 
before start using it in chrome code,
just like we did for Async Function, so that things don't break even if it gets 
disabled again for some reason or when it hits some issue.
(and it would also make uplift easier)

[1] https://tc39.github.io/proposal-async-iteration/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1352312
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1331092

--
arai

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

refcounting - which types to use ?

[Enrico Weigelt, metux IT consult]

Hi folks,


I'm still a bit confused on which types (nsCOMPtr, ...) to use when
exactly, in combination w/ IDLs.

Let's consider a case where an nsArray is created and returned
(as rval, not out-parameter):

IDL:

[scriptable, uuid(ea0d8b3d-a549-4666-82d8-3a82cee2a3f1)]
interface nsIAddrBookService : nsISupports
{
nsIArray FindRecipients(in AString name);
...
}

C++:

/* nsIArray FindRecipients (in AString name); */
NS_IMETHODIMP nsAddrBookService::FindRecipients(const nsAString & addr, 
nsIArray * *_retval)

{
nsresult rv = NS_OK;
nsCOMPtr list =
do_CreateInstance(NS_ARRAY_CONTRACTID, );
NS_ENSURE_SUCCESS(rv, rv);
*_retval = list;
return FillRecipients(addr, list);
}

I'd assume that do_CreateInstance() returns the object w/ refcnt=1.
The assignment to nsCOMPtr should increase refcount. Correct ?
When the function is left, the nsCOMPtr is destroyed, and refcnt
goes back to 1 (we now have a reference left in the caller's pointer
field).

Now the caller side: (inspired by various examples ...)

nsCOMPtr list;
rv = addrBookService->FindRecipients(
splittedRecipients[j].mEmail,
getter_AddRefs(list));

I'd guess getter_AddRefs() causes refcnt to be increased again, so
we're back at 2. That could lead to a leak, when that function returns
(and doesn't pass the ref anywhere else).

So, should I use dont_AddRef() here ?

Is the situation different when using out parameter instead of rval ?


BTW: what happens when passing nsCOMPtr as a reference (w/o IDL) ?

Assume the following code:

void caller() {
nsCOMPtr ref;

callee(ref);
ref->Something();
}

void callee(nsCOMPtr & outref) {
nsCOMPtr myref = do_CreateInstance(...);
...
outref = myref;
}

I'd assume that the last line will fill the caller's ref field w/ the
pointer and increase the object's refcnt (so it's 2 now), then when
callee is left, its myref is destroyed and refcnt is back to 1.

Is that correct ?


--mtx

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

Re: Intent to ship version 4 of the Safe Browsing protocol

[Gijs Kruitbosch]

On 16/08/2017 11:11, Enrico Weigelt, metux IT consult wrote:

On 16.08.2017 01:46, Francois Marier wrote:

After a year's worth of development, bug fixes, and integration testing,
we are now ready to enable the latest version [1] of the Safe Browsing
API in Firefox 56, two releases ahead of schedule and only a few weeks
behind Chrome.


How can I get rid of that ?
I don't want my browser to call google servers, nor do I want allow
google to decide what's malware and what's not.


This and other queries like it are best asked and answered on 
https://support.mozilla.org/ . Furthermore, just like with your 
next-most-recent posts (about nsString and printf, and about CIDs), the 
answer is already documented and easily found using a web search:


https://duckduckgo.com/?q=turn+off+firefox+safebrowsing=hb=web
https://duckduckgo.com/?q=mozilla+nsstring+printf=hb=web
https://duckduckgo.com/?q=cid+xpcom=hb=qa

The first page of results for all these queries all have several 
reasonable answers to them. Please use resources like web search, MDN or 
support.mozilla.org first, instead of posting here.


I also believe your reflexive responses along the line of "how can I get 
a version of Firefox that doesn't have X" for every X (you don't like) 
that happens to come up in this group are unproductive. Presumably you 
know that we have pretty decent code search tools at 
https://dxr.mozilla.org/ and http://searchfox.org/, which can help you 
answer questions like "where does this code live", "what prefs govern 
it" and "is there a build option to not include it".


The answer to that last question is almost invariably "no". There are 
usually prefs while features are being developed, but those will 
frequently get removed when features are mature enough that we don't 
think turning them off is web-compatible. Firefox and Gecko are 
explicitly *not* aiming to have 42,000 build-time defines to remove 
every conceivable feature that someone might not want. It's already been 
established in previous threads that for your usecase (where you want to 
not build lots of features), you basically need to fork Gecko. It helps 
nobody to revisit that same subject whenever a feature you don't like 
comes up, and effectively derails the relevant threads announcing 
features or feature updates. Please stop doing that.


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

Re: Intent to ship version 4 of the Safe Browsing protocol

[Enrico Weigelt, metux IT consult]

On 16.08.2017 01:46, Francois Marier wrote:

After a year's worth of development, bug fixes, and integration testing,
we are now ready to enable the latest version [1] of the Safe Browsing
API in Firefox 56, two releases ahead of schedule and only a few weeks
behind Chrome.


How can I get rid of that ?
I don't want my browser to call google servers, nor do I want allow
google to decide what's malware and what's not.

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