Re: Dropping support for MSVC2012
On 2015-01-02 4:36 AM, Kent James wrote: On 1/1/2015 3:08 PM, Ryan VanderMeulen wrote: Having just filed my fourth MSVC2012 is busted bug since we dropped support for 2010 a few weeks ago, I'm wondering what the point of even supporting 2012 is? Are there any licensing/OS support/etc advantages to keeping it around vs. just leaving 2013 as our only supported compiler? Because there's certainly a non-zero cost to supporting it at this point. Note that MSVC 2012 is supported in the sense that we'd accept patches that help fix it, and we won't check in patches that require compiler features that 2012 does not support. Traditionally people who use compilers different than what we use on our infra may face local build issues from time to time, and this is not specific only to MSVC 2012. The issue for me is that there were multiple patches required to support VS2013 in the first place, and AFAIK these have not been ported to older gecko versions. So I don't believe that you can compile esr31 with VS2013. Why is that an issue? When we discuss dropping support for compilers, we only talk about mozilla-central, and you should be able to install MSVC2012 and 2013 side by side and use the compiler you want depending on what tree you are trying to build. It would be much easier to keep it running if there was at least one builder that ran VS2012 that failed when someone checks in a compile that breaks it. The non-zero cost is mostly fixing there regressions, and would be much lower cost if they were caught earlier. But what benefit would we get out of doing that? Keeping MSVC2012 working should not be a goal to itself. I can't think of what benefit adding official support for MSVC2012 can have. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
On Friday 2015-01-02 14:23 +0100, Robert Kaiser wrote: Seth Fowler schrieb: On Dec 17, 2014, at 10:08 PM, James May m...@fowlsmurf.net wrote: * Is there telemetry for this? There isn’t telemetry specifically for non-MJPEG usage of multipart/x-mixed-replace images. Given that I’ve never seen them used outside of our test suite, I don’t think we need telemetry to make this particular decision, although generally it’s a good idea. Letting the change ride the trains, and making sure that it’s easy to back out if a problem is found, should suffice. IMHO, I haven't seen is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. I don't think that' necessary for features that aren't supported across other browser engines, which I believe is the case here. -David -- 턞 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: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
Seth Fowler schrieb: On Dec 17, 2014, at 10:08 PM, James May m...@fowlsmurf.net wrote: * Is there telemetry for this? There isn’t telemetry specifically for non-MJPEG usage of multipart/x-mixed-replace images. Given that I’ve never seen them used outside of our test suite, I don’t think we need telemetry to make this particular decision, although generally it’s a good idea. Letting the change ride the trains, and making sure that it’s easy to back out if a problem is found, should suffice. IMHO, I haven't seen is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 1/1/2015 3:08 PM, Ryan VanderMeulen wrote: Having just filed my fourth MSVC2012 is busted bug since we dropped support for 2010 a few weeks ago, I'm wondering what the point of even supporting 2012 is? Are there any licensing/OS support/etc advantages to keeping it around vs. just leaving 2013 as our only supported compiler? Because there's certainly a non-zero cost to supporting it at this point. The issue for me is that there were multiple patches required to support VS2013 in the first place, and AFAIK these have not been ported to older gecko versions. So I don't believe that you can compile esr31 with VS2013. It would be much easier to keep it running if there was at least one builder that ran VS2012 that failed when someone checks in a compile that breaks it. The non-zero cost is mostly fixing there regressions, and would be much lower cost if they were caught earlier. :rkent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What does the sameZoneAs option on the Cu.Sandbox do?
I'm sorry, I'm a bit new to this, so the intricacies of the javascript scopes and zones aren't yet very clear to me. Does that mean that the globals of the content script will automatically be cleaned up if the tab is closed or is it just a technicality of the GC and do you still have to do cleanup? Eg. compared to being in the same zone of the window or not, what exactly happens differently? Should an explanation of this be added to the MDN page? I wouldn't mind to do it, but I don't feel I understand enough to give a good wording to it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-02 1:31 PM, Kent James wrote: On 1/2/2015 6:23 AM, Ehsan Akhgari wrote: Note that MSVC 2012 is supported in the sense that we'd accept patches that help fix it, and we won't check in patches that require compiler features that 2012 does not support. Traditionally people who use compilers different than what we use on our infra may face local build issues from time to time, and this is not specific only to MSVC 2012. What has become clear is that MVCV 2012 is NOT actually supported in the second sense, but only in the first sense. That is, we do check in patches that break VS 2012, and those patches are not backed out when the breakage is discovered. Yes, exactly my point. The way to fix that is by adding automatic builders that test for VS 2012 breakage. If that is not done, then people should be strongly discouraged from using VS 2012 rather than saying it is supported. Yes, people should be discouraged from using MSVC2012 locally. Please note that: a) It is impractical for Mozilla to test every single toolchain that every single developer out there uses. If you want any kind of guarantee that your builds will keep working, you should use MSVC2013 on trunk and MSVC2010 on older versions than 37. b) MSVC2012 has *never* been a supported compiler in the second sense, and we have never used it on our infra (except for a short while for testing unofficial Win64 builds, and I believe that is no longer the case.) The issue for me is that there were multiple patches required to support VS2013 in the first place, and AFAIK these have not been ported to older gecko versions. So I don't believe that you can compile esr31 with VS2013. Why is that an issue? When we discuss dropping support for compilers, we only talk about mozilla-central, and you should be able to install MSVC2012 and 2013 side by side and use the compiler you want depending on what tree you are trying to build. I would hope that you would be considering the larger question of what is optimal for the developer community, and not simply what does not break mozilla-central. Yes I suppose that developers can figure out how to install multiple versions of VS on their computers, but that just adds one more obstacle to developing with Mozilla. Isn't making it easier to contribute supposed to be a goal? Developers should use MSVC2013 locally. And that is true no matter whether we decide to keep or drop support for MSVC2012. But actually what will probably happen is that people will just install VS 2013, and then when it comes to to check if their patch runs on esr31 they'll just not bother to recompile since it involves the onerous task of adding support to their system for an older compiler. That would have real quality ramifications. I know that what I'll do initially is just upgrade to VS 2013 on my development machine now and hope that I am sufficiently motivated to install VS2012 when it comes time to test something on esr31. Testing whether or not something works on esr31 is best done on the try server. Or, if that's something that you do very often, you need to install and use MSVC2010 for it. MSVC2012 is not the answer. But what benefit would we get out of doing that? Keeping MSVC2012 working should not be a goal to itself. I can't think of what benefit adding official support for MSVC2012 can have. If by adding official support you mean adding automatic tests, the benefit is to actually make VS 2012 viable, which it is increasingly becoming not viable. That is, you will actually do what you already claim that you do, namely we won't check in patches that require compiler features that 2012 does not support To be perfectly clear, I am very strongly opposed for us to spend any money or time to run and test MSVC2012 builds on our infra, even if we choose to keep support for it. We just cannot test every single build configuration out there, and yours is not the only one that differs from what we test on the infra. But I can see that the support for this is weak. I don't think that dropping VS 2012 support is correct obviously, but I am not going to continue arguing for it. I suppose I'll just have to deal with the additional complexity of supporting multiple VS versions. Add another few percentage points to the already-too-high fraction of my time spent just keeping things building instead of actually fixing bugs. To me, the default answer to whether we should keep supporting MSVC2012 is no, merely because it will require time and effort that will not directly benefit our users as we do not use that compiler to release Firefox. That is, without someone coming up with a good reason otherwise, we should drop it. And not having it locally installed is not a good reason. :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 1/2/2015 6:23 AM, Ehsan Akhgari wrote: Note that MSVC 2012 is supported in the sense that we'd accept patches that help fix it, and we won't check in patches that require compiler features that 2012 does not support. Traditionally people who use compilers different than what we use on our infra may face local build issues from time to time, and this is not specific only to MSVC 2012. What has become clear is that MVCV 2012 is NOT actually supported in the second sense, but only in the first sense. That is, we do check in patches that break VS 2012, and those patches are not backed out when the breakage is discovered. The way to fix that is by adding automatic builders that test for VS 2012 breakage. If that is not done, then people should be strongly discouraged from using VS 2012 rather than saying it is supported. The issue for me is that there were multiple patches required to support VS2013 in the first place, and AFAIK these have not been ported to older gecko versions. So I don't believe that you can compile esr31 with VS2013. Why is that an issue? When we discuss dropping support for compilers, we only talk about mozilla-central, and you should be able to install MSVC2012 and 2013 side by side and use the compiler you want depending on what tree you are trying to build. I would hope that you would be considering the larger question of what is optimal for the developer community, and not simply what does not break mozilla-central. Yes I suppose that developers can figure out how to install multiple versions of VS on their computers, but that just adds one more obstacle to developing with Mozilla. Isn't making it easier to contribute supposed to be a goal? But actually what will probably happen is that people will just install VS 2013, and then when it comes to to check if their patch runs on esr31 they'll just not bother to recompile since it involves the onerous task of adding support to their system for an older compiler. That would have real quality ramifications. I know that what I'll do initially is just upgrade to VS 2013 on my development machine now and hope that I am sufficiently motivated to install VS2012 when it comes time to test something on esr31. But what benefit would we get out of doing that? Keeping MSVC2012 working should not be a goal to itself. I can't think of what benefit adding official support for MSVC2012 can have. If by adding official support you mean adding automatic tests, the benefit is to actually make VS 2012 viable, which it is increasingly becoming not viable. That is, you will actually do what you already claim that you do, namely we won't check in patches that require compiler features that 2012 does not support But I can see that the support for this is weak. I don't think that dropping VS 2012 support is correct obviously, but I am not going to continue arguing for it. I suppose I'll just have to deal with the additional complexity of supporting multiple VS versions. Add another few percentage points to the already-too-high fraction of my time spent just keeping things building instead of actually fixing bugs. :rkent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-01-02 2:03 PM, Brian Smith wrote: In this case, the problem is that I wrote a patch to explicitly delete (= delete) some members of classes in mozilla::pkix. mozilla::pkix cannot depend on MFBT for licensing and build independence reasons (e.g. so it can be put into NSS). I don't want to add the equivalent of MOZ_DELETE to mozilla::pkix just to make MSVC2012 work. = delete currently cannot be used in Mozilla code according to https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code. I realize that now. It is very unfortunate that the rules for using C++ in Mozilla code are not simply if it passes tryserver, it's OK. I hope that Mozilla accelerates its deprecation for old compilers (GCC less than 4.8, in particular, so that enum class can be used safely) and improves the automation. I am not sure why you don't want to add the equivalent of MOZ_DELETE given how easy that is. Our personal opinion about MSVC2012 aside, without a decision to drop support for MSVC2012, we cannot say no to fixing the build issues specific to that compiler, and such decision has not been made so far. First, I will back out the offending patch pending a resolution of this discussion, in the interests of being a good team player while this discussion unfolds. I've already asked a VS2012 user to review the patch here: https://bugzilla.mozilla.org/show_bug.cgi?id=1117003#c3 However, I think my time is better spent arguing for dropping MSVC2012 support (and allowing = delete) than writing another = delete macro. So, let's try to resolve that it is OK to drop MSVC2012 support in Firefox 37 now. We shouldn't hold people to supporting MSVC2012 without a way to verify that MSVC2012 can build the code correctly on tryserver. That is, it is unreasonable to require that we won't check in patches that require compiler features that 2012 does not support if MSVC2012 is not in tryserver. It's especially an unnecessary burden on us independent contributors. FWIW people fix compiler issues that cannot be tested on try server all the time. Because I develop on Windows and most others develop on Linux, I am disproportionately involved in these bugs, which usually affect differences in fail-on-warnings behavior between Windows and newer clang versions. That's why I'd like for us to resolve to move forward to increasing minimum compiler versions at a faster pace, because that seems like an effective and cheap way of reducing the occurrences of such issues. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-02 2:03 PM, Brian Smith wrote: Ehsan wrote: Note that MSVC 2012 is supported in the sense that we'd accept patches that help fix it, and we won't check in patches that require compiler features that 2012 does not support. In this case, the problem is that I wrote a patch to explicitly delete (= delete) some members of classes in mozilla::pkix. mozilla::pkix cannot depend on MFBT for licensing and build independence reasons (e.g. so it can be put into NSS). I don't want to add the equivalent of MOZ_DELETE to mozilla::pkix just to make MSVC2012 work. = delete currently cannot be used in Mozilla code according to https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code. I am not sure why you don't want to add the equivalent of MOZ_DELETE given how easy that is. Our personal opinion about MSVC2012 aside, without a decision to drop support for MSVC2012, we cannot say no to fixing the build issues specific to that compiler, and such decision has not been made so far. It would be much easier to keep it running if there was at least one builder that ran VS2012 that failed when someone checks in a compile that breaks it. The non-zero cost is mostly fixing there regressions, and would be much lower cost if they were caught earlier. But what benefit would we get out of doing that? Keeping MSVC2012 working should not be a goal to itself. I can't think of what benefit adding official support for MSVC2012 can have. We shouldn't hold people to supporting MSVC2012 without a way to verify that MSVC2012 can build the code correctly on tryserver. That is, it is unreasonable to require that we won't check in patches that require compiler features that 2012 does not support if MSVC2012 is not in tryserver. It's especially an unnecessary burden on us independent contributors. FWIW people fix compiler issues that cannot be tested on try server all the time. It's OK if you don't want to do the work of fixing this yourself, but it seems like you are arguing against fixing the issue even if someone else provides a fix. Those are two separate matters. :-) The best solution is to just drop MSVC2012 support and officially allow features like = delete to be used from Gecko 37 onward. I am personally in favor of dropping support for MSVC2012, but before we do that, we should accept a fix for this particular issue. I would be interested to see if anyone else has a good reason for us to not drop support for MSVC2012. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: Dropping support for MSVC2012
Ehsan wrote: Note that MSVC 2012 is supported in the sense that we'd accept patches that help fix it, and we won't check in patches that require compiler features that 2012 does not support. In this case, the problem is that I wrote a patch to explicitly delete (= delete) some members of classes in mozilla::pkix. mozilla::pkix cannot depend on MFBT for licensing and build independence reasons (e.g. so it can be put into NSS). I don't want to add the equivalent of MOZ_DELETE to mozilla::pkix just to make MSVC2012 work. It would be much easier to keep it running if there was at least one builder that ran VS2012 that failed when someone checks in a compile that breaks it. The non-zero cost is mostly fixing there regressions, and would be much lower cost if they were caught earlier. But what benefit would we get out of doing that? Keeping MSVC2012 working should not be a goal to itself. I can't think of what benefit adding official support for MSVC2012 can have. We shouldn't hold people to supporting MSVC2012 without a way to verify that MSVC2012 can build the code correctly on tryserver. That is, it is unreasonable to require that we won't check in patches that require compiler features that 2012 does not support if MSVC2012 is not in tryserver. It's especially an unnecessary burden on us independent contributors. The best solution is to just drop MSVC2012 support and officially allow features like = delete to be used from Gecko 37 onward. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Supporting binary keys in IndexedDB
Supporting binary keys in IndexedDB is a proposed enhancement[1] to the standard, referred to some in the related discussion as straightforward[2]. Chromium has an implementation of this behind a flag. I'd like to potentially work on adding support for this enhancement to Firefox, but thought I'd speak up here before investing too much in doing so, since perhaps existing contributors might have already started on it. Finally, I am new to contributing to Firefox, so if there's a better forum for this discussion (perhaps I should just open a mozilla bug to correspond to the w3c issue?), a pointer would be appreciated. Thanks, - Chas [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23332 [2] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0149.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What does the sameZoneAs option on the Cu.Sandbox do?
On Jan 1, 2015, at 10:31 PM, Bobby Holley bobbyhol...@gmail.com wrote: It indicates the GC region that the sandbox will be placed in. It has no effect on correctness, but memory usage will be better if globals which die at the same time are allocated in the same zone. This is why content scripts pass the window they run against for sameZoneAs - both the content and the content script will get cleaned up at the same time. I've added a bit to https://developer.mozilla.org/en-US/docs/Components.utils.Sandbox#Sandbox_options to cover this option. I see there are other not-yet-documented options, too, but I didn't get into them. Eric Shepherd Developer Documentation Lead Mozilla http://www.bitstampede.com/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What does the sameZoneAs option on the Cu.Sandbox do?
On Jan 2, 2015, at 12:37 PM, Eric Shepherd esheph...@mozilla.com wrote: I've added a bit to https://developer.mozilla.org/en-US/docs/Components.utils.Sandbox#Sandbox_options to cover this option. I see there are other not-yet-documented options, too, but I didn't get into them. I also filed bug 1117143 (https://bugzilla.mozilla.org/show_bug.cgi?id=1117143) to make sure we don't forget to someday update this content. Eric Shepherd Developer Documentation Lead Mozilla http://www.bitstampede.com/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules
I feel a lot less embarrassed about not finding that bug number now that I know how long this thread has been running. :) Eric Shepherd Developer Documentation Lead Mozilla http://www.bitstampede.com/ On Dec 30, 2014, at 12:25 PM, L. David Baron dba...@dbaron.org wrote: From the message at the start of the thread (six months ago): https://bugzilla.mozilla.org/show_bug.cgi?id=664104 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-02 3:32 PM, Brian Smith wrote: Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-01-02 2:03 PM, Brian Smith wrote: In this case, the problem is that I wrote a patch to explicitly delete (= delete) some members of classes in mozilla::pkix. mozilla::pkix cannot depend on MFBT for licensing and build independence reasons (e.g. so it can be put into NSS). I don't want to add the equivalent of MOZ_DELETE to mozilla::pkix just to make MSVC2012 work. = delete currently cannot be used in Mozilla code according to https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code. I realize that now. It is very unfortunate that the rules for using C++ in Mozilla code are not simply if it passes tryserver, it's OK. I hope that Mozilla accelerates its deprecation for old compilers (GCC less than 4.8, in particular, so that enum class can be used safely) and improves the automation. We are *very* interested in supporting fewer compiler versions as well. There are usually some factors that limit how aggressive we can be here (such as Linux distros using gcc versions older than what we'd like, and the b2g toolchain dependencies that we cannot necessarily control). Thanks for being patient while we get better at this. :-) FWIW to the best of my knowledge, we have kept the last two MSVC releases supported for quite a long time, but I don't know if there has ever been a good reason for that (besides people having them installed locally.) I would very much like us to change that tradition! I am not sure why you don't want to add the equivalent of MOZ_DELETE given how easy that is. Our personal opinion about MSVC2012 aside, without a decision to drop support for MSVC2012, we cannot say no to fixing the build issues specific to that compiler, and such decision has not been made so far. First, I will back out the offending patch pending a resolution of this discussion, in the interests of being a good team player while this discussion unfolds. I've already asked a VS2012 user to review the patch here: https://bugzilla.mozilla.org/show_bug.cgi?id=1117003#c3 Thank you! However, I think my time is better spent arguing for dropping MSVC2012 support (and allowing = delete) than writing another = delete macro. So, let's try to resolve that it is OK to drop MSVC2012 support in Firefox 37 now. That's fair. :-) FWIW as I said elsewhere in the thread I think that the default answer at the lack of evidence to the contrary should be for us to drop MSVC2012, so perhaps you don't need to argue that strongly after all! Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
L. David Baron schrieb: On Friday 2015-01-02 14:23 +0100, Robert Kaiser wrote: Seth Fowler schrieb: On Dec 17, 2014, at 10:08 PM, James May m...@fowlsmurf.net wrote: * Is there telemetry for this? There isn’t telemetry specifically for non-MJPEG usage of multipart/x-mixed-replace images. Given that I’ve never seen them used outside of our test suite, I don’t think we need telemetry to make this particular decision, although generally it’s a good idea. Letting the change ride the trains, and making sure that it’s easy to back out if a problem is found, should suffice. IMHO, I haven't seen is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. I don't think that' necessary for features that aren't supported across other browser engines, which I believe is the case here. We have been burned by removing Gecko-only features in JS land, that's why even that reasoning is dangerous in general. For this specific case everything might be fine, I don't dispute that, but we shouldn't do removals of web-exposed features without good data in general. Can we at least have a very small telemetry probe along with this specific removal (can be removed in the next train again), so we can get at least some data from beta users if there are cases encountered of those features we remove? I'd have guessed we all, including Seth, would be happier if we have data confirmation of us doing the right thing here. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
I'd say this is far enough out towards extreme edge case land that we can be a bit more aggressive here compared to general feature removals. So agreed. On Fri, Jan 2, 2015 at 1:52 PM, Seth Fowler s...@mozilla.com wrote: On Jan 2, 2015, at 7:16 AM, L. David Baron dba...@dbaron.org wrote: IMHO, I haven't seen is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. I don't think that' necessary for features that aren't supported across other browser engines, which I believe is the case here. That is true. IE does not support this feature at all. I completely concur that in general we should gather telemetry before removing a feature that’s exposed to the web, but I just don’t see it as adding much value for this *particular* case. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- jst ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Supporting binary keys in IndexedDB
On Sat, Jan 3, 2015 at 2:34 AM, c...@cemerick.com wrote: Supporting binary keys in IndexedDB is a proposed enhancement[1] to the standard, referred to some in the related discussion as straightforward[2]. Chromium has an implementation of this behind a flag. I'd like to potentially work on adding support for this enhancement to Firefox, but thought I'd speak up here before investing too much in doing so, since perhaps existing contributors might have already started on it. Finally, I am new to contributing to Firefox, so if there's a better forum for this discussion (perhaps I should just open a mozilla bug to correspond to the w3c issue?), a pointer would be appreciated. It would be nice if you could submit a bug of this in our bugzilla, and then send an Intend to implement to this mailing list. You can find some examples here: https://groups.google.com/forum/#!searchin/mozilla.dev.platform/intend$20to$20implement - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
On Jan 2, 2015, at 7:16 AM, L. David Baron dba...@dbaron.org wrote: IMHO, I haven't seen is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. I don't think that' necessary for features that aren't supported across other browser engines, which I believe is the case here. That is true. IE does not support this feature at all. I completely concur that in general we should gather telemetry before removing a feature that’s exposed to the web, but I just don’t see it as adding much value for this *particular* case. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What does the sameZoneAs option on the Cu.Sandbox do?
On Fri, Jan 2, 2015 at 4:11 AM, Naja Melan najame...@autistici.org wrote: Does that mean that the globals of the content script will automatically be cleaned up if the tab is closed No. or is it just a technicality of the GC and do you still have to do cleanup? Correct (as in, you need to stop holding references to the sandbox, or use Cu.nukeSandbox. Eg. compared to being in the same zone of the window or not, what exactly happens differently? It's basically just a hint for the GC so that it can organize the heap in a way that large chunks of contiguous data can be freed simultaneously. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 2015-01-02 5:04 PM, RyanVM wrote: Are there any licensing/OS support/other issues that would encourage us to keep support for MSVC2012 hanging around? Both compilers support Windows 7 and above, and the express version of both compilers is freely (as in beer!) available (MSVC2012 cannot be downloaded from Microsoft any more, at least not in an obvious way.) So I think there is no difference that would encourage us to keep support for MSVC2012 around. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
Are there any licensing/OS support/other issues that would encourage us to keep support for MSVC2012 hanging around? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
