Re: Web Speech API Installation Build Flags
On Wednesday, May 6, 2015 at 10:29:29 PM UTC+2, Nicholas Alexander wrote: On Tue, May 5, 2015 at 10:36 PM, kdavis wrote: We would like some feedback on build flags for the Web Speech API installation. More specifically, we are planning to land an initial version of the Web Speech API[1] into Geko. However, due to a number of factors, model size being one of them, we plan to introduce various build flags which install/do not install parts of the Web Speech API for various build targets. Our current plan for B2G is as follows: 1. Introduce a flag to control installation of the Web Speech API 2. Introduce a flag to control installation of Pocketsphinx[2], the STT/TTS engine. 3. Introduce a script to allow installation of models, allowing developers to test the Web Speech API (They can test once they've made a build with the previous two flags on) Our question is related to desktop and Fennec. Our current plan is to: 1. Introduce a flag to control installation of the Web Speech API + Pocketsphinx + English model[3] For Fennec, that's about right -- a build flag should control building and shipping all (or parts) of this, and a Gecko pref controls enabling the feature (exposing it to web content). There are numerous examples, and see [1] and [2] for Fennec specific notes. Fennec is extremely concerned about its APK size and is very unlikely to ship the large model files that the Web Speech API relied on many moons ago when I looked at it. I encourage you to f? me and mfinkle on Fennec build patches, and to pursue Fennec-specific discussion on mobile-firefox-dev. Nick [1] http://www.ncalexander.net/blog/2014/07/09/how-to-land-a-fennec-feature-behind-a-build-flag/ [2] http://www.ncalexander.net/blog/2015/02/13/how-to-update-and-test-fennec-feature-build-flags/ The question is: Is this a good plan for desktop and Fennec? Should there be more/less fine grade control for installation there? [1] https://dvcs.w3.org/hg/speech-api/raw-file/tip/webspeechapi.html [2] http://cmusphinx.sourceforge.net/ [3] Initially we will work only with English and introduce a mechanism to install other models later. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform Nick Thanks for the detailed feedback! I'll start a separate Fennec specific discussion on mobile-firefox-dev. As far as Fennec is concerned, we can make the installation not include the a model, but have the Fennec plan mirror the B2G plan and have model(s) downloadable/installable by interested devs. This can be a solution for nightly, until a final solution for model installation is decided upon. Best ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Thu, May 7, 2015 at 12:43 AM, Adam Roach aro...@mozilla.com wrote: Which leaves us with a conundrum regarding your plea for more notice: it's a bit hard to seriously consider complaints that at some future date yet to be determined is too soon. My apologies. My reading of the announcements indicated that this was happening in Firefox 40, which is very soon. It was not at all clear that there was some kind of step by step process (indeed, this message was the first time I picked up on that, despite reading this thread fairly closely -- perhaps communications being clearer would have helped). I suspect a lot of this kerfuffle could have been dodged had the original posting been a little more thorough and more cautiously worded. Trying to tease these nuances out of a long and emotional thread has been difficult, unfortunately. It was not clear until quite a few messages into the thread that this wasn't all happening at once, and wasn't automatically being applied to all servers. It sounded very much as if all unencrypted HTTP was going to be rejected starting in Firefox 40. Now that I know that's not the case, I'm much less concerned, although not 100% living in happy unicorns and rainbows land. -- Eric Shepherd Senior Technical Writer Mozilla Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
On 2015-05-07 7:07 AM, David Rajchenbach-Teller wrote: From what I gather, ServiceWorkers are now The Right Thing To Do if a webpage needs some off main thread pre/post processing on server-sent data. This got me thinking that pre/post processing is exactly what AdBlock Plus is doing. So, I wonder: could AdBlock Plus be reimplemented using a slightly beefed up browser-wide ServiceWorker? Could add-on authors similarly implement, say, image-blocking for slow-connections using a similar mechanism? What about anti-viruses, which could possibly perform scans on e.g. swf before it is executed, using js-ctypes and ServiceWorkers? These types of add-ons are usually implemented by registering a content policy implementation which is a service that we call into from the main thread to determine whether or not to load content. Service workers however are full fledged workers that are currently installed for a URL scope under one origin, and they intercept the network fetch and have a lot of power over what to do with it. They can just log the request, and let it go to the network, synthesize an error response, send back a cached response, or generate a dynamic response that may be fully generated. IOW, they can do a *lot* more than a content policy implementation. There are two problems which make what you're suggesting not a great idea: 1. Because service workers run on their own thread, they add some latency for determining what to do for each network request. Therefore running them for all network requests across the entire browser is probably impractical. 2. As they are currently implemented, they can only intercept the requests that are coming from a specific scope under a specific origin. Currently it's not possible to register a global service worker for intercepting all network requests no matter where they are coming from. Also, they cannot see the insides of a response for a cross-origin request (which will essentially be all requests for a service worker similar to what you have in mind) which makes them unsuitable for things such as anti-virus scanners. I think that service workers are probably too big of a hammer for supporting use cases such as adblock, image blocking, etc. They are probably the right level of abstraction for something like a swf virus scanner but they're restricted in what they can do with those as I mentioned above. And I suspect that as a mechanism for intercepting all network requests, they will be too slow. It's probably much better to come up with specific APIs for these use cases where are current solutions are insufficient. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
AdBlock Plus as a ServiceWorker?
From what I gather, ServiceWorkers are now The Right Thing To Do if a webpage needs some off main thread pre/post processing on server-sent data. This got me thinking that pre/post processing is exactly what AdBlock Plus is doing. So, I wonder: could AdBlock Plus be reimplemented using a slightly beefed up browser-wide ServiceWorker? Could add-on authors similarly implement, say, image-blocking for slow-connections using a similar mechanism? What about anti-viruses, which could possibly perform scans on e.g. swf before it is executed, using js-ctypes and ServiceWorkers? Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: No more binary components in extensions
On 06/05/2015 23:47, Doug Turner wrote: One thing I should point out is that binary components in B2G are NOT user installable. Instead, binaries components are used by companies building FirefoxOS devices. For example, Qualcomm has some special implementation for Geolocation and the radio interface layer (RIL). When a company wants to build a FirefoxOS device on Qualcomm hardware, Qualcomm hands them a bunch of binaries. These binaries obviously aren’t compiled into LIBXUL and thus we need XPCOM to continue looking for and loading binary components. Sony is unlocking their bootloaders to allow users to install other phone operating systems, including FirefoxOS. If the hardware is Qualcomm, I expect the users will want to install the binary blobs as well. Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On 2015-05-07 5:53 PM, Karl Tomlinson wrote: Ehsan Akhgari writes: This seems similar to the compiler warning situation. Usually at least, I don't think we should automatically modify the code in line with how the compiler reads the code just to silence the warning. Instead the warning is there to indicate that a programmer needs to check the code. These cases bear no similarity whatsoever. I can't think of any compiler warnings that can be automatically fixed without changing the meaning of the program. The warning that you are proposing to fix here is -Woverloaded-virtual. No. My proposal is completely unrelated to function overloading. Perhaps you're thinking of clang's -Winconsistent-missing-override? This proposal obviously fixes that warning (as a mere side effect), but that warning wouldn't catch everything that this proposal covers. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
Ehsan Akhgari writes: On 2015-05-07 5:53 PM, Karl Tomlinson wrote: Ehsan Akhgari writes: This seems similar to the compiler warning situation. Usually at least, I don't think we should automatically modify the code in line with how the compiler reads the code just to silence the warning. Instead the warning is there to indicate that a programmer needs to check the code. These cases bear no similarity whatsoever. I can't think of any compiler warnings that can be automatically fixed without changing the meaning of the program. The warning that you are proposing to fix here is -Woverloaded-virtual. No. My proposal is completely unrelated to function overloading. Perhaps you're thinking of clang's -Winconsistent-missing-override? This proposal obviously fixes that warning (as a mere side effect), but that warning wouldn't catch everything that this proposal covers. Ah, yes. Sorry to confusing things. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On 2015-04-29 9:16 PM, Karl Tomlinson wrote: and this one isn't final, but we could make it final if the tu will be built into libxul (because then devirtualization is fine) http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIDocument.h#1287 I'm not sure why that function is virtual. If it's just in order to make it possible to call it through a vtable from outside of libxul, I'm not sure why we need to treat it differently than other XPCOM APIs for example. If this is not used outside of libxul, we can probably make it non-virtual. XPCOM APIs are usually abstract interfaces and so not final. final could be removed and have valid code, but may be a useful optimization or enforcement of intent. virtual final seems necessary for some use cases, and there is no redundancy. Is there a need to ban this usage? The point is that there are *very few* use cases. Right now it seems that there is only one place in mozilla-central where we use a non-overriding virtual function that is also final, and that is a function that is never called by anybody. In almost every other case, such a method would just be devirtualized. The case ththat Trevor mentioned above (using a non-virtual function for internal code but allowing external code to access it too) is easily served by a virtual non-final function that wraps a non-virtual one that the internal code uses. The point of having a coding style is to have it prescribe what is desirable in 99% of the cases, not prescribe something that works for every single edge case that most people should never have to use. :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On 2015-05-05 2:51 PM, Jeff Walden wrote: Seeing this a touch late, commenting on things not noted yet. On 04/27/2015 12:48 PM, Ehsan Akhgari wrote: I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Here are the advantages: * It is a more succinct, as |virtual void foo() override;| doesn't convey more information than |void foo() override;|. * It makes it easier to determine what kind of function you are looking at by just looking at its declaration. |virtual void foo();| means a virtual function that is not overridden, |void foo() override;| means an overridden virtual function, and |void foo() final;| means an overridden virtual function that cannot be further overridden. All else equal, shorter is better. But this concision hurts readability, even past the non-obvious final/override = virtual implication others have noted. (And yes, C++ can/should permit final/override on non-virtuals. JSString and subclasses would be immediate users.) At the risk of repeating myself and others here, let's not worry about what C++ should do if it were being redesigned today, and let's focus on what it actually does. Requiring removal of virtual from the signature for final/override prevents simply examining a declaration's start to determine whether the function is virtual. You must read the entire declaration to know: a problem because final/override can blend in. For longer (especially multiline) declarations this matters. Consider these SpiderMonkey declarations: /* Standard internal methods. */ virtual bool getOwnPropertyDescriptor(JSContext* cx, HandleObject proxy, HandleId id, MutableHandleJSPropertyDescriptor desc) const override; virtual bool defineProperty(JSContext* cx, HandleObject proxy, HandleId id, HandleJSPropertyDescriptor desc, ObjectOpResult result) const override; virtual bool ownPropertyKeys(JSContext* cx, HandleObject proxy, AutoIdVector props) const override; virtual bool delete_(JSContext* cx, HandleObject proxy, HandleId id, ObjectOpResult result) const override; virtual is extraordinarily clear in starting each declaration. override and final alone would be obscured at the end of a long string of text, especially when skimming. (I disagree with assuming syntax coloring penalizing non-IDE users.) This is basically what Trevor was arguing for. I don't think there is much more to say on this as we're basically comparing what you and I are used to read. * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead. A better alternative, that exposes standard C++ and macro-hides non-standard gunk, would be to use NS_IMETHOD for everything and directly use |virtual| in declarations. This point is no justification for changing style rules. That has similar verbosity issues. But yeah I agree on the broader point that this macro situation can be solved in other ways, we just disagree what those ways should be. :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On 2015-04-29 9:17 PM, Karl Tomlinson wrote: Ehsan Akhgari writes: I think there's a typo of some sort in the question, but if you meant every overriding function must be marked with override, then yes, that is the change I'm proposing, but the good news is that you can now run clang-tidy on the entire tree and get it to rewrite the source code to make sure that the override keywords are present where they are needed, and we can do that as often as we would like. IOW, this can be done without requiring every C++ programmer to remember to do it always. I fear that an automatic update would be more than just enforcing a style because override keywords imply programmer intent. If the proposal is to periodically automatically add override keywords where methods override but are currently not annotated as such Yes, I would like us to get to that point (but running the tool needs to be done manually for now.) then it seems we should we have an annotation to indicate that a method is not intended to override. However, that would require annotating all methods. I don't understand what you're suggesting. Adding override to an overriding virtual function doesn't change what the program means. There is no need to annotate all methods. (Please note that my proposal works very well in other large well established code bases. I'm not exactly making up a new rule!) This seems similar to the compiler warning situation. Usually at least, I don't think we should automatically modify the code in line with how the compiler reads the code just to silence the warning. Instead the warning is there to indicate that a programmer needs to check the code. These cases bear no similarity whatsoever. I can't think of any compiler warnings that can be automatically fixed without changing the meaning of the program. Perhaps though there is a case for a one-off change to add override automatically so that warnings can be enabled on new code. Again, I'm not sure what you're mentioning exactly, but my proposal entails periodic automatic rewrites of the code without changing what the code means. And hopefully people will start to gradually obey the new coding style. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On Fri, May 08, 2015 at 09:53:54AM +1200, Karl Tomlinson wrote: Ehsan Akhgari writes: This seems similar to the compiler warning situation. Usually at least, I don't think we should automatically modify the code in line with how the compiler reads the code just to silence the warning. Instead the warning is there to indicate that a programmer needs to check the code. These cases bear no similarity whatsoever. I can't think of any compiler warnings that can be automatically fixed without changing the meaning of the program. The warning that you are proposing to fix here is -Woverloaded-virtual. At least once we can build with this warning enabled, I recommend making this warning fatal instead of covering over it by adding an override annotation that the author may have never intended. It *is* enabled and fatal, but there are a few places that disable it. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
Ehsan Akhgari writes: This seems similar to the compiler warning situation. Usually at least, I don't think we should automatically modify the code in line with how the compiler reads the code just to silence the warning. Instead the warning is there to indicate that a programmer needs to check the code. These cases bear no similarity whatsoever. I can't think of any compiler warnings that can be automatically fixed without changing the meaning of the program. The warning that you are proposing to fix here is -Woverloaded-virtual. At least once we can build with this warning enabled, I recommend making this warning fatal instead of covering over it by adding an override annotation that the author may have never intended. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
A request from the docs team: once the final decisions are made, please either let us know what those decisions are (use our doc request form: https://bugzilla.mozilla.org/form.doc) or update the coding style guide yourselves ( https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style). Either one wins you brownie points, but updating the doc yourselves will result in super-tasty brownie points. On Thu, May 7, 2015 at 9:52 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-05-05 2:51 PM, Jeff Walden wrote: Seeing this a touch late, commenting on things not noted yet. On 04/27/2015 12:48 PM, Ehsan Akhgari wrote: I think we should change it to require the usage of exactly one of these keywords per *overridden* function: virtual, override, and final. Here are the advantages: * It is a more succinct, as |virtual void foo() override;| doesn't convey more information than |void foo() override;|. * It makes it easier to determine what kind of function you are looking at by just looking at its declaration. |virtual void foo();| means a virtual function that is not overridden, |void foo() override;| means an overridden virtual function, and |void foo() final;| means an overridden virtual function that cannot be further overridden. All else equal, shorter is better. But this concision hurts readability, even past the non-obvious final/override = virtual implication others have noted. (And yes, C++ can/should permit final/override on non-virtuals. JSString and subclasses would be immediate users.) At the risk of repeating myself and others here, let's not worry about what C++ should do if it were being redesigned today, and let's focus on what it actually does. Requiring removal of virtual from the signature for final/override prevents simply examining a declaration's start to determine whether the function is virtual. You must read the entire declaration to know: a problem because final/override can blend in. For longer (especially multiline) declarations this matters. Consider these SpiderMonkey declarations: /* Standard internal methods. */ virtual bool getOwnPropertyDescriptor(JSContext* cx, HandleObject proxy, HandleId id, MutableHandleJSPropertyDescriptor desc) const override; virtual bool defineProperty(JSContext* cx, HandleObject proxy, HandleId id, HandleJSPropertyDescriptor desc, ObjectOpResult result) const override; virtual bool ownPropertyKeys(JSContext* cx, HandleObject proxy, AutoIdVector props) const override; virtual bool delete_(JSContext* cx, HandleObject proxy, HandleId id, ObjectOpResult result) const override; virtual is extraordinarily clear in starting each declaration. override and final alone would be obscured at the end of a long string of text, especially when skimming. (I disagree with assuming syntax coloring penalizing non-IDE users.) This is basically what Trevor was arguing for. I don't think there is much more to say on this as we're basically comparing what you and I are used to read. * It will allow us to remove NS_IMETHODIMP, and use NS_IMETHOD instead. A better alternative, that exposes standard C++ and macro-hides non-standard gunk, would be to use NS_IMETHOD for everything and directly use |virtual| in declarations. This point is no justification for changing style rules. That has similar verbosity issues. But yeah I agree on the broader point that this macro situation can be solved in other ways, we just disagree what those ways should be. :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Eric Shepherd Senior Technical Writer Mozilla Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On May 6, 2015, at 22:51, Eric Shepherd esheph...@mozilla.com wrote: would have been nice to have more notice The plan that has been outlined involves a staged approach, with new JavaScript features being withheld after some date, followed by a period during which select older JavaScript features are gradually removed. I'll note that actually turning off http isn't part of the outline. Most importantly, all of these steps are to be taken at dates that are still under discussion. You can be part of that discussion. Which leaves us with a conundrum regarding your plea for more notice: it's a bit hard to seriously consider complaints that at some future date yet to be determined is too soon. /a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On 05/01/2015 01:50 PM, oli...@omattos.com wrote: When plans like this aren't rolled out across all browsers together, users inevitably come across a broken site and say Firefox works with this site, but Safari gives a warning. Safari must be broken. Better security is punished. Having this determined by a browser release is also bad. My up to date Firefox is broken, but my old Safari works. Updating breaks things and must be bad!. Secure practices are punished. All browsers could change their behaviour on a specific date and time. But that would lead to stampedes of webmasters having issues all at once. And if theres any unforeseen compatibility issue, you just broke the entire world. Not so great. So might I suggest the best rollout plan is to apply policies based on a hash of the origin and a timestamp. Ie. on a specific date, 1% of sites have the new policies enforced, while 99% do not. Then a month later, it's up to 51%, and another month later it's up to 100%. The proposal I understood from this thread involves breaking precisely 0% of existing sites. So the flag day would only be relevant to in-development sites using new features only available in development browser builds. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
