Re: refcounting - which types to use ?
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
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 ?
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, &rv); 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, &rv); > 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
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
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
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
> 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
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
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
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
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
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
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
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
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
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 ?
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, &rv); 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
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&t=hb&ia=web https://duckduckgo.com/?q=mozilla+nsstring+printf&t=hb&ia=web https://duckduckgo.com/?q=cid+xpcom&t=hb&ia=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
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