Re: Documenting uses of Github at Mozilla
On 9/30/2014 11:44 PM, Eric Shepherd wrote: Last week the idea came up that it would be helpful to create a list on MDN of the Mozilla projects that are on GitHub, with links to those sites. I have two questions: 1. Do we already have such a list anywhere? 2. If you have a project (or projects) on Github, please let me know! I'd like to make sure people know where it is if they're looking for it. Please define Mozilla projects. I have my Thunderbird extension mirrored on GitHub and I know there are a couple more projects hosted there. If you want to include those in your list, it is probably best to also post in mozilla.dev.extensions... Also I'd like to know why you seem to limit this to GitHub. I think there are Mozilla projects hosted on other repository sites, like Mozdev, Google Code, SourceForge or BitBucket. Onno ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Logging start page loading
Hi, Thank you! Yes, I do care about iFrames, and I'll check out nsDocShell::LoadURI. As for the logging, currently i'm using my own, simple infrastructure, but I was just curious if there is something already used by the Firefox source, e.g. I see a bunch of LOG(...) statements scattered around, so I might start with there. Thank you. On Wednesday, October 1, 2014 5:25:18 PM UTC+2, Josh Matthews wrote: On 2014-10-01 9:47 AM, Josip Maras wrote: Hi, How can I log to a file the URL of every page that has started loading? What is the best code location to do this. (I understand that this can be easily done with a Firefox plugin, but I would like to work directly in the Firefox source code). I was thinking of going with the nsURILoader class, but is there a better option? Also, what is a good built-in option for logging to a custom file, especially if this logging will be done fairly frequently. Thank you, Josip When you say page, what do you mean, exactly? Do you care about iframes? You might be interested in nsDocShell::LoadURI. With respect to logging, I don't know what you mean by built-in option; if this is just for yourself, I would recommend using fopen and fprintf, otherwise you can use the nsIFile interface. Look for uses of InitWithPath for decent examples. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Array.prototype.contains is going away again
On 02/10/2014 00:52, Till Schneidereit wrote: Unfortunately, it turns out that Array.prototype.contains breaks the web. Or, the MooTools-using parts of the web, at least. So I'm preparing a backout right now. Can we not reach out to the MooTools people and work together unbreak the web? What's more pressingly unfortunate is that Array.prototype.contains enjoys a surprisingly spectacular popularity: it's already used in quite a number of places in the tree, which I'll have to back out, too. DoublePlusUngood. 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: PSA: Array.prototype.contains is going away again
On 02/10/14 09:06, Philip Chee wrote: On 02/10/2014 00:52, Till Schneidereit wrote: Unfortunately, it turns out that Array.prototype.contains breaks the web. Or, the MooTools-using parts of the web, at least. So I'm preparing a backout right now. Can we not reach out to the MooTools people and work together unbreak the web? Unfortunately js libraries aren't like web browsers; you can't just ship a new version and upgrade all existing users in a matter of weeks. Instead usage of the broken versions may continue for years, depending on the popularity of the library, how long it had been broken for, and so on. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
u me
No I can't wait for it to happen ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
u me
___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Array.prototype.contains is going away again
Is there even a solution to that problem? Could, say, `Array.prototype.contains` be instantiated lazily when called and only if no `Array.prototype.contains` has been defined by web code? On 02/10/14 10:49, James Graham wrote: Unfortunately js libraries aren't like web browsers; you can't just ship a new version and upgrade all existing users in a matter of weeks. Instead usage of the broken versions may continue for years, depending on the popularity of the library, how long it had been broken for, and so on. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 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
Intent to implement: WOFF2 webfont format
The W3C WebFonts Working Group[1] has been working on designing and specifying a new compressed font format for the web, aiming to give significantly smaller file sizes than the existing WOFF format (to reduce bandwidth requirements), while remaining cheap to decode (for low-power devices). The format is primarily based on earlier TrueType compression work (MicroType Express) by Monotype, and a new entropy coder (Brotli) developed by Google's data compression team in Zurich. For more information about the WOFF2 format, see the FPWD spec[2] and current Editors' Draft.[3] WOFF2 is currently supported by Chrome and Opera,[4] and the Google webfonts service is serving WOFF2-compressed fonts to browser versions that are known to support it.[5] I'm proposing to add WOFF2 support to Gecko, based on the reference implementation code from the Google font and compression teams, found at [6]. Support for WOFF2 will be controlled by a new boolean pref gfx.downloadable_fonts.woff2.enabled. Initially this defaults to false for release builds, and true for nightlies; when we're ready to ship the feature on-by-default, we can simply flip the pref to true for all channels. This work is happening in bugs [7] and [8], which I hope to land real soon now (in time for Gecko 35, if all goes well). - JK [1] http://www.w3.org/Fonts/WG/ [2] http://www.w3.org/TR/WOFF2/ [3] http://dev.w3.org/webfonts/WOFF2/spec/ [4] http://caniuse.com/#feat=woff2 [5] https://code.google.com/p/font-compression-reference/wiki/testing_woff2 [6] https://code.google.com/p/font-compression-reference/ [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1066160 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1064737 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Array.prototype.contains is going away again
On 02/10/2014 17:30, David Rajchenbach-Teller wrote: On 02/10/14 10:49, James Graham wrote: Unfortunately js libraries aren't like web browsers; you can't just ship a new version and upgrade all existing users in a matter of weeks. Instead usage of the broken versions may continue for years, depending on the popularity of the library, how long it had been broken for, and so on. Is there even a solution to that problem? Could, say, `Array.prototype.contains` be instantiated lazily when called and only if no `Array.prototype.contains` has been defined by web code? I would have expected that their polyfill would be smart enough to notice a ES7 compliant A.p.contains() and defer to it. 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: PSA: Array.prototype.contains is going away again
On Thu, Oct 2, 2014 at 2:24 PM, Philip Chee philip.c...@gmail.com wrote: On 02/10/2014 17:30, David Rajchenbach-Teller wrote: On 02/10/14 10:49, James Graham wrote: Unfortunately js libraries aren't like web browsers; you can't just ship a new version and upgrade all existing users in a matter of weeks. Instead usage of the broken versions may continue for years, depending on the popularity of the library, how long it had been broken for, and so on. Is there even a solution to that problem? Could, say, `Array.prototype.contains` be instantiated lazily when called and only if no `Array.prototype.contains` has been defined by web code? See this es-discuss thread for proposed solutions: http://esdiscuss.org/topic/array-prototype-contains-solutions bz pointed out that some web API additions are specified using the second of Domenic's proposals. I would have expected that their polyfill would be smart enough to notice a ES7 compliant A.p.contains() and defer to it. That's a very optimistisc expectation, unfortunately. It also doesn't fully work: code that expects the MooTools Array.prototype.contains, which is slightly different from the proposed standardized one, might simply not work with the latter. This case isn't really about whether the MooTools Array.prototype.contains is spec-compliant: the specific issue is that MooTools installs its Array.prototype extensions simply by setting them as value properties: Array.prototype.contains = function ... (or at least using code to that effect, bz lays it all out in bug 1075059[1]) Now, the ES7 version would be non-enumerable. Because of some fairly amazing details of how MooTools initialization works, that causes Array.prototype.contains to not get copied over to a collection class called Elements. Again, see [1] for details. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1075059 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Array.prototype.contains is going away again
On Wed, Oct 1, 2014 at 7:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-01, 1:20 PM, Till Schneidereit wrote: That's a great point. It would be great if we can adopt https://wiki.mozilla.org/WebAPI/ExposureGuidelines for new JS fatures as well. Yes, I think we should consider that. The situation is somewhat different in that we usually only implement features that are stable, specced, and agreed upon by tc39 and thus have buy-in by other vendors. (Usually because we do some experimental Nightly-only stuff, but that is so exotic, really, that FF devs wouldn't begin to think that it's production-usable.) Sure, but I think it would still be valuable, even if it's only used as an announcement mechanism. I agree, and will bring it up with other SpiderMonkey devs. Also, out of curiosity, do we have ways of hiding JS built-ins behind prefs similar to DOM APIs? Not really: by the time the prefs are read, we have already created globals, so those either have the builtins (if we default to installing them) or won't ever get them, regardless of the pref's value (if we default to not installing them). Hmm.. I'm not sure about the details of the code in question. Is this easy to solve? At what point exactly during startup do we create those built-ins? The full answer to that is actually ridiculously complicated. The part relevant here is, though: very early on in at least some cases. Too early to rely on preferences, if I'm not mistaken. I think the only reliable way would be to do it when creating the runtime. Also, I think there is great value in having these features available without a pref. Chrome uses prefs, and I think is substantially diminishes the value for testing things out. Array.prototype.contains is a good example for that: if it had been behind a pref, who knows when we'd have discovered the web breakage? I was not suggesting that we should have landed Array.prototype.contains behind a pref. However, there are other uses for being able to hide things behind a pref. One great example is this pattern: #ifdef NIGHTLY_BUILD pref(what.ever, true); #else pref(what.ever, false); #endif This basically ensures that we don't accidentally end up letting the feature slip past Nightly before we're ready (part of the definition of ready might be, knowing that the feature is Web compatible, etc.) Inside SpiderMonkey, we ensure that by doing the Nightly check where the feature is compiled/installed in the first place. For Array.prototype.contains, that is here: http://mxr.mozilla.org/mozilla-central/source/js/src/jsarray.cpp?rev=020a62efb303#3027 Now that obviously doesn't allow you to manually enable these features on Aurora and above. Assuming that you'd want to be able to do that in a fine-grained way, the prefs thing would be even more complicated: we'd have to add a way for the JS engine to query prefs, because just passing in all of them from the outside becomes untenable. One thing that would be possible, I suppose, is to have a single flag enable experimental extensions, as Chrome does. We should at least consider doing that, without changing our current behavior of having these features enabled by default on Nightly. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Logging start page loading
That's provided by the NSPR library we use; see https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR/Reference/Logging for an in-depth explanation, or http://bertrandbenoit.blogspot.ca/2011/09/activate-logging-for-mozilla.html for a quick explanation of how to view the output. Cheers, Josh On 2014-10-02 4:06 AM, Josip Maras wrote: Hi, Thank you! Yes, I do care about iFrames, and I'll check out nsDocShell::LoadURI. As for the logging, currently i'm using my own, simple infrastructure, but I was just curious if there is something already used by the Firefox source, e.g. I see a bunch of LOG(...) statements scattered around, so I might start with there. Thank you. On Wednesday, October 1, 2014 5:25:18 PM UTC+2, Josh Matthews wrote: On 2014-10-01 9:47 AM, Josip Maras wrote: Hi, How can I log to a file the URL of every page that has started loading? What is the best code location to do this. (I understand that this can be easily done with a Firefox plugin, but I would like to work directly in the Firefox source code). I was thinking of going with the nsURILoader class, but is there a better option? Also, what is a good built-in option for logging to a custom file, especially if this logging will be done fairly frequently. Thank you, Josip When you say page, what do you mean, exactly? Do you care about iframes? You might be interested in nsDocShell::LoadURI. With respect to logging, I don't know what you mean by built-in option; if this is just for yourself, I would recommend using fopen and fprintf, otherwise you can use the nsIFile interface. Look for uses of InitWithPath for decent examples. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: FYI: developer services components moving in Bugzilla Oct 1
All changes have been applied, as of a few moments ago. - Mensaje original - De: Hal Wine hw...@mozilla.com Para: release rele...@mozilla.com, Sheriffs sheri...@mozilla.org, Ben Kero bk...@mozilla.com, Gregory Szorc gsz...@mozilla.com CC: Kendall Libby kli...@mozilla.com, Mark Côté mc...@mozilla.com, dev-platform@lists.mozilla.org, Dylan Hardison dhardi...@mozilla.com Enviados: Miércoles, 1 de Octubre 2014 0:05:35 Asunto: FYI: developer services components moving in Bugzilla Oct 1 These changes (below) will be made on Oct 1 around 2100 PT The complete set of changes are listed at: https://bugzilla.mozilla.org/show_bug.cgi?id=1071332#user_story_header ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Array.prototype.contains is going away again
On 2014-10-02, 9:58 AM, Till Schneidereit wrote: On Wed, Oct 1, 2014 at 7:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: On 2014-10-01, 1:20 PM, Till Schneidereit wrote: That's a great point. It would be great if we can adopt https://wiki.mozilla.org/__WebAPI/ExposureGuidelines https://wiki.mozilla.org/WebAPI/ExposureGuidelines for new JS fatures as well. Yes, I think we should consider that. The situation is somewhat different in that we usually only implement features that are stable, specced, and agreed upon by tc39 and thus have buy-in by other vendors. (Usually because we do some experimental Nightly-only stuff, but that is so exotic, really, that FF devs wouldn't begin to think that it's production-usable.) Sure, but I think it would still be valuable, even if it's only used as an announcement mechanism. I agree, and will bring it up with other SpiderMonkey devs. Thank you! Also, out of curiosity, do we have ways of hiding JS built-ins behind prefs similar to DOM APIs? Not really: by the time the prefs are read, we have already created globals, so those either have the builtins (if we default to installing them) or won't ever get them, regardless of the pref's value (if we default to not installing them). Hmm.. I'm not sure about the details of the code in question. Is this easy to solve? At what point exactly during startup do we create those built-ins? The full answer to that is actually ridiculously complicated. The part relevant here is, though: very early on in at least some cases. Too early to rely on preferences, if I'm not mistaken. I think the only reliable way would be to do it when creating the runtime. So, I took a quick look, and we create the first JSRuntime during the initialization of XPConnect, which is *way* after the XPCOM stuff required for the preferences service is initialized (I did verify that the preferences service is initialized before we create the runtime.) Now, of course, there is no XPCOM (and no preferences service) in the js shell, but it seems like if we wanted to support preferences for this purpose for browser builds, the XPCOM side of things is not going to be an issue. (Of course, I have no idea whether you'd be OK with just calling the Preferences API inside the js code or if we need to invent some kind of a way to mask that away, and just pass the necessary info into the JS engine from the browser, and I have no idea how much work that would be, but I think at least the first option is readily available if we decide to do that.) Also, I think there is great value in having these features available without a pref. Chrome uses prefs, and I think is substantially diminishes the value for testing things out. Array.prototype.contains is a good example for that: if it had been behind a pref, who knows when we'd have discovered the web breakage? I was not suggesting that we should have landed Array.prototype.contains behind a pref. However, there are other uses for being able to hide things behind a pref. One great example is this pattern: #ifdef NIGHTLY_BUILD pref(what.ever, true); #else pref(what.ever, false); #endif This basically ensures that we don't accidentally end up letting the feature slip past Nightly before we're ready (part of the definition of ready might be, knowing that the feature is Web compatible, etc.) Inside SpiderMonkey, we ensure that by doing the Nightly check where the feature is compiled/installed in the first place. For Array.prototype.contains, that is here: http://mxr.mozilla.org/mozilla-central/source/js/src/jsarray.cpp?rev=020a62efb303#3027 Oh, cool, I didn't know that. Now that obviously doesn't allow you to manually enable these features on Aurora and above. Assuming that you'd want to be able to do that in a fine-grained way, the prefs thing would be even more complicated: we'd have to add a way for the JS engine to query prefs, because just passing in all of them from the outside becomes untenable. One thing that would be possible, I suppose, is to have a single flag enable experimental extensions, as Chrome does. We should at least consider doing that, without changing our current behavior of having these features enabled by default on Nightly. I really dislike the idea of having a single pref which enables all kinds of random features. I think we could definitely build a UI on top of our existing experimental prefs if we decided that we wanted that, but I'd hate to lose the granularity of having one pref per feature. That being said, having one pref to control all experimental JS features sounds less bad to me. :-)
Re: PSA: Array.prototype.contains is going away again
On Thu, Oct 2, 2014 at 4:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: (Of course, I have no idea whether you'd be OK with just calling the Preferences API inside the js code or if we need to invent some kind of a way to mask that away, and just pass the necessary info into the JS engine from the browser, and I have no idea how much work that would be, but I think at least the first option is readily available if we decide to do that.) I think the correct thing to do would be to have XPConnect query these prefs and then set them on the runtime. If we wanted to, we could keep per-compartment state, have XPConnect monitor the pref and update the runtime, and have the runtime propagate the current bits to each compartment at creation time. This would let the pref would work for new compartments sans restart. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Documenting uses of Github at Mozilla
I don't have control over that site anymore. On Wed, Oct 1, 2014 at 10:19 AM, Ralph Giles gi...@mozilla.com wrote: Forked and PR submitted. Jeff, do you still have admin access on gitmirror.mozilla.org? Can you deploy and confirm the fix? -r On 2014-10-01 10:12 AM, Ralph Giles wrote: On 2014-10-01 9:49 AM, Mike Hoye wrote: I think the author of that intranet page has left us for Stripe a while ago. Who owns it now? Perhaps no one. I've just discovered in adding new repos that it's broken. The github webhook format has changed, and it's returning 500. -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 2014-10-02 4:03 AM, Jonathan Kew wrote: The format is primarily based on earlier TrueType compression work (MicroType Express) by Monotype, and a new entropy coder (Brotli) developed by Google's data compression team in Zurich. What kind of filesize reductions do you see over ttf and woff1? -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 2/10/14 16:20, Ralph Giles wrote: On 2014-10-02 4:03 AM, Jonathan Kew wrote: The format is primarily based on earlier TrueType compression work (MicroType Express) by Monotype, and a new entropy coder (Brotli) developed by Google's data compression team in Zurich. What kind of filesize reductions do you see over ttf and woff1? Results will vary considerably depending on the specific fonts involved, but a compressed size that is around 25-30% smaller than WOFF 1.0 would be typical for TrueType fonts. See Appendix B of http://www.w3.org/TR/WOFF20ER/. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Array.prototype.contains is going away again
On Thu, Oct 2, 2014 at 4:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-02, 9:58 AM, Till Schneidereit wrote: The full answer to that is actually ridiculously complicated. The part relevant here is, though: very early on in at least some cases. Too early to rely on preferences, if I'm not mistaken. I think the only reliable way would be to do it when creating the runtime. So, I took a quick look, and we create the first JSRuntime during the initialization of XPConnect, which is *way* after the XPCOM stuff required for the preferences service is initialized (I did verify that the preferences service is initialized before we create the runtime.) Ah, I was mistaken then, nice! Now, of course, there is no XPCOM (and no preferences service) in the js shell, but it seems like if we wanted to support preferences for this purpose for browser builds, the XPCOM side of things is not going to be an issue. I don't think we need to care about the shell at all. It can just always have all features. I really dislike the idea of having a single pref which enables all kinds of random features. I think we could definitely build a UI on top of our existing experimental prefs if we decided that we wanted that, but I'd hate to lose the granularity of having one pref per feature. That being said, having one pref to control all experimental JS features sounds less bad to me. :-) Sorry, I did mean JS features, not All The Things. On Thu, Oct 2, 2014 at 4:55 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: (Of course, I have no idea whether you'd be OK with just calling the Preferences API inside the js code or if we need to invent some kind of a way to mask that away, and just pass the necessary info into the JS engine from the browser, and I have no idea how much work that would be, but I think at least the first option is readily available if we decide to do that.) I think the correct thing to do would be to have XPConnect query these prefs and then set them on the runtime. If we wanted to, we could keep per-compartment state, have XPConnect monitor the pref and update the runtime, and have the runtime propagate the current bits to each compartment at creation time. This would let the pref would work for new compartments sans restart. Yes, that'd probably be the way to do this. I'm not sure how important the runtime updating part is, though. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 2014-10-02, 7:03 AM, Jonathan Kew wrote: The W3C WebFonts Working Group[1] has been working on designing and specifying a new compressed font format for the web, aiming to give significantly smaller file sizes than the existing WOFF format (to reduce bandwidth requirements), while remaining cheap to decode (for low-power devices). The format is primarily based on earlier TrueType compression work (MicroType Express) by Monotype, and a new entropy coder (Brotli) developed by Google's data compression team in Zurich. For more information about the WOFF2 format, see the FPWD spec[2] and current Editors' Draft.[3] WOFF2 is currently supported by Chrome and Opera,[4] and the Google webfonts service is serving WOFF2-compressed fonts to browser versions that are known to support it.[5] Is support for WOFF2 feature detectible? Or do people need to hardcode UA versions to know what UAs support it? I'm proposing to add WOFF2 support to Gecko, based on the reference implementation code from the Google font and compression teams, found at [6]. Support for WOFF2 will be controlled by a new boolean pref gfx.downloadable_fonts.woff2.enabled. Initially this defaults to false for release builds, and true for nightlies; when we're ready to ship the feature on-by-default, we can simply flip the pref to true for all channels. This work is happening in bugs [7] and [8], which I hope to land real soon now (in time for Gecko 35, if all goes well). - JK [1] http://www.w3.org/Fonts/WG/ [2] http://www.w3.org/TR/WOFF2/ [3] http://dev.w3.org/webfonts/WOFF2/spec/ [4] http://caniuse.com/#feat=woff2 [5] https://code.google.com/p/font-compression-reference/wiki/testing_woff2 [6] https://code.google.com/p/font-compression-reference/ [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1066160 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1064737 ___ 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: Intent to implement: WOFF2 webfont format
On Thursday, October 2, 2014 9:17:38 AM UTC-7, Ehsan Akhgari wrote: On 2014-10-02, 7:03 AM, Jonathan Kew wrote: WOFF2 is currently supported by Chrome and Opera,[4] and the Google webfonts service is serving WOFF2-compressed fonts to browser versions that are known to support it.[5] Is support for WOFF2 feature detectible? Or do people need to hardcode UA versions to know what UAs support it? You don't need UA detection, @fontface with format() hint does the trick: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization#defining-font-family-with-font-face ig ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1075985 to cover the fact that steeplechase does not work with the new layout. This is more of an FYI. Syd Polk sp...@mozilla.com +1-512-905-9904 irc: sydpolk On Sep 30, 2014, at 23:22, Robert Strong rstr...@mozilla.com wrote: The Mac package layout and signing changes merged to mozilla-central on Tuesday and the new layout will be present in the update on Wednesday. There are a couple of files still in the bundle after the first update to the new layout that will make the signature invalid. This shouldn't cause any problems since the signature is currently only checked on first launch after installing from the dmg and these files will be removed on the next update which should make the signature valid. Also, the signature should be valid when installing from the dmg as well as after each update from then on. If you find any bugs that you believe are due to these changes please file a new bug under toolkit - application update and we'll take it from there. Thanks go out to everyone involved in making this happen on such short notice! Cheers, Robert -Original Message- From: Robert Strong [mailto:rstr...@mozilla.com] Sent: Monday, September 22, 2014 2:07 AM To: dev-platform Subject: RE: Upcoming changes to Mac package layout, signing Quick status update on the progress for Mac v2 signing. All of the major changes for Mac v2 signing have landed on the Oak branch. This will allow us to test installing and updating before landing on mozilla- central. https://bugzilla.mozilla.org/show_bug.cgi?id=1046906 https://bugzilla.mozilla.org/show_bug.cgi?id=1046306 https://bugzilla.mozilla.org/show_bug.cgi?id=1047584 and the dependent bugs If no serious issues are found we are hoping to be able to land on mozilla- central later this week. There have been no significant deviations from what has been previously discussed in this thread and the current plan is to still target Firefox 34. We will be looking into how to get back parity on Mac to the current capabilities for distributions and administrative configurations after we finish the current work. Cheers, Robert ___ 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: PSA: Array.prototype.contains is going away again
On 10/2/14, 4:06 AM, Philip Chee wrote: Can we not reach out to the MooTools people and work together unbreak the web? Already done. Now you just have to get the several million sites using old MooTools versions to update. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using c++11 right angle bracket in template code?
On 2014-10-02, 1:14 AM, Xidorn Quan wrote:
On Wed, Oct 1, 2014 at 6:27 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
On 2014-10-01, 7:42 PM, L. David Baron wrote:
On Wednesday 2014-10-01 16:24 -0700, Eric Rescorla wrote:
Obviously, if you have some argument that auto is bad
programming practice
or a hazard and should thus be forbidden, that's something
you could make
and
see if people generally agree...
I think there are cases where |auto| makes code substantially less
readable, and cases where it's fine. I don't think I have enough
experience reading code using |auto| to say exactly what's in which
set, but I have mandated less use of |auto| in code reviews.
Some of it is simple readability; there are cases where seeing the
type of a variable allows its name to be simpler while preserving
the same level of readability, and if we're going to hide the type,
I'd want it to have a more complex name to make the code obvious.
But I'm also worried about use of auto leading people to stop using
const or where they should be (particularly where |auto| instead
of |const auto| leads to unnecessary expensive copies). (And I
think knowing whether I want |auto| or |const auto| requires
knowing the type, which makes the feature less valuable to me.)
I'm fine with just enforcing reasonable judgment in code reviews,
although I suspect some people would be bothered by having code
reviewers enforce style rules that aren't written down.
FWIW, I have had some actual practical experience in using |auto| in
the LLVM code base (and with reading code that uses it). Here is my
take on things:
* Beware of using auto in cases where types can be constructed
implicitly from other types.
This is the most important rule, I think. Here's an example of how
this can introduce real bugs. Let's imagine you have code like this:
nsIFoo* FooGetter();
nsCOMPtrnsIFoo foo = FooGetter();
DO NOT replace the type here with auto:
auto foo = FooGetter(); // NOT COOL!
After this change, foo will be a raw nsIFoo*, which is a weak
reference, so this changes the meaning of the program.
Arguably, this is not an issue with auto, but with implicit
conversions. It is one of the reasons why implicit conversions are
evil. :-)
* |auto| itself is rarely what you want (unless you know the
underlying type is not copyable), you probably want |auto| for
references if you intend to modify the original value, or |const
auto| if you don't. A sufficiently smart compiler should be able
to figure out that it doesn't actually need to create a reference
under the hood if the type it's seeing is a built-in one. (clang
seems to be able to do this based on a quick test.)
* If you find yourself typing the type once in the statement
already, use |auto|. Example:
auto ptr = static_castClass*(foo);
* Do not use auto for functions that can return different types that
have the same interface, as it obscures away the operation performed
on the type. Example:
class Container {
// ...
// Assume that the below iterator types map closely to the STL
concepts
iterator foo(int x);
reverse_iterator foo(string y);
};
Container c;
auto it = c.foo(str); // What kind of iterator do I have?!
* Do use auto for situations where the type doesn't really matter.
For example, if you have code like below:
foo(bar());
And want to put the call to |bar| into its own statements, and do
not care what the return type is, use auto:
const auto result = bar();
foo(result);
(Of course, depending on the nature of |foo| and |bar|, not all code
that looks like this should be refactored this way.)
* Do not use auto outside of a local scope. This helps restrict the
implications of auto to a hopefully smaller amount of code.
* Do not overuse auto. Consider auto as a handy tool that prevents
you from typing needlessly. But if you have code which uses auto
all over the place, you're *probably* doing it wrong.
* Remember that at the end of the day, code is read way more often
than it is written. If in doubt, opt for keeping the code more
readable by typing in what you mean, IOW, don't use auto when in doubt.
I want to add one case, which is when receiving some plain integers from
some kinds of functions, and doing computation based on them. For example:
nsTArraynsString array;
auto length = array.Length();
In this case, the perfectly exact type of |length| should be
nsTArraynsString::size_type. Before we have |auto|, the common way
is to write int32_t, uint32_t, size_t, or something similar. There
Re: Deprecate geolocation and getUserMedia() for unauthenticated origins
On Sep 30, 2014, at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-09-30, 4:29 AM, Henri Sivonen wrote: More immediately we should make it impossible to make persistent grants for these features on unauthenticated origins. This I agree with when it comes to privacy-sensitive API: Granting a persistent permission to an http: origin amounts to granting a persistent permission to everyone who in the future has a chance of performing an active MITM attack on you. I also think that we should definitely stop persisting the geolocation permission grant for non-authenticated origins. I'm not really sure if web compat allows us to remove support for the API completely (although admittedly I don't have data on this.) Either way, we should collect some data before we take action. ___ 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: Deprecate geolocation and getUserMedia() for unauthenticated origins
On 2014-10-02, 2:34 PM, Richard Barnes wrote: On Sep 30, 2014, at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-09-30, 4:29 AM, Henri Sivonen wrote: More immediately we should make it impossible to make persistent grants for these features on unauthenticated origins. This I agree with when it comes to privacy-sensitive API: Granting a persistent permission to an http: origin amounts to granting a persistent permission to everyone who in the future has a chance of performing an active MITM attack on you. I also think that we should definitely stop persisting the geolocation permission grant for non-authenticated origins. I'm not really sure if web compat allows us to remove support for the API completely (although admittedly I don't have data on this.) Either way, we should collect some data before we take action. What data specifically? I'm fairly confident that we can make this change no matter how many websites use geolocation from non-authenticated origins. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
JavaScript (strict) Warning from FF mochitest-plain test.
Hi, I was looking at a large number of JavaScript (strict) warnings, and errors from the recording of |make mozmill| test run of locall-built DEBUG BUILD of TB last several days after a refresh of C-C source tree. The number of such has increased very much both - due to the seemingly stricter checks done by JS infrastructure, and - new carelessly written code, I think. But the sheer number of them overwhelmed me and I began wondering is FF faring better? I don't think so. Here are the list of such errors summarized from the log of |./mach mochitest-plain| of locally-built DEBUG BUILD of FF (from M-C portion of C-C source tree). The # at the beginning of each line is the frequency of the occurrences. [I was looking at getter only message which is printed for more than 3K times during |make mozmill| test for TB for Services when checking the health of logs from FF tests came to my mind.) I think we need a sort of sheriff to look at these warnings and file bugzilla entries accordingly from time to time: I say this because it seems not many people look at debug build run of test suite often (well, at least on TB side. I don't know if TB debug run is created regularly.) Excerpt from summary of the log : ./mach mochitest-plain JavaScript strict warning jquery.js and jquery-ui.js are ignored. 206 JavaScript error: file:///home/ishikawa/ff-objdir-tb3/dist/bin/components/nsHandlerService.js, line 891: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] 99 JavaScript strict warning: , line 0: TypeError: setting getter-only property PrivateBrowsingUtils 66 JavaScript strict warning: , line 0: TypeError: setting getter-only property Services 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property TelemetryStopwatch 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property Task 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property PlacesUtils 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property NewTabUtils 11 JavaScript strict warning: chrome://specialpowers/content/specialpowersAPI.js, line 214: ReferenceError: reference to undefined property x.SpecialPowers_wrappedObject 4 JavaScript error: resource://gre/modules/XPCOMUtils.jsm, line 110: SyntaxError: missing ; before statement 4 JavaScript error: http://example.com/tests/content/base/test/bug696301-script-1.js, line 3: ReferenceError: c is not defined 4 JavaScript error: , line 0: uncaught exception: 2147500033 3 JavaScript strict warning: resource://specialpowers/MockFilePicker.jsm, line 92: SyntaxError: octal literals and octal escape sequences are deprecated 3 JavaScript strict warning: chrome://specialpowers/content/specialpowersAPI.js, line 662: ReferenceError: reference to undefined property wrapPrivileged(...).classes 3 JavaScript error: , line 0: uncaught exception: Permission denied to add http://mochi.test:/%sas a protocol handler 2 JavaScript strict warning: chrome://specialpowers/content/specialpowersAPI.js, line 665: ReferenceError: reference to undefined property wrapPrivileged(...).results 2 JavaScript error: resource://gre/modules/vtt.jsm, line 1261: TypeError: self.window.VTTRegion is not a constructor 2 JavaScript error: , line 0: uncaught exception: Permission denied to add http://remotehost:/%s as a content or protocol handler 2 JavaScript error: , line 0: uncaught exception: Permission denied to add ftp://mochi.test:/%s as a content or protocol handler 2 JavaScript error: , line 0: uncaught exception: Permission denied to add foo://mochi.test:/%s as a content or protocol handler 2 JavaScript error: , line 0: uncaught exception: 2152923148 1 JavaScript warning: resource://gre/modules/Preferences.jsm, line 381: mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create 1 JavaScript strict warning: resource://gre/modules/Webapps.jsm, line 539: ReferenceError: reference to undefined property Components.classes['@mozilla.org/app-migrator;1'] 1 JavaScript strict warning: resource://gre/modules/Webapps.jsm, line 389: ReferenceError: reference to undefined property aManifest.type 1 JavaScript strict warning: resource://gre/modules/Webapps.jsm, line 361: ReferenceError: reference to undefined property aResult.redirects 1 JavaScript strict warning: resource://gre/modules/Webapps.jsm, line 2136: ReferenceError: reference to undefined property app.appStatus 1 JavaScript strict warning: resource://gre/modules/Webapps.jsm, line 1683: ReferenceError: reference to undefined property aApp.appStatus 1 JavaScript strict warning:
Re: JavaScript (strict) Warning from FF mochitest-plain test.
We should most likely assert when we have strict violations in chrome JS. We should *definitely* assert when we have JS errors in chrome JS. I don't see how there should be any excuse for either of these cases. We certainly can't assert on non-browser JS errors, but we should keep our own scripts clean. - Original Message - From: chiaki ISHIKAWA ishik...@yk.rim.or.jp To: dev-platform@lists.mozilla.org Sent: Thursday, October 2, 2014 11:59:04 AM Subject: JavaScript (strict) Warning from FF mochitest-plain test. Hi, I was looking at a large number of JavaScript (strict) warnings, and errors from the recording of |make mozmill| test run of locall-built DEBUG BUILD of TB last several days after a refresh of C-C source tree. The number of such has increased very much both - due to the seemingly stricter checks done by JS infrastructure, and - new carelessly written code, I think. But the sheer number of them overwhelmed me and I began wondering is FF faring better? I don't think so. Here are the list of such errors summarized from the log of |./mach mochitest-plain| of locally-built DEBUG BUILD of FF (from M-C portion of C-C source tree). The # at the beginning of each line is the frequency of the occurrences. [I was looking at getter only message which is printed for more than 3K times during |make mozmill| test for TB for Services when checking the health of logs from FF tests came to my mind.) I think we need a sort of sheriff to look at these warnings and file bugzilla entries accordingly from time to time: I say this because it seems not many people look at debug build run of test suite often (well, at least on TB side. I don't know if TB debug run is created regularly.) Excerpt from summary of the log : ./mach mochitest-plain JavaScript strict warning jquery.js and jquery-ui.js are ignored. 206 JavaScript error: file:///home/ishikawa/ff-objdir-tb3/dist/bin/components/nsHandlerService.js, line 891: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] 99 JavaScript strict warning: , line 0: TypeError: setting getter-only property PrivateBrowsingUtils 66 JavaScript strict warning: , line 0: TypeError: setting getter-only property Services 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property TelemetryStopwatch 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property Task 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property PlacesUtils 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property NewTabUtils 11 JavaScript strict warning: chrome://specialpowers/content/specialpowersAPI.js, line 214: ReferenceError: reference to undefined property x.SpecialPowers_wrappedObject 4 JavaScript error: resource://gre/modules/XPCOMUtils.jsm, line 110: SyntaxError: missing ; before statement 4 JavaScript error: http://example.com/tests/content/base/test/bug696301-script-1.js, line 3: ReferenceError: c is not defined 4 JavaScript error: , line 0: uncaught exception: 2147500033 3 JavaScript strict warning: resource://specialpowers/MockFilePicker.jsm, line 92: SyntaxError: octal literals and octal escape sequences are deprecated 3 JavaScript strict warning: chrome://specialpowers/content/specialpowersAPI.js, line 662: ReferenceError: reference to undefined property wrapPrivileged(...).classes 3 JavaScript error: , line 0: uncaught exception: Permission denied to add http://mochi.test:/%sas a protocol handler 2 JavaScript strict warning: chrome://specialpowers/content/specialpowersAPI.js, line 665: ReferenceError: reference to undefined property wrapPrivileged(...).results 2 JavaScript error: resource://gre/modules/vtt.jsm, line 1261: TypeError: self.window.VTTRegion is not a constructor 2 JavaScript error: , line 0: uncaught exception: Permission denied to add http://remotehost:/%s as a content or protocol handler 2 JavaScript error: , line 0: uncaught exception: Permission denied to add ftp://mochi.test:/%s as a content or protocol handler 2 JavaScript error: , line 0: uncaught exception: Permission denied to add foo://mochi.test:/%s as a content or protocol handler 2 JavaScript error: , line 0: uncaught exception: 2152923148 1 JavaScript warning: resource://gre/modules/Preferences.jsm, line 381: mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create 1 JavaScript strict warning: resource://gre/modules/Webapps.jsm, line 539: ReferenceError: reference to undefined property Components.classes['@mozilla.org/app-migrator;1'] 1 JavaScript strict warning: resource://gre/modules/Webapps.jsm, line 389: ReferenceError:
Re: Documenting uses of Github at Mozilla
On 2014-10-01 12:16 PM, Ehsan Akhgari wrote: On 2014-10-01, 11:59 AM, Ralph Giles wrote: On 2014-10-01 7:17 AM, Mike Hoye wrote: Having to scramble to recover from data loss - particularly around source or bug tracking - is a miserable experience we should try to avoid. Perhaps http://gitmirror.mozilla.org/ should be our project directory. That is a great idea! There's a proposal to decommission gitmirror.m.o. in https://bugzilla.mozilla.org/show_bug.cgi?id=910040 ... in favor of git.m.o for major projects. I've made the case there that instead, we should keep it as an automated index of tier-2 GitHub repos and cc'ed Ehsan and Ralph on it, for initiating this discussion and issuing the first pull request to the old updater script respectively. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript (strict) Warning from FF mochitest-plain test.
On 10/02/2014 11:59 AM, ISHIKAWA,chiaki wrote: Hi, I was looking at a large number of JavaScript (strict) warnings, and errors from the recording of |make mozmill| test run of locall-built DEBUG BUILD of TB last several days after a refresh of C-C source tree. The number of such has increased very much both - due to the seemingly stricter checks done by JS infrastructure, and - new carelessly written code, I think. Did you compare the count from a while ago to the count today? I was kind of assuming that we've always had lots of these. But the sheer number of them overwhelmed me and I began wondering is FF faring better? I don't think so. No. It's awful. I wasted a couple of hours the other day on similar errors in xpcshell-test. I couldn't believe that such serious-sounding errors could have existed before my patch, but eventually discovered that they did. I think we need a sort of sheriff to look at these warnings and file bugzilla entries accordingly from time to time: I say this because it seems not many people look at debug build run of test suite often (well, at least on TB side. I don't know if TB debug run is created regularly.) Yeah, it seems nobody looks at it. Except when some random developer happens to break a test, and tries to figure out what warnings/errors are real and what are expected noise. It's pretty awful. Then again, we can't get people to fix intermittent test failures, and instead disable tests frequently. So finding such a sheriff is going to be... challenging. The understanding of many of these warnings tends to be specific to very localized parts of the codebase, so a single sheriff would need to pester a lot of people. Or not -- actually, a lot of these are probably easily solvable. If someone were willing to triage, they could probably at least cut down the number by quite a bit if they were willing to ignore the harder ones. These references to undefined whatever seem to have appeared suddenly thanks to the stricter checking of JS infrastructure. I wonder if that is a side effect of the 'let' TDZ (temporal dead zone) changes. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript (strict) Warning from FF mochitest-plain test.
See bug 807862 - Use strict mode for all builtin JS Note that some of those warnings are from SpiderMonkey's non-standard extra warnings mode, not ES5 strict mode. To confuse matters, extra warnings were called strict warnings before ES5 and are controlled by the javascript.options.strict pref. SpiderMonkey already forces ES5 strict mode and extra warnings mode for all self-hosted JS: bug 784295. chris On 10/2/14 12:22 PM, Jeff Gilbert wrote: We should most likely assert when we have strict violations in chrome JS. We should *definitely* assert when we have JS errors in chrome JS. I don't see how there should be any excuse for either of these cases. We certainly can't assert on non-browser JS errors, but we should keep our own scripts clean. - Original Message - From: chiaki ISHIKAWA ishik...@yk.rim.or.jp To: dev-platform@lists.mozilla.org Sent: Thursday, October 2, 2014 11:59:04 AM Subject: JavaScript (strict) Warning from FF mochitest-plain test. Hi, I was looking at a large number of JavaScript (strict) warnings, and errors from the recording of |make mozmill| test run of locall-built DEBUG BUILD of TB last several days after a refresh of C-C source tree. The number of such has increased very much both - due to the seemingly stricter checks done by JS infrastructure, and - new carelessly written code, I think. But the sheer number of them overwhelmed me and I began wondering is FF faring better? I don't think so. Here are the list of such errors summarized from the log of |./mach mochitest-plain| of locally-built DEBUG BUILD of FF (from M-C portion of C-C source tree). The # at the beginning of each line is the frequency of the occurrences. [I was looking at getter only message which is printed for more than 3K times during |make mozmill| test for TB for Services when checking the health of logs from FF tests came to my mind.) I think we need a sort of sheriff to look at these warnings and file bugzilla entries accordingly from time to time: I say this because it seems not many people look at debug build run of test suite often (well, at least on TB side. I don't know if TB debug run is created regularly.) Excerpt from summary of the log : ./mach mochitest-plain JavaScript strict warning jquery.js and jquery-ui.js are ignored. 206 JavaScript error: file:///home/ishikawa/ff-objdir-tb3/dist/bin/components/nsHandlerService.js, line 891: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] 99 JavaScript strict warning: , line 0: TypeError: setting getter-only property PrivateBrowsingUtils 66 JavaScript strict warning: , line 0: TypeError: setting getter-only property Services 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property TelemetryStopwatch 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property Task 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property PlacesUtils 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property NewTabUtils 11 JavaScript strict warning: chrome://specialpowers/content/specialpowersAPI.js, line 214: ReferenceError: reference to undefined property x.SpecialPowers_wrappedObject 4 JavaScript error: resource://gre/modules/XPCOMUtils.jsm, line 110: SyntaxError: missing ; before statement 4 JavaScript error: http://example.com/tests/content/base/test/bug696301-script-1.js, line 3: ReferenceError: c is not defined 4 JavaScript error: , line 0: uncaught exception: 2147500033 3 JavaScript strict warning: resource://specialpowers/MockFilePicker.jsm, line 92: SyntaxError: octal literals and octal escape sequences are deprecated 3 JavaScript strict warning: chrome://specialpowers/content/specialpowersAPI.js, line 662: ReferenceError: reference to undefined property wrapPrivileged(...).classes 3 JavaScript error: , line 0: uncaught exception: Permission denied to add http://mochi.test:/%sas a protocol handler 2 JavaScript strict warning: chrome://specialpowers/content/specialpowersAPI.js, line 665: ReferenceError: reference to undefined property wrapPrivileged(...).results 2 JavaScript error: resource://gre/modules/vtt.jsm, line 1261: TypeError: self.window.VTTRegion is not a constructor 2 JavaScript error: , line 0: uncaught exception: Permission denied to add http://remotehost:/%s as a content or protocol handler 2 JavaScript error: , line 0: uncaught exception: Permission denied to add ftp://mochi.test:/%s as a content or protocol handler 2 JavaScript error: , line 0: uncaught exception: Permission denied to add foo://mochi.test:/%s as a content or protocol handler 2 JavaScript error: , line 0: uncaught exception: 2152923148 1 JavaScript warning:
Re: JavaScript (strict) Warning from FF mochitest-plain test.
On 02/10/14 12:52, Chris Peterson wrote: SpiderMonkey already forces ES5 strict mode and extra warnings mode for all self-hosted JS: bug 784295. The problem is that this only generates an exception, not a test failure, so if the error is in code that isn't depended upon (also a problem), then it just disappears. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecate geolocation and getUserMedia() for unauthenticated origins
On 02/10/14 11:58, Ehsan Akhgari wrote: What data specifically? I'm fairly confident that we can make this change no matter how many websites use geolocation from non-authenticated origins. I believe that usual practice before we remove something we don't like is to provide some warning. There are some big sites that use geolocation from http:// origins. That said, those sites will continue to work. It is most likely treated in the same way as the user rejecting the request for location. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecate geolocation and getUserMedia() for unauthenticated origins
On 10/2/14 1:07 PM, Martin Thomson wrote: On 02/10/14 11:58, Ehsan Akhgari wrote: What data specifically? I'm fairly confident that we can make this change no matter how many websites use geolocation from non-authenticated origins. I believe that usual practice before we remove something we don't like is to provide some warning. There are some big sites that use geolocation from http:// origins. That said, those sites will continue to work. It is most likely treated in the same way as the user rejecting the request for location. I think Ehsan is only talking about removing the persistent always allow permission. The effect of doing so would be that the user would simply be prompted each for each request, instead of it being automatically allowed. It's not treated as a permission denial, and is what happens by default in Firefox. I'd have no objection to this. We can monitor Input feedback on the prerelease channels, before/after the change, to see if it's a problem prior to shipping it on release. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript (strict) Warning from FF mochitest-plain test.
Thanks for bringing this up! So ever since extra super awesome strict warning were turned on we indeed have to endure longer tail logs during test runs and when running debug builds. Just like I get the information telling me which video card my computer has for about the 1000th time. All in all, for someone looking for it, enough source for frustration! Now that we got past that point, let’s try to solve this! So how about starting with a tool that scrapes the warnings from the tbpl logs? I’m thinking it might be a cool Treeherder plugin. We got logs filenames and line numbers, a vcs, so we can even run a blame command and auto-create bugs and and auto-assign them to the one who introduced the error (or at least knows more about it)… Most of the errors I usually see are about uninitialised variables and undefined properties. JS errors are very bad. If they’re expected for some reason, it’d at least be nice to put a try…catch block around it to suppress the log clutter. These are all _very_ easy to fix. I think a tool would help greatly. Mike. On 02 Oct 2014, at 21:52, Chris Peterson cpeter...@mozilla.com wrote: See bug 807862 - Use strict mode for all builtin JS Note that some of those warnings are from SpiderMonkey's non-standard extra warnings mode, not ES5 strict mode. To confuse matters, extra warnings were called strict warnings before ES5 and are controlled by the javascript.options.strict pref. SpiderMonkey already forces ES5 strict mode and extra warnings mode for all self-hosted JS: bug 784295. chris On 10/2/14 12:22 PM, Jeff Gilbert wrote: We should most likely assert when we have strict violations in chrome JS. We should *definitely* assert when we have JS errors in chrome JS. I don't see how there should be any excuse for either of these cases. We certainly can't assert on non-browser JS errors, but we should keep our own scripts clean. - Original Message - From: chiaki ISHIKAWA ishik...@yk.rim.or.jp To: dev-platform@lists.mozilla.org Sent: Thursday, October 2, 2014 11:59:04 AM Subject: JavaScript (strict) Warning from FF mochitest-plain test. Hi, I was looking at a large number of JavaScript (strict) warnings, and errors from the recording of |make mozmill| test run of locall-built DEBUG BUILD of TB last several days after a refresh of C-C source tree. The number of such has increased very much both - due to the seemingly stricter checks done by JS infrastructure, and - new carelessly written code, I think. But the sheer number of them overwhelmed me and I began wondering is FF faring better? I don't think so. Here are the list of such errors summarized from the log of |./mach mochitest-plain| of locally-built DEBUG BUILD of FF (from M-C portion of C-C source tree). The # at the beginning of each line is the frequency of the occurrences. [I was looking at getter only message which is printed for more than 3K times during |make mozmill| test for TB for Services when checking the health of logs from FF tests came to my mind.) I think we need a sort of sheriff to look at these warnings and file bugzilla entries accordingly from time to time: I say this because it seems not many people look at debug build run of test suite often (well, at least on TB side. I don't know if TB debug run is created regularly.) Excerpt from summary of the log : ./mach mochitest-plain JavaScript strict warning jquery.js and jquery-ui.js are ignored. 206 JavaScript error: file:///home/ishikawa/ff-objdir-tb3/dist/bin/components/nsHandlerService.js, line 891: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] 99 JavaScript strict warning: , line 0: TypeError: setting getter-only property PrivateBrowsingUtils 66 JavaScript strict warning: , line 0: TypeError: setting getter-only property Services 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property TelemetryStopwatch 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property Task 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property PlacesUtils 33 JavaScript strict warning: , line 0: TypeError: setting getter-only property NewTabUtils 11 JavaScript strict warning: chrome://specialpowers/content/specialpowersAPI.js, line 214: ReferenceError: reference to undefined property x.SpecialPowers_wrappedObject 4 JavaScript error: resource://gre/modules/XPCOMUtils.jsm, line 110: SyntaxError: missing ; before statement 4 JavaScript error: http://example.com/tests/content/base/test/bug696301-script-1.js, line 3: ReferenceError: c is not defined 4 JavaScript error: , line 0: uncaught exception: 2147500033 3 JavaScript strict warning:
Re: Deprecate geolocation and getUserMedia() for unauthenticated origins
On 2014-10-02, 4:07 PM, Martin Thomson wrote: On 02/10/14 11:58, Ehsan Akhgari wrote: What data specifically? I'm fairly confident that we can make this change no matter how many websites use geolocation from non-authenticated origins. I believe that usual practice before we remove something we don't like is to provide some warning. There are some big sites that use geolocation from http:// origins. Oh, for sure. I don't have anything against warning people. :-) And in fact if we decide to do this we should publicize the idea on the hacks blog etc. That said, those sites will continue to work. It is most likely treated in the same way as the user rejecting the request for location. No, the way it would be handled is the user will get prompted again, and we wont show them the option of remembering their decision. The geolocation functionality itself would keep working fine. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecate geolocation and getUserMedia() for unauthenticated origins
On 2014-10-02, 4:38 PM, Justin Dolske wrote: On 10/2/14 1:07 PM, Martin Thomson wrote: On 02/10/14 11:58, Ehsan Akhgari wrote: What data specifically? I'm fairly confident that we can make this change no matter how many websites use geolocation from non-authenticated origins. I believe that usual practice before we remove something we don't like is to provide some warning. There are some big sites that use geolocation from http:// origins. That said, those sites will continue to work. It is most likely treated in the same way as the user rejecting the request for location. I think Ehsan is only talking about removing the persistent always allow permission. The effect of doing so would be that the user would simply be prompted each for each request, instead of it being automatically allowed. It's not treated as a permission denial, and is what happens by default in Firefox. Indeed (I phrased it very poorly!) I'd have no objection to this. We can monitor Input feedback on the prerelease channels, before/after the change, to see if it's a problem prior to shipping it on release. Great idea. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript (strict) Warning from FF mochitest-plain test.
Indeed, which is why I recommended assert, not warn. Warnings are basically useless from a CI standpoint. If you want to guarantee it, don't warn, assert. -Jeff - Original Message - From: Martin Thomson m...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Thursday, October 2, 2014 1:05:44 PM Subject: Re: JavaScript (strict) Warning from FF mochitest-plain test. On 02/10/14 12:52, Chris Peterson wrote: SpiderMonkey already forces ES5 strict mode and extra warnings mode for all self-hosted JS: bug 784295. The problem is that this only generates an exception, not a test failure, so if the error is in code that isn't depended upon (also a problem), then it just disappears. ___ 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: JavaScript (strict) Warning from FF mochitest-plain test.
On 2014-10-02, 4:40 PM, Mike de Boer wrote: Thanks for bringing this up! So ever since extra super awesome strict warning were turned on we indeed have to endure longer tail logs during test runs and when running debug builds. Just like I get the information telling me which video card my computer has for about the 1000th time. All in all, for someone looking for it, enough source for frustration! Now that we got past that point, let’s try to solve this! So how about starting with a tool that scrapes the warnings from the tbpl logs? I’m thinking it might be a cool Treeherder plugin. We got logs filenames and line numbers, a vcs, so we can even run a blame command and auto-create bugs and and auto-assign them to the one who introduced the error (or at least knows more about it)… Most of the errors I usually see are about uninitialised variables and undefined properties. JS errors are very bad. If they’re expected for some reason, it’d at least be nice to put a try…catch block around it to suppress the log clutter. These are all _very_ easy to fix. I think a tool would help greatly. Are we going to spend the time to fix these, however? For context, for as long as I remember, if you kept the browser console open and used the browser, we'd occasionally report an unhandled chrome JS errors (for example when attempting to access properties off of null variables). And those are not even strict errors. I've occasionally filed bugs for them, but my impression was that unless I can construct a case for those warnings to map to a user visible bug, they would not be fixed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript (strict) Warning from FF mochitest-plain test.
Are we going to spend the time to fix these, however? I’d be up for that, certainly! For context, for as long as I remember, if you kept the browser console open and used the browser, we'd occasionally report an unhandled chrome JS errors (for example when attempting to access properties off of null variables). And those are not even strict errors. I've occasionally filed bugs for them, but my impression was that unless I can construct a case for those warnings to map to a user visible bug, they would not be fixed. Hence my - perhaps controversial - idea to auto-create and auto-assign bugs. So for new warnings that appear in the integration branch and m-c logs we could even make those bugs block the bugs that introduced them. Mike. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew jfkth...@gmail.com wrote:
Or do people need to hardcode
UA versions to know what UAs support it?
I believe that's what Google Fonts currently does, though IMO a better
approach is to serve CSS that offers both WOFF2 and older (more
widely-supported) formats, using the @font-face src descriptor's format
hint to let the browser choose the optimal resource depending on what it
supports:
@font-face {
font-family: MyFont;
src: url(myfont.woff2) format(woff2),
url(myfont.woff) format(woff),
url(myfont.eot) format(embedded-opentype),
url(myfont.ttf) format(truetype);
}
Could we at least add woff2 to the Accept header when fetching fonts?
/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript (strict) Warning from FF mochitest-plain test.
On 10/2/14, 4:53 PM, Jeff Gilbert wrote: If you want to guarantee it, don't warn, assert. Note that mochitest-plain tests will go orange on unexpected uncaught exceptions. Not least because we added that pretty early on in their evolution. We're nowhere close to doing that with mochitest-chrome or browser-chrome. :( But it sure would be nice; I've had several instances of tests being effectively self-disabling because of an exception they were throwing early on. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
