Re: Collecting web platform features implementation status
On 16/07/15 21:51, Martin Thomson wrote: On Thu, Jul 16, 2015 at 12:26 PM, Anthony Ricaud anth...@ricaud.me wrote: In order to get accurate data and update it regularly, we need your help. Please go to the following etherpad and insert any information that can help us: https://etherpad.mozilla.org/gecko-web-platform-dashboard That's a fairly clumsy input scheme. Given the scale of this now, would it be unreasonable to request a form? Or maybe put it on github and accept pull requests. This will definitely live in Github in the future. I thought starting with Etherpad would make it easier to bulk contributions given the large number of features. But I can move it to Github tomorrow if no one objects. Regarding in progress|favorable|not favorable|no opinion, I think that we don't need to be opinionated about features we aren't implementing unless we have a firm commitment not to implement the feature. Here I'm thinking variously about ORTC and navigator.connect, which we could say bad things about now and end up implementing later if we aren't careful. Do we really want or need to use this list as a political tool? Developers want to know when something is coming foremost, and maybe if. I think that's all we need. I think there could be value in having a clear stance on our position but maybe that can be provided through the description field. I have no preference and will implement whatever the consensus is. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Collecting web platform features implementation status
On Thu, Jul 16, 2015 at 6:28 PM, Anthony Ricaud anth...@ricaud.me wrote: Regarding in progress|favorable|not favorable|no opinion, I think that we don't need to be opinionated about features we aren't implementing unless we have a firm commitment not to implement the feature. Here I'm thinking variously about ORTC and navigator.connect, which we could say bad things about now and end up implementing later if we aren't careful. Do we really want or need to use this list as a political tool? Developers want to know when something is coming foremost, and maybe if. I think that's all we need. I think there could be value in having a clear stance on our position but maybe that can be provided through the description field. I have no preference and will implement whatever the consensus is. FWIW, I've sent an intent to implement for the Streams API, but I won't be able to actually start work until Q4. I just listed that as favorable for now. Not sure if we need a clearer we intend to implement this but just haven't been able to start yet status. Thanks for putting this together! Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 07/16/2015 01:16 AM, Thomas Zimmermann wrote: Hi Am 16.07.2015 um 00:47 schrieb Jeff Gilbert: On Tue, Jul 14, 2015 at 7:55 AM, Thomas Zimmermann tzimmerm...@mozilla.com mailto:tzimmerm...@mozilla.com wrote: The discussion has a number of good points in favor of using 'a', but I missed convincing arguments in favor of not using 'a'. Are there any? I don't consider I don't get what 'a' is good for a convincing argument. On the other hand, I'm still unconvinced by the pro-'a' arguments I've read here. Besides roc's point about refactoring, the argument against aFoo is mainly about whether the information added is worth the noise. Adding information is not always worth it, since useless information is noise. One man's noise is another man's information. ;) Your arguments here and below are of the I don't need it so it's useless type. The core question is: How does removing this prefix help us in producing better code? To me, 'producing' includes 'writing' and 'reviewing/reading'. Using 'a' seems helpful to at least some reviewers. If we remove the prefix, does this improve the writing part significantly enough to make it worthwhile? My answer is No. Best regards Thomas To a user that doesn't know any coding, it appears to me that all of these style guides are wrong, and you need to start a campaign to change their thinking. Notable works or style guides [2] which do not recommend `aFoo`: [3] * Google * Linux Kernel * Bjarne Stroustrup * GCC * LLVM * Java Style (Java, non-C) * PEP 0008 (Python, non-C) * FreeBSD * Unreal Engine * Unity3D (largely C#) * Spidermonkey * Daala * RR * Rust * Folly (from Facebook) * C++ STL entrypoints * IDL for web specs on W3C and WhatWG * etc. I don't know what a style guide is, but if it is just a guide then remove aFoo, and those that use it go on using it. Those coming from coding one of the above won't have to go WTH, when they see the Mozilla style guide. Cheers! -- Kubuntu 14.10 | KDE 4.14.1 | Thunderbird 42.0a1(Daily) Go Bucs! [Coexist ยท Understanding Across Divides](https://www.coexist.org/) [Visit Pittsburgh](http://www.visitpittsburgh.com) [Pittsburgh Vintage Grand Prix -](http://www.pvgp.org/) July 10-19,2015 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On 16 July 2015 at 01:44, Robert O'Callahan rob...@ocallahan.org wrote: As long as platforms exist with homescreens and other inventories of installed apps, of which the browser is one, it seems worthwhile to me to support adding Web apps to those inventories so they're peers of native apps instead of having to go through a level of indirection by launching a browser, making them second-class. We can argue that such platforms shouldn't exist, but we also have to work with the reality that they do. Exactly. We can no longer talk about merging the web and native as some potential future thing that may or may not happen. It is already happening: 1. Android's Chrome Custom Tabs will keep users in native apps when following external hyperlinks https://developer.chrome.com/multidevice/android/customtabs 2. Android's App Links will let native apps register to handle a particular web URL scope and remove the choice of the user to choose to open in the browser instead https://developer.android.com/preview/features/app-linking.html 3. App install banners in Chrome may prompt users to install a web app or a native app, and the user may not even be able to tell the difference https://developers.google.com/web/updates/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android?hl=en http://www.w3.org/TR/appmanifest/#related_applications-member 4. Android's App Indexing will surface content from inside Android apps in Google results https://developers.google.com/app-indexing/ 5. iOS's Universal Links, Smart App Banners and new search API will do much of the same on iOS https://developer.apple.com/videos/wwdc/2015/?id=509 This all points towards a future where the web and proprietary app platforms are so intertwined that users may not even know the difference. The question is how we respond to that. On Firefox OS we have the freedom to define the entire experience, but on the other operating systems we touch we need to accept the reality of the environment that we find ourselves in. My personal conclusion is that we should react to all of the above by pushing back in the other direction by: 1. Helping users discover a web app before they discover its native equivalent, whilst browsing and searching the web 2. Making web content a first class citizen on every OS Firefox touches, with a standalone display mode for Firefox 3. Promoting re-engagement with web content through icons in launchers, offline and push notifications 4. Guiding users to the best of the web through a crowd-sourced, community curated guide The web has some unique advantages over other platforms, but those advantages are being eroded. It's up to us to prove that the web can still compete. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On 2015-07-15 6:47 PM, Jeff Gilbert wrote: Arg warts improve backtracking for debugging Regardless of the validity of Arg warts help illustrate information flow, the use-case of backtracking to 'origin' of aFoo is also unconvincing, since you'd only need to go back once more than previously before moving once back 'up'. Either way sounds eminently automateable. - No practical change, thus irrelevant. I don't understand what you're saying here at all. It seems that you're saying that this use case is not interesting to you, and that's OK, but that doesn't make it irrelevant. :-) It's hard to implement This is irrelevant for new code, and bulk-change is feasible once we have -Wshadow. (which isn't too hard. We shouldn't have shadowing in our code anyway, so we want -Wshadow regardless of this discussion) Besides, a number of our internal projects and modules already don't have it, so it's free for them. - Non-trivial, but not too hard to implement. The isn't too hard part of the above is factually incorrect. See bug 563195 for why. So, when you say I like aFoo because it lets me know which vars are args, is there any un-touched-on aspect of the information this var is an argument that is useful to know? How does every other project survive without it? Given Benjamin's response, there is really no point in arguing over this any more, but just as a thought exercise: is there anything that would convince you that this is useful for some people? I would expect having those people tell you that it's useful for them should be a good enough reason to assume that it is! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement W3C Manifest for web application
On 16 July 2015 at 14:36, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: As far as I can tell, neither of the above are things that another UA can hook into. Am I correct in my understanding here? I asked about that for Chrome Custom Tabs, a Googler told me there's an API so that other browsers can create the equivalent if they want to. I'm not sure if that's something we'd want to do with Fennec. But the important point is that it will keep users in the context of native apps and has the potential to reduce mindshare of the concept of the browser altogether. App Links and App Indexing bypass browsers altogether, install banners are something we could implement. If the above assertion is true, then you need to replace the web with Chrome and Safari on their respective OSes. Given the market share of those browsers on their respective operating systems I'd argue that amounts to the same thing. But yes, Firefox is its own island. With the new Android and iOS features I described that island is increasingly cut off from users. How does supporting W3C manifest or lack thereof help or hurt this? Couldn't we detect these web apps by looking at the meta tags inside pages? It seems like manifests are not technically needed for this. Sure. Web apps are just web sites with extra metadata. A manifest linked from a web page using a manifest link relation is a way for a page to associate itself with that metadata, for the purpose of discovery. The fact that it's JSON rather than HTML is largely a practical implementation detail, because adding 12+ meta tags to the head of every web page doesn't scale very well. As I said, for the simple use case of defining an application-name and icon meta tags work fine, and we will support that. How are we planning to hook into the OS through Firefox? It seems like a lot of the web integration coming to Android and iOS is essentially integration with the browser developed by the OS vendor. I'm trying to find that out, I'd be interested to see some experimentation of how possible it is to create a standalone display mode for Firefox on various operating systems, accessible by launchers added from the browser, treated as a separate app by the OS, but using the same Gecko instance and profile as Firefox. Like Chrome does on Android. 3. Promoting re-engagement with web content through icons in launchers, offline and push notifications Again, how does supporting W3C manifest or lack thereof help or hurt this? It seems like we can pick up the icons/application-name through the meta tag as well. An icon and name is not enough metadata to describe modern web apps, as I said above using a manifest file is just a practicality, like having CSS and JavaScript in separate files to HTML. And given that the manifest format helps people link to the native app offerings, it seems like supporting it will slightly hurt this goal! We don't have to implement that feature and we should argue to have it removed from the spec. I don't think this is a good enough reason to give up on the standardisation altogether. 4. Guiding users to the best of the web through a crowd-sourced, community curated guide I'm not sure how W3C manifest helps here either. W3C manifests allow web apps to be crawled by search engines and discovered by users through their user agent without needing them to be submitted to a central app store by the developer. They provide the metadata needed to describe a web app, and provide a built-in discovery mechanism. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Collecting web platform features implementation status
Potch and I are working on a website to present Mozilla's point of view on various web platform features. Other browsers have similar websites [1] [2] [3]. This project has been in lingo for a while so, to get it out the door, we're going to focus on one information: what is Mozilla's opinion on features that have not been shipped yet. We see 4 possible answers: in development, favorable, not favorable, no opinion. In order to get accurate data and update it regularly, we need your help. Please go to the following etherpad and insert any information that can help us: https://etherpad.mozilla.org/gecko-web-platform-dashboard Thanks for your help! [1] https://www.chromestatus.com/features [2] https://status.modern.ie [3] http://www.webkit.org/status.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Collecting web platform features implementation status
On Thu, Jul 16, 2015 at 12:26 PM, Anthony Ricaud anth...@ricaud.me wrote: In order to get accurate data and update it regularly, we need your help. Please go to the following etherpad and insert any information that can help us: https://etherpad.mozilla.org/gecko-web-platform-dashboard That's a fairly clumsy input scheme. Given the scale of this now, would it be unreasonable to request a form? Or maybe put it on github and accept pull requests. Regarding in progress|favorable|not favorable|no opinion, I think that we don't need to be opinionated about features we aren't implementing unless we have a firm commitment not to implement the feature. Here I'm thinking variously about ORTC and navigator.connect, which we could say bad things about now and end up implementing later if we aren't careful. Do we really want or need to use this list as a political tool? Developers want to know when something is coming foremost, and maybe if. I think that's all we need. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unprefixed CSS and DOM properties (across browser vendors)
This is the bug I filed to capture the unprefix list: https://bugzilla.mozilla.org/show_bug.cgi?id=775235 Having our dev-tools alert for deprecated syntax would be very helpful. +cc dev-developer-tools for feedback. --Jet On Wed, Jul 15, 2015 at 10:05 PM, Karl Dubost kdub...@mozilla.com wrote: Hello, (mostly for people of DOM and CSS) tl;dr: A list of unprefixed properties where the prefixed version has been dropped. Context: A feature has 4 states (or at least my impression): 1. No support 2. prefixed only support (MozFoo and -moz-bar) 3. prefixed and unprefixed support (MozFoo, Foo, -moz-bar and bar) 4. unprefixed only support (Foo and bar) For Web Compatibility, dropping the unprefixed version may create issues (See the recent issue with -moz-gradient). I would love to know if we have an always up to date list features state for Firefox/Gecko. Both caniuse and MDN are giving the information on when the prefixless version has been introduced but never when/if the prefix has been dropped. Why is it interesting? Given the current state of the Chinese and Japanese Web, some prefixes seem impossible to drop both for Mozilla, but also other browser vendors. Having the list of the current state could help us to send the right message to Web developers on 1. adding prefixless versions to their code 2. sometimes to remove the prefixed version of their code (more difficult because of old mobile devices). PS: I want to know that for WebKit, Blink and Edge too. I will ask around. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Collecting web platform features implementation status
On 2015-07-16 9:21 PM, Martin Thomson wrote: On Thu, Jul 16, 2015 at 5:44 PM, Benjamin Kelly bke...@mozilla.com wrote: FWIW, I've sent an intent to implement for the Streams API, but I won't be able to actually start work until Q4. I just listed that as favorable for now. Not sure if we need a clearer we intend to implement this but just haven't been able to start yet status. I would rather have: - done (Firefox X) - planned (with some vague time frame) - under investigation or no current plans Streams seems straightforward enough. navigator.connect would fall into the last category. I think we need to have a way to signal that we are not going to implement a specific feature in addition to those categories (without delving into the specific example here, but yes this is one of those features.) That sends a useful signal to other browser vendors and web developers. I know that for us, it would be hugely helpful to know if vendor X is actively planning to not implement a certain feature when weighing the pros and cons of working on something. I can imagine the same would be useful for other vendors, and it would be nice if we did that. Thinking about this more, I really don't see why we should try to narrow down the list to fewer items. I feel like our default position on a random spec is no opinion, because we aren't aware of the content. After someone studies it a bit, we can spend a while to consider it, and then defer it to some point into the future (as in in support of, without current plans), or decide to work on it soon, or decide that we should not work on it, etc. Of course, we can't get too fine grained to keep things comprehensible and realistic to keep updated, but a couple of additional categories wouldn't hurt! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Collecting web platform features implementation status
Agreed. This is about how we feel about a spec, its content, and the design of its API, not about if or when we will get around to implementing it. That's also something worth capturing, but they're not the same data points at all. Eric Shepherd Sr. Technical Writer Mozilla Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy On Jul 16, 2015, at 10:26 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Thinking about this more, I really don't see why we should try to narrow down the list to fewer items. I feel like our default position on a random spec is no opinion, because we aren't aware of the content ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)
On 7/16/15 11:33 PM, Mike Taylor wrote: Will we ever run into the same problems with unprefixing rAF raised on blink-dev[1]? I see 932322 was partially backed out and 943958 seems to describe the `var requestAnimationFrame = window.requestAnimationFrame` problem. Mike, Thank you for checking this! Bug 932322 was backed out a few times on branches, but it stuck in Firefox 31. So in Gecko right now (as of Gecko 31), window.hasOwnProperty(requestAnimationFrame) returns true and code like var requestAnimationFrame = will work correctly. So we should be good on this front. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Collecting web platform features implementation status
On Thu, Jul 16, 2015 at 7:26 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-07-16 9:21 PM, Martin Thomson wrote: On Thu, Jul 16, 2015 at 5:44 PM, Benjamin Kelly bke...@mozilla.com wrote: FWIW, I've sent an intent to implement for the Streams API, but I won't be able to actually start work until Q4. I just listed that as favorable for now. Not sure if we need a clearer we intend to implement this but just haven't been able to start yet status. I would rather have: - done (Firefox X) - planned (with some vague time frame) - under investigation or no current plans Streams seems straightforward enough. navigator.connect would fall into the last category. I think we need to have a way to signal that we are not going to implement a specific feature in addition to those categories (without delving into the specific example here, but yes this is one of those features.) That sends a useful signal to other browser vendors and web developers. I know that for us, it would be hugely helpful to know if vendor X is actively planning to not implement a certain feature when weighing the pros and cons of working on something. I can imagine the same would be useful for other vendors, and it would be nice if we did that. Thinking about this more, I really don't see why we should try to narrow down the list to fewer items. I feel like our default position on a random spec is no opinion, because we aren't aware of the content. After someone studies it a bit, we can spend a while to consider it, and then defer it to some point into the future (as in in support of, without current plans), or decide to work on it soon, or decide that we should not work on it, etc. Of course, we can't get too fine grained to keep things comprehensible and realistic to keep updated, but a couple of additional categories wouldn't hurt! I don't think it's important to minimize the number of categories, but I do think it's a mistake to have categories which provide sentiment but not definiteness. What I mean by that is that I'm not a big fan of favorable and unfavorable but rather I'd rather see planned and we do not intend to implement this (though maybe there's a way to make that shorter). -Ekr ___ 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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
On Thu, Jul 16, 2015 at 6:50 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-07-15 6:47 PM, Jeff Gilbert wrote: Arg warts improve backtracking for debugging Regardless of the validity of Arg warts help illustrate information flow, the use-case of backtracking to 'origin' of aFoo is also unconvincing, since you'd only need to go back once more than previously before moving once back 'up'. Either way sounds eminently automateable. - No practical change, thus irrelevant. I don't understand what you're saying here at all. It seems that you're saying that this use case is not interesting to you, and that's OK, but that doesn't make it irrelevant. :-) Not at all! Rather, that either way it would be workable. The tiny extra bit of effort it would take without aFoo is completely solved by automation, and if this is a common enough use-case for this tiny extra bit of effort to matter, it should *already* have been automated. Thus I don't have a ton of sympathy for making a readily-automateable process require differentially more effort without automation. It's hard to implement This is irrelevant for new code, and bulk-change is feasible once we have -Wshadow. (which isn't too hard. We shouldn't have shadowing in our code anyway, so we want -Wshadow regardless of this discussion) Besides, a number of our internal projects and modules already don't have it, so it's free for them. - Non-trivial, but not too hard to implement. The isn't too hard part of the above is factually incorrect. See bug 563195 for why. I have read it, and it doesn't seem insurmountable. Just because it's not free doesn't make it 'too hard'. I am naturally willing to work on this myself. So, when you say I like aFoo because it lets me know which vars are args, is there any un-touched-on aspect of the information this var is an argument that is useful to know? How does every other project survive without it? Given Benjamin's response, there is really no point in arguing over this any more, but just as a thought exercise: is there anything that would convince you that this is useful for some people? There's only no point here if Benjamin's proposal carries! Besides, this discussion is certainly a subset of the boil-the-ocean discussion. If aFoo is truly valuable, then removing it via Google Style would hurt us just as removing it a la carte would. What could convince me? Reasoned and consistent arguments, perhaps examples or anecdotes where aFoo really came in handy that wouldn't have been covered under general good code style. Maybe someone might have done a study on this style. Maybe there are other large projects which use this style. Tautologically: Convincing arguments! I would expect having those people tell you that it's useful for them should be a good enough reason to assume that it is! Especially as part of standards body, I'm perfectly fine with dismissing requests for things people claim to want, but can't provide sufficient reasoning for, [1] or likewise being unable to argue my own case successfully. I'm well-acquainted with being convinced to change my position through discussion and debate, and also with convincing others. (or not!) This is why we have these discussions! Claims are not substantiated simply because people claim them to be true. We need to lay the reasons on the table and then weigh them, as without reasons, choices are arbitrary. Sometimes we even need to do it more than once, as time changes things. (even if people hate doing this!) We may find no need for change, or we may instead find we can change for the better. [1]: To be clear, sufficient reasoning can definitely include culture, harsh realities, pragmatism, and other such things. They are not all granted the same gravity, but they all contribute. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)
On 7/16/15 19:08, Boris Zbarsky wrote: Web compat impact for mozRequestAnimationFrame/mozCancelAnimationFrame: Not known for sure, but expected to be small to none. Pretty much any real-life web code that uses this API will also used the unprefixed version or at worst fall back to setTimeout/setInterval. Unfortunately, a use counter would not help much here because of web sites that prefer using the prefixed version to the unprefixed one. Will we ever run into the same problems with unprefixing rAF raised on blink-dev[1]? I see 932322 was partially backed out and 943958 seems to describe the `var requestAnimationFrame = window.requestAnimationFrame` problem. [1] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/5S7qeLSXT5Q/aN01cHXbVg8J -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)
On 7/16/15 9:04 PM, Boris Zbarsky wrote: On 7/16/15 8:34 PM, Kyle Huey wrote: There are a handful of uses in Gaia. Oh, gah. I keep forgetting gaia's on a separate mxr repo. I'll get together a pull request. Good catch. Actually, I just looked, and I had in fact checked on those and decided they wouldn't break and moved on. Let's see whether people are OK with me changing those libraries outside the clock app. ;) -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Collecting web platform features implementation status
On Thu, Jul 16, 2015 at 5:44 PM, Benjamin Kelly bke...@mozilla.com wrote: FWIW, I've sent an intent to implement for the Streams API, but I won't be able to actually start work until Q4. I just listed that as favorable for now. Not sure if we need a clearer we intend to implement this but just haven't been able to start yet status. I would rather have: - done (Firefox X) - planned (with some vague time frame) - under investigation or no current plans Streams seems straightforward enough. navigator.connect would fall into the last category. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)
On Thu, Jul 16, 2015 at 5:08 PM, Boris Zbarsky bzbar...@mit.edu wrote: Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=909154 APIs to be removed: mozRequestAnimationFrame, mozAnimationStartTime, mozCancelAnimationFrame. As of today, they are not used in our tree. There are a handful of uses in Gaia. None of them look like they will break, but we should still clean them up. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 7/15/2015 3:23 AM, Benjamin Smedberg wrote: Given that premise, we shouldn't just change aArgument; we should adopt the Google C++ style guide wholesale: * names_with_underscores * members_with_trailing_ * no more ns prefix I used this style in a personal project, and I quickly came to regret it. Distinguishing whether a variable is a member verses being a local var by a single '_' character I found was harder, as '_' is a very small character, and is hard to see, especially when syntax highlighting is underlining the word. Whereas the difference between a leading 'a' and 'm' is very obvious, even when syntax highlighting is underlining the word. I think adopting Google style is a bad idea. cpearce. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New requirement for tier 1 platforms: working assertion stacks
Ehsan Akhgari schrieb: Is someone signing up to do the work to keep the working on all tier 1 platforms now? I know it's not a platform, but does JIT conflict with this? Ion JIT stack are not walkable in any way that the stackwalker understands... (Actually, I do not know of any way to even detect if a crash is in the Ion JIT - in Baseline JIT, stacks are walkable by frame pointers and the first frame that actually make sense is something like EnterBaseline which ends up as the crash signature). KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)
Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=909154 APIs to be removed: mozRequestAnimationFrame, mozAnimationStartTime, mozCancelAnimationFrame. As of today, they are not used in our tree. Web compat impact for mozRequestAnimationFrame/mozCancelAnimationFrame: Not known for sure, but expected to be small to none. Pretty much any real-life web code that uses this API will also used the unprefixed version or at worst fall back to setTimeout/setInterval. Unfortunately, a use counter would not help much here because of web sites that prefer using the prefixed version to the unprefixed one. Web compat impact for mozAnimationStartTime: I expect none, since no other browser supports anything like it. Extension compat impact: There are some extensions using mozCancelAnimationFrame and mozAnimationStartTime but not very many and they should be easy to update. There are _lots_ of extensions with hits on mozRequestAnimationFrame but most of those seem to be a comment in the add-on SDK and various web libraries. Again, I expect any extensions that _do_ solely use mozRequestAnimationFrame to be easy to update, but hunting them down might be a bit of work... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)
On 7/14/2015 8:23 AM, Benjamin Smedberg wrote: Aww, I was avoiding getting into this thread. ... The argument I am most sympathetic to is that this convention is a barrier to new contributors. Making new contributors productive, both employees and volunteers, is a very good reason to choose one style over another. I have also avoided getting into this thread, as the whole premise seems to me to be pretty clueless about what makes Mozilla code difficult for newcomers. I think I'm a pretty good authority on experience of newcomers, as I spend a pretty good part of my Mozilla life tracing out Thunderbird issues in core Mozilla code that I know very little about. Earlier in the week it was the addon manager, today it is certificate handling. I find the same thing over and over again that makes Mozilla code really difficult to approach when you are not already an expert. And it has nothing to do with whether you include the a in front of method variables or not. What is missing? The most basic description of what major functions do, and how they are supposed to interact with the rest of code. If you really to be Making new contributors productive then require that! Examples: 1) Earlier this week, it was the addon code. Checkout XPIProvider.jsm No description anywhere of what this is supposed to do or how it interacts with other code. Yes there is detailed documentation of some of the function calls, but nowhere can I understand the relationship of this to AddonManager, which seems to pretty much do he same thing just from the titles. Only by hours and hours of tracing out code can I figure out their relationship (see bug 1183733 for the final result). Documentation of function calls does not really help when, as a newcomer, you don't understand the big picture. 2) Currently, looking at some sort of regression in certificate management with STARTTLS. Look at TCPSocketChild.cpp for example, no clue anywhere in that file what it is about. Or nsNSSCertificate.cpp no clue what that really does, and the code does not give any hints. So if you want to make things easier for newcomers, require that modules have some sort of overview of what they are supposed to do, and how they interact with other code. Don't waste time on code churn with style of existing code. :rkent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)
On 7/16/15 8:34 PM, Kyle Huey wrote: There are a handful of uses in Gaia. Oh, gah. I keep forgetting gaia's on a separate mxr repo. I'll get together a pull request. Good catch. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
