Re: JavaScript code coverage
On 27/01/2015 18:29, Gregory Szorc wrote: I thought someone did experiments with the Debugger API and concluded that using it to capture code coverage was too slow to be practical: we need something built into the engine that is fast. Also, part of the Engineering Operations Strategic Plan is to provide better data and metrics (including code coverage). Speaking as a member of that organization, I'd love to deliver JavaScript code coverage. I'm pretty sure we need the SpiderMonkey Team to step up and implement something. Is it too hard for a Google Summer of code project? Thanks, Sylvestre ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reversely iterating nsTArray
On Wed, Jan 28, 2015 at 7:39 PM, Cameron McCormack c...@mcc.id.au wrote:
Xidorn Quan:
I asked a question in #developers that what is the best way to reversely
iterating nsTArray, and there are some suggestions:
For cases where we don’t need to know the index of the array, can we
support something like:
for (e : array.ReverseIterator()) { ... }
or:
for (e : ReverseIterator(array)) { ... }
(I notice that boost::adaptors::reversed is something like this.)
There’s a danger that it’s not clear what happens if you modify the
array while using the iterator, but it’s probably no worse than using
the indexes that would come from ReverseIntegerRange.
Hmm. It reminds me that we might not need a ReverseIntegerRange at all. We
can have a Range, and a Reversed, then combine them to achieve
ReversedRange. We can make Reversed works with nsTArray as well :)
- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Reversely iterating nsTArray
Xidorn Quan:
I asked a question in #developers that what is the best way to reversely
iterating nsTArray, and there are some suggestions:
For cases where we don’t need to know the index of the array, can we
support something like:
for (e : array.ReverseIterator()) { ... }
or:
for (e : ReverseIterator(array)) { ... }
(I notice that boost::adaptors::reversed is something like this.)
There’s a danger that it’s not clear what happens if you modify the
array while using the iterator, but it’s probably no worse than using
the indexes that would come from ReverseIntegerRange.
--
Cameron McCormack ≝ http://mcc.id.au/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Reversely iterating nsTArray
Fiddlesticks! I’d have immediate use for both of those things, that’s why I suggested them. Also, the first suggestion is probably actually less typing than not doing it that way. You’re basically writing ‘template typename T’ at the front, where you lose some characters, but then you make it up every time you type ’T’ instead of ‘uint32_t’ or whatever you’d have used otherwise. =) - Seth On Jan 27, 2015, at 11:47 PM, Kyle Huey m...@kylehuey.com wrote: On Wed, Jan 28, 2015 at 1:18 PM, Seth Fowler s...@mozilla.com mailto:s...@mozilla.com wrote: Sounds good! +1 from me. Bike shedding: - Make Range() and ReverseRange() templates, so you can use them with any type that supports the appropriate operators. This also implies removing ‘Integer’ from their names, I think. - It’d be nice to add a constructor that supports specifying both the beginning and the end points, and another constructor that further supports specifying a stride. YAGNI*. Someone can implement those once they need them. - Kyle * You aren't gonna need it ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reversely iterating nsTArray
Yes, that’s a good idea! I like this even better than the original proposal.
- Seth
On Jan 28, 2015, at 1:59 AM, Xidorn Quan quanxunz...@gmail.com wrote:
On Wed, Jan 28, 2015 at 7:39 PM, Cameron McCormack c...@mcc.id.au
mailto:c...@mcc.id.au wrote:
Xidorn Quan:
I asked a question in #developers that what is the best way to reversely
iterating nsTArray, and there are some suggestions:
For cases where we don’t need to know the index of the array, can we
support something like:
for (e : array.ReverseIterator()) { ... }
or:
for (e : ReverseIterator(array)) { ... }
(I notice that boost::adaptors::reversed is something like this.)
There’s a danger that it’s not clear what happens if you modify the
array while using the iterator, but it’s probably no worse than using
the indexes that would come from ReverseIntegerRange.
Hmm. It reminds me that we might not need a ReverseIntegerRange at all. We
can have a Range, and a Reversed, then combine them to achieve
ReversedRange. We can make Reversed works with nsTArray as well :)
- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org mailto:dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On Tue, Jan 27, 2015 at 11:31 PM, Chris Peterson cpeter...@mozilla.com wrote: Are there recent studies of which features servers do detect and why? I could see arguments for sharing information about mobile devices, touch support, and OS. Long ago I used to do development for MediaWiki. We had UA string checks to work around certain UA-specific bugs where no other easy workaround was possible. I remember one particular bug in Firefox (which was only fixed years later) that I spent considerable effort trying to figure out how to work around without a UA string check, and eventually gave up. It was something like: if you append #foo to the URL while the page is loading in order to jump to span id=foo, but that element has not yet loaded when you set the URL, every other browser would jump to the element when it was added to the DOM, but Gecko would not. So I checked for Gecko and set the hash again onload. I didn't want to do this for non-Gecko browsers, because it would degrade the user experience (delaying the jump until the whole page loaded). And I couldn't figure out any reasonable way to detect it without UA sniffing. Sometimes browser behavior is just not reasonably detectable other than by UA sniffing. Yes, authors should use other methods if practical, and when I was a web dev I always would, but sometimes it's just not practical. Sometimes it's not even possible. This particular example did UA sniffing from JavaScript, not HTTP headers, but it illustrates why authors do need access to this information, and always will. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
Le 27/01/2015 22:31, Chris Peterson a écrit : On 1/27/15 9:29 AM, Jonas Sicking wrote: We keep telling websites to not use the UA string, however we've so far been very bad at asking them why they use the UA string and then create better alternatives for them. Essentially many websites need to do server-side feature detection in order to determine what version of the website to serve. However we expose *very* few client capabilities in the original HTTP request to a website. Essentially only supports HTML, which clearly isn't terribly useful. Are there recent studies of which features servers do detect and why? I could see arguments for sharing information about mobile devices, touch support, and OS. chris Mozilla.org uses UA sniffing to propose the right download process for Firefox to users wisiting our download pages, that seems like a legitimate use of UA sniffing to me :) Pascal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On Wed, Jan 28, 2015 at 11:51:40AM +0800, Philip Chee wrote: On 28/01/2015 01:29, Martin Thomson wrote: On Tue, Jan 27, 2015 at 2:51 AM, Daniel Stenberg dan...@haxx.se wrote: I personally think it would be wrong to do it in connection with HTTP/2 since it'll bring a bunch of unrelated breakage to be associated with the protocol bump. I'd rather we didn't for similar reasons. If we're interested in this, maybe run an experiment where Nightly offers a User-Agent of just Nightly. See how that goes. I don't expect much success unfortunately; UA detection is still in pretty wide use, and not always for the wrong reasons (you won't have to search back far on mozilla-google-discuss for an example). Pale Moon tried to do something similar. It was rather impressive how much of the web breaks when you do that. That change was backed out in haste. Simply not including Firefox can break things for Gecko-based browsers. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reversely iterating nsTArray
On Thu, Jan 29, 2015 at 2:59 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
On 2015-01-27 9:24 PM, Xidorn Quan wrote:
I asked a question in #developers that what is the best way to reversely
iterating nsTArray, and there are some suggestions:
tbsaunde uint32_t count = array.Length(); for (uint32_t i = length - 1;
i
length; i--)
smaug iterate from length() to 1 and index using i - 1
jcranmer for (uint32_t i = array.Length(); i-- 0; ) { }
tbsaunde's method should work fine, but not intuitive. smaug's looks fine
to me, but could cause some problem if I use i instead of i-1 by mistake.
jcranmer's... I don't think it is a good idea, anyway. None of them looks
prefect to me.
As we have supported range-based for loop in our code, I purpose that we
have something like ReverseIntegerRange, and use this with range-based
loop
to iterate the index. So we can use, for example: for (auto i :
ReverseIntegerRange(array.Length()))
Maybe we can also add IntegerRange to benefit from the integer type
dedution.
How does it sound?
No, please don't do this. We need to make our container classes more
similar to the STL containers, not less, and since this is about adding new
functionality, here is what we need to do:
* Add a begin() and end() function to nsTArray that return iterators with
STL semantics.
* Add a rbegin() and rend() function to nsTArray with similar semantics
which return a reverse iterator.
* Add something similar to boost::adaptors::reverse, probably to MFBT.
That's exactly what I want to do :)
And we still need a Range class for iterating integer.
- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
Aryeh Gregor wrote: I remember one particular bug in Firefox (which was only fixed years later) that I spent considerable effort trying to figure out how to work around without a UA string check, and eventually gave up. It was something like: if you append #foo to the URL while the page is loading in order to jump to span id=foo, but that element has not yet loaded when you set the URL, every other browser would jump to the element when it was added to the DOM, but Gecko would not. (I ended up fixing this because I fixed a very similar bug with the MSDN blogs, however that case was slightly different in that they linked directly to #foo but the element was created dynamically after the DOMContentLoaded event. My fix then caused a regression whose fix then incidentally fixed Aryeh's bug, almost exactly 5 years after he filed it.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On 28/01/2015 15:25, Gervase Markham wrote: On 27/01/15 09:16, Chris Peterson wrote: btw, here is the spartan User-Agent string for Microsoft's new Spartan browser: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36 Edge/12.0 Really? http://www.nczonline.net/blog/2013/07/02/internet-explorer-11-dont-call-me-ie/ suggests that it's: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv 11.0) like Gecko Gerv That's IE11, which is not the same as Spartan. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
On 27/01/15 09:16, Chris Peterson wrote: btw, here is the spartan User-Agent string for Microsoft's new Spartan browser: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36 Edge/12.0 Really? http://www.nczonline.net/blog/2013/07/02/internet-explorer-11-dont-call-me-ie/ suggests that it's: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv 11.0) like Gecko Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reversely iterating nsTArray
On 2015-01-27 9:24 PM, Xidorn Quan wrote:
I asked a question in #developers that what is the best way to reversely
iterating nsTArray, and there are some suggestions:
tbsaunde uint32_t count = array.Length(); for (uint32_t i = length - 1; i
length; i--)
smaug iterate from length() to 1 and index using i - 1
jcranmer for (uint32_t i = array.Length(); i-- 0; ) { }
tbsaunde's method should work fine, but not intuitive. smaug's looks fine
to me, but could cause some problem if I use i instead of i-1 by mistake.
jcranmer's... I don't think it is a good idea, anyway. None of them looks
prefect to me.
As we have supported range-based for loop in our code, I purpose that we
have something like ReverseIntegerRange, and use this with range-based loop
to iterate the index. So we can use, for example: for (auto i :
ReverseIntegerRange(array.Length()))
Maybe we can also add IntegerRange to benefit from the integer type
dedution.
How does it sound?
No, please don't do this. We need to make our container classes more
similar to the STL containers, not less, and since this is about adding
new functionality, here is what we need to do:
* Add a begin() and end() function to nsTArray that return iterators
with STL semantics.
* Add a rbegin() and rend() function to nsTArray with similar semantics
which return a reverse iterator.
* Add something similar to boost::adaptors::reverse, probably to MFBT.
That way you can write:
for (auto elem : array)
or:
for (auto elem : mozilla::Reverse(array))
And that would work no matter whether array is an nsTArray or a std::vector.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Visibility plan for document.registerElement (custom elements)
On Wednesday, January 28, 2015 at 12:04:25 PM UTC-8, James Burke wrote: Is there a place where I can follow the plan for enabling document.registerElement for wider web usage? Right now is is only available behind an about:config setting or if an app is a certified app. I am just interested in the machinery for document.registerElement/custom elements to be available, and do not need the full web components story (for example, do not need HTML Imports). Reason for asking: we want to try an experimental FxOS email app variant, but try delivering it through the marketplace. For that, it is best if the app is privileged instead of certified. We use some custom elements inside the app, so cannot currently go privileged. While it would be relatively straightforward for the app to move away from using document.registerElement, I would prefer to just leave it as-is if document.registerElement was going to be more widely available in the FxOS 3.0 timeframe (extra nice if it were to happen in the first half of this year). --- Originally posted on dev-b2g: https://groups.google.com/forum/#!topic/mozilla.dev.b2g/CqS5fQt9b-I but was informed off-list that dev-platform may be a better place to ask this question. James Hi James, Recently annevk has been working on reviewing the current specification for custom elements and we were getting the custom elements implementation to a state where we would be ready to turn it on once we were satisfied with the spec. Ideally this would have been near the end of the quarter as we were only anticipating relatively minor changes but it turns out that the current API doesn't fit that well with ES6 classes which are just around the corner and this may require additional work on both the spec and the implementation. As we currently stand, it's hard to give an estimate for when registerElement will be widely turned on. Planning will be easier once the spec settles down and we know what we need to implement (annevk would probably be able to provide a better estimate for this piece than I could). To follow the recent spec issues currently in discussion, we have this wiki page: https://wiki.whatwg.org/wiki/CustomElements Once we know what we need to implement, we will have a bug to track progress on implementation and enabling the feature. - William ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTTP/2 and User-Agent strings?
btw, Le 28 janv. 2015 à 07:16, Karl Dubost kdub...@mozilla.com a écrit : We did ask. The range of reasons spreads on a very large spectrum. Technical, Commercial, Laziness, Economic constraints, etc. During the survey last year, we got answers from business people, Web developers, companies providing UA dbs, etc. The answers are summarized in this article: http://www.otsukare.info/2014/03/31/ua-detection-use-cases slightly related to this, Chris and others you might be interested. We are having in Mozilla Mountain View office a Web Compatibility Summit with participation of Google, Microsoft and others. https://wiki.mozilla.org/WebCompat_Summit_%282015%29 -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
HEADS-UP: Disabling Gecko Media Plugins on older Linux kernels (bug 1120045)
Short version: On desktop Linux systems too old to support seccomp-bpf system call filtering[1], Gecko Media Plugins will be disabled; in practice, this means OpenH264, which is used for H.264 video compression in WebRTC. This will be controlled with a pref, media.gmp.insecure.allow. [1] Examples of sufficiently new distribution versions: Ubuntu 12.04, Fedora 18, RHEL/Centos 7, Debian 8.0. More background: Currently it's difficult to evaluate the security implications of bugs in OpenH264 with respect to Firefox, because approximately 99.9% of Firefox instances run it in some kind of OS-level sandboxing, but the remaining ~0.1% are fully exposed. Disabling OpenH264 would break WebRTC interoperability with endpoints that support only H.264 and not VP8, but if those exist then they're currently also incompatible with Google Chrome. Also, mobile devices with hardware H.264 acceleration might prefer it and use more CPU/power to fall back to VP8. Given the specifics of this security/usability tradeoff, we're changing the default to security. Note that Fedora and Debian already disable OpenH264 by default in their Firefox/Iceweasel (respectively) builds due to their license policies. Even more background: Firefox on Windows and OS X can sandbox media plugins unconditionally, but on Linux the situation is more complicated. We're using the seccomp-bpf system call filter (CONFIG_SECCOMP_FILTER), which is available for ~96% of desktop Linux Firefox, with a restrictive policy. In principle the classic Chromium sandbox would be more compatible, but it requires a setuid root executable, whereas seccomp-bpf needs no special privileges (nor changes to release/test/install infrastructure). --Jed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HEADS-UP: Disabling Gecko Media Plugins on older Linux kernels (bug 1120045)
One clarification. Sites that use WebRTC but only do H264 do exist - http://web.projectsquared.com/ is one of them. When you try to initiate a video call using Chrome it has a popup that says Firefox Rocks for Video Calls! and gives a Download Firefox button. It has mostly non-browser endpoints and none of them support VP8. That said, I would have to guess that the percentage of users of projectsquared affected by this is near zero. -EH On Wed, Jan 28, 2015 at 10:07 AM, Jed Davis j...@mozilla.com wrote: Short version: On desktop Linux systems too old to support seccomp-bpf system call filtering[1], Gecko Media Plugins will be disabled; in practice, this means OpenH264, which is used for H.264 video compression in WebRTC. This will be controlled with a pref, media.gmp.insecure.allow. [1] Examples of sufficiently new distribution versions: Ubuntu 12.04, Fedora 18, RHEL/Centos 7, Debian 8.0. More background: Currently it's difficult to evaluate the security implications of bugs in OpenH264 with respect to Firefox, because approximately 99.9% of Firefox instances run it in some kind of OS-level sandboxing, but the remaining ~0.1% are fully exposed. Disabling OpenH264 would break WebRTC interoperability with endpoints that support only H.264 and not VP8, but if those exist then they're currently also incompatible with Google Chrome. Also, mobile devices with hardware H.264 acceleration might prefer it and use more CPU/power to fall back to VP8. Given the specifics of this security/usability tradeoff, we're changing the default to security. Note that Fedora and Debian already disable OpenH264 by default in their Firefox/Iceweasel (respectively) builds due to their license policies. Even more background: Firefox on Windows and OS X can sandbox media plugins unconditionally, but on Linux the situation is more complicated. We're using the seccomp-bpf system call filter (CONFIG_SECCOMP_FILTER), which is available for ~96% of desktop Linux Firefox, with a restrictive policy. In principle the classic Chromium sandbox would be more compatible, but it requires a setuid root executable, whereas seccomp-bpf needs no special privileges (nor changes to release/test/install infrastructure). --Jed ___ 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
Visibility plan for document.registerElement (custom elements)
Is there a place where I can follow the plan for enabling document.registerElement for wider web usage? Right now is is only available behind an about:config setting or if an app is a certified app. I am just interested in the machinery for document.registerElement/custom elements to be available, and do not need the full web components story (for example, do not need HTML Imports). Reason for asking: we want to try an experimental FxOS email app variant, but try delivering it through the marketplace. For that, it is best if the app is privileged instead of certified. We use some custom elements inside the app, so cannot currently go privileged. While it would be relatively straightforward for the app to move away from using document.registerElement, I would prefer to just leave it as-is if document.registerElement was going to be more widely available in the FxOS 3.0 timeframe (extra nice if it were to happen in the first half of this year). --- Originally posted on dev-b2g: https://groups.google.com/forum/#!topic/mozilla.dev.b2g/CqS5fQt9b-I but was informed off-list that dev-platform may be a better place to ask this question. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
