Re: Intent to implement HTMLMediaElement.srcObject partially
On 7/15/15 9:28 PM, jyaven...@mozilla.com wrote: I need to complete bug 886194 then (that add MSE supports). Yes, or at least rename the subject slightly. ;) PS: We have the same first name in different language. awesome. Hey, that's rare for us! .: Jan-Ivar :. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Unprefixed CSS and DOM properties (across browser vendors)
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
Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement HTMLMediaElement.srcObject partially
On 7/15/15 3:42 PM, Jan-Ivar Bruaroey wrote: This means it will support get/set of: MediaStream objects. This means it will throw TypeError on set of: MediaSource objects, Blob objects, and File objects, for now. Jan-Ivar, Do you happen to know whether other UAs support this unprefixed and if so what the state of their support is? Also, of the ones who don't support it unprefixed, any idea on their unprefixing plans? I have no idea is a fine response here; I'm just asking for information you may already have, not asking you to go do research. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement HTMLMediaElement.srcObject partially
On Wed, Jul 15, 2015 at 12:42 PM, Jan-Ivar Bruaroey j...@mozilla.com wrote: This means it will throw TypeError on set of: MediaSource objects, Blob objects, and File objects, for now. For what it's worth, I think implementing Blob/File support would be quite trivial. Just make elem.srcObject = blob; internally call URL.revokeObjectURL(this.mOldObjectURL); this.mOldObjectURL = URL.createObjectURL(blob); LoadSrc(this.mOldObjectURL); / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement HTMLMediaElement.srcObject partially
On 07/15/2015 10:42 PM, Jan-Ivar Bruaroey wrote: Hi, We intend to un-prefix HTMLMediaElement.srcObject (it currently exists as HTMLMediaElement.mozSrcObject), even though it only supports a subset of the types mandated in the spec. [1] It is a bit unfortunate to expose the property without supporting what is in the spec atm, but I think it is good enough for now. -Olli This means it will support get/set of: MediaStream objects. This means it will throw TypeError on set of: MediaSource objects, Blob objects, and File objects, for now. The intent is still to support these other types eventually. [2] The reason for doing this now is that this subset of funtionality is believed to be stable, and is valuable to user-cases in WebRTC and MediaCapture and Streams. Bug: https://bugzil.la/1175523 Links: [1] https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-srcobject [2] https://html.spec.whatwg.org/multipage/embedded-content.html#media-provider-object Platform coverage: All. Estimated or target release: ASAP, Q3, 2015 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement HTMLMediaElement.srcObject partially
On Thursday, July 16, 2015 at 5:42:39 AM UTC+10, Jan-Ivar Bruaroey wrote: Hi, We intend to un-prefix HTMLMediaElement.srcObject (it currently exists as HTMLMediaElement.mozSrcObject), even though it only supports a subset of the types mandated in the spec. [1] This means it will support get/set of: MediaStream objects. This means it will throw TypeError on set of: MediaSource objects, Blob objects, and File objects, for now. The intent is still to support these other types eventually. [2] The reason for doing this now is that this subset of funtionality is believed to be stable, and is valuable to user-cases in WebRTC and MediaCapture and Streams. Bug: https://bugzil.la/1175523 I need to complete bug 886194 then (that add MSE supports). PS: We have the same first name in different language. awesome. ___ 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 Wed, Jul 15, 2015 at 8:15 AM, mar...@marcosc.com wrote: 1. Enhance browser tiles: many sites have nice logos/icons, and they have an application-name. I want to show the application-name and icon or logo them in tiles in the new tab page. This seems possible using meta name=application-name + link rel=icon sizes. 2. Page previews suck today: they are mostly broken, don't show the right content, they are badly zoomed, and don't lead me to the right place. Be nice if developers could provide a link to a page I can render in a tile + a preferred start URL. As a developer, I want this tile to get updated using a push notification and I want it to work offline. I'm not sure what feature this is, but as Martin said this can probably be easily extracted and retrofitted as meta and/or link features. Similar to Apple's recent link rel=mask-icon proposal. -- https://annevankesteren.nl/ ___ 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 Tue, Jul 14, 2015 at 3:00 PM, mar...@marcosc.com wrote: Some of the things raised: * It's not clear what problems manifest solves: do we really want to replicate native app installation behavior on the Web? We don't have a good history of making this work in various products. * Extra HTTP request could yield a performance penalty (even if deprioritized)... though probably not a concern in a HTTP2 world. * Can't we just use meta tags (application-name, etc.)? * App-scope is as bad, or worst, than scope in service workers (i.e., you only get one directory in a domain, or the whole domain). * How would Desktop firefox make use of display modes? (i.e., how would they work with tab browsing) The work on manifests started because Alex Russell from Google reached out to me and said that Google was looking at building a web app implementation and asked if I had ideas where to start. However the way that manifests ended up getting specified and implemented they aren't really a suitable base for web apps. I.e. it's not at all the thing that was envisioned when I started talking with Google about manifests. Which is actually totally fine since we in FirefoxOS no longer are working on creating a web apps platform. I agree that the manifest spec as it ended up being defined is very equivalent to just a bunch of meta tags. Which I also pointed out during the spec development [1][2]. However I still feel like the separate manifest file might hold some value. Don't Repeat Yourself still seems valuable. Allowing developers to link to a separate file from everywhere seems likely to lead to less out-of-date information in different files on the website. And avoiding to transfer the metadata when it's not needed by avoiding to download the manifest during normal browsing also seems like a minor win. However with icons being duplicated in both meta tags and in the manifest, in order to show beautiful icons in the browser tab UI, then we're actually causing developers to have to repeat themselves more, not less. I also think that display-mode and orientation (and maybe theme_color) properties seem to make much less sense given the current model of manifests. That seems like information that we'd want to apply during normal browsing too, which means that it's not really appropriate for the manifest but rather for a meta tag. I also can't think of a really good use of the scope property. I know it's something we're planning on using in the FirefoxOS pinning feature, but I'm not convinced that the resulting UI will be understandable to users. User testing will show. All in all I can't say that I'm passionate either way here. The manifest seems pretty equivalent to a bunch of meta tags to me. And as long as we don't end up having to download it during normal navigation, then it doesn't seem any significantly worse. I.e. I have a hard time rallying for using meta given that it seems pretty much the same. But it'd be *really* nice to get rid of features that are there specifically to migrate users away from the web and to native Android and iOS apps. If google/apple wants to implement that then that's fine with me, it's their browsers. I just don't see why that needs to be sanctioned by a web specification. It'd be nice if the spec took as hard of a line against native app stores as it did against web app stores. [1] https://github.com/w3c/manifest/issues/272#issuecomment-87495930 [2] https://github.com/w3c/manifest/issues/272#issuecomment-89411351 / Jonas ___ 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 15 July 2015 at 10:42, Jonas Sicking jo...@sicking.cc wrote: But it'd be *really* nice to get rid of features that are there specifically to migrate users away from the web and to native Android and iOS apps. If google/apple wants to implement that then that's fine with me, it's their browsers. I just don't see why that needs to be sanctioned by a web specification. It'd be nice if the spec took as hard of a line against native app stores as it did against web app stores. I strongly agree with this. I think the related_applications [1] and prefer_related_applications [2] properties have no place in a W3C specification and are potentially very harmful to the web. 1. http://w3c.github.io/manifest/#related_applications-member 2. http://w3c.github.io/manifest/#prefer_related_applications-member ___ 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 15 July 2015 at 10:42, Jonas Sicking jo...@sicking.cc wrote: I also think that display-mode and orientation (and maybe theme_color) properties seem to make much less sense given the current model of manifests. That seems like information that we'd want to apply during normal browsing too, which means that it's not really appropriate for the manifest but rather for a meta tag. We already have a way for an individual web page to set orientation and theme-color while browsing with page metadata and a JavaScript API. I think the value of having these properties in the manifest is that they can be applied to the URL scope of a whole site rather than just an individual page by applying the manifest to a browsing context to create what the spec calls an application context, which just means that it already has default metadata applied for a group of web pages. Otherwise you have to wait for each individual page to download to know what display properties to use. This is bad for UX. I don't think the display property is relevant whilst browsing because you are, by definition, in the browser display mode. I also can't think of a really good use of the scope property. I know it's something we're planning on using in the FirefoxOS pinning feature, but I'm not convinced that the resulting UI will be understandable to users. User testing will show. Yes we are using this for Pin the Web in Firefox OS, and we are putting that UI through user testing, I agree it needs testing. FWIW I think the scope and display properties could be even more important for an implementation in Firefox (on mobile and on desktop), if that was to go ahead. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
API documentation/evangelism/development teams meeting Thursday at 8 AM PDT
The Web API documentation community meeting, with representatives from the technical evangelism and the API development teams, will take place on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your time zone). Typical meetings include news about recent API development progress and future development plans, discussions about what the priorities for documenting and promoting new Web technologies should be, and the status of ongoing work to document and evangelize these technologies. We have an agenda, as well as details on how to join, here: https://etherpad.mozilla.org/API-docs-meeting-2015-07-16. If you have topics you wish to discuss, please feel free to add them to the agenda. We look forward to seeing you there! If you have topics you wish to discuss, please feel free to add them to the agenda. Also, if you're unable to attend but have information or suggestions related to APIs on the Web, their documentation, and how we promote these APIs, please add a note or item to the agenda so we can be sure to address it, even if you're unable to attend. -- Eric Shepherd Senior Technical Writer Mozilla https://www.mozilla.org/ Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy Check my Availability https://freebusy.io/esheph...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement HTMLMediaElement.srcObject partially
Hi, We intend to un-prefix HTMLMediaElement.srcObject (it currently exists as HTMLMediaElement.mozSrcObject), even though it only supports a subset of the types mandated in the spec. [1] This means it will support get/set of: MediaStream objects. This means it will throw TypeError on set of: MediaSource objects, Blob objects, and File objects, for now. The intent is still to support these other types eventually. [2] The reason for doing this now is that this subset of funtionality is believed to be stable, and is valuable to user-cases in WebRTC and MediaCapture and Streams. Bug: https://bugzil.la/1175523 Links: [1] https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-srcobject [2] https://html.spec.whatwg.org/multipage/embedded-content.html#media-provider-object Platform coverage: All. Estimated or target release: ASAP, Q3, 2015 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Summary of e10s performance (Talos + Telemetry + crash-stats)
For the e10s talos regressions see https://bugzilla.mozilla.org/show_bug.cgi?id=1174776 and https://bugzilla.mozilla.org/show_bug.cgi?id=1184277. We've already diagnose one source of the regression to be a difference with GC/CC behavior when running e10s talos. On Fri, Jul 10, 2015 at 5:44 PM, Vladan Djeric vdje...@mozilla.com wrote: Yup, the median shutdown duration for Release 39 users on Windows with Telemetry is 2.3 seconds for example: http://mzl.la/1HSHiD8 Those are also the kinds of shutdown times I see on my Windows machines when I have 3-5 windows open with 5-10 tabs each. What is your experience? Btw, you can go to about:telemetry and look through your archived Telemetry pings to see a history of your own shutdownDurations. Open about:telemetry, select Archived ping data, open the Simple Measurements section, and use the next-previous arrows to look through your Telemetry submissions. Focus on the saved-session pings. On Fri, Jul 10, 2015 at 5:33 PM, Mike Hommey m...@glandium.org wrote: On Fri, Jul 10, 2015 at 03:59:43PM -0400, Vladan Djeric wrote: A few of us on the perf team (+ Joel Maher) looked at e10s performance stability using Talos, Telemetry, and crash-stats. I wrote up the conclusions below. Notable improvements in Talos tests [1]: * Hot startup time in Talos improved by about 50% across all platforms (ts_paint [2]). This test measures time from Firefox launch until a Firefox window is first painted (ts_paint); I/O read costs are not accounted for, as data is already cached in the OS disk buffer before the test. * The tsvgr_opacity test improved 50-80% across all platforms. This is a sign of a reduction in the overhead of loading a page, instead of an improvement in actual SVG performance. * Linux scrolling performance improved 5-15% * The long-standing e10s WebGL performance regression has been fixed * SVG rendering performance (tsvgx) is ~25% better on Windows 7 8, but it is 10% worse on Windows XP and 25% worse on Linux Notable regressions in Talos tests [1]: * There are several large regressions unique to Windows XP. Scrolling smoothness regressed significantly (5-6 times worse on tp5o_scroll and tscrollx [2]), resizing of Firefox windows is 150% worse (tresize), SVG rendering performance is 25% worse (tsvgx) * Page loading time regressed across all platforms (tp5o). Linux regressed ~30%, OS X 10.10 regressed 20%, WinXP/Win8/Win7 all regressed ~10%. Page-loading with accessibility enabled (a11yr) saw similar regressions. * Time to open a new Firefox window (tpaint) regressed 30% on Linux, and across different versions of Windows (10%) * Resizing of Firefox windows (tresize) is ~15% worse on Linux * Note: not all tests are compatible with e10s yet (e.g. session-restore performance test) so this list isn't complete Notable improvements from Telemetry data [3]: * Overall tab animation smoothness improved significantly: 50% vs 30% of tab animation frames are hitting the target 16ms inter-frame interval. See FX_TAB_ANIM_* graphs in [3] to see the distribution of frame intervals. Note that not all tab animations benefited equally. * e10s significantly decreased jank caused by GC CC, both in parent content processes (GC_MAX_PAUSE_MS, GC_SCC_SWEEP_MAX_PAUSE_MS, CYCLE_COLLECTOR_MAX_PAUSE, etc [3]) * Unlike Talos, Telemetry suggests that the time to open a new Firefox window improved with e10s (FX_NEW_WINDOW_MS) * Median time to restore a saved session improved by 40ms or 20% (simpleMeasurements/sessionRestored) * Median shutdown duration improved by 120ms or 10% (simpleMeasurements/shutdownDuration) Wait. What? Median shutdown duration is 1.2s ?!? ___ 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 W3C Manifest for web application
On Wed, Jul 15, 2015 at 4:12 AM, mar...@marcosc.com wrote: some people believe that web applications should be installable I don't subscribe to that theory. The web is comprised of pages, not apps. (I mostly agree with Alex, but not regarding the perceived need for app discoverability; I hear Google has a way to solve that problem.) ___ 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 Tue, Jul 14, 2015 at 9:17 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Tue, Jul 14, 2015 at 8:06 PM, Bobby Holley bobbyhol...@gmail.com wrote: I'm not wild about this idea. It's such a boil-the-ocean solution I honestly thought bsmedberg was joking at first... Well consistency is a major concern, so as long as the oceans are well and truly boiled... I'm certainly no fan of snake_case, but the literature does say it's more readable, and their data is better than my anecdotes. This Modest Proposal has my vote. ___ 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++)
The public source code for Firefox has existed for 17+ years (since ~April 1998). We can only assume it will be around for another 10+ years. I believe you have to take the long view on the cost benefit analysis and realize that a lot of pain in the short term (e.g. switching styles entirely) will be a fraction of the cost for tolerating inconsistent styles for years more. Yes, it will be painful to transition. But for software with a history measured in decades as opposed to months, being short-sighted will only burden us with various forms of debt in the years to come. On Tue, Jul 14, 2015 at 8:06 PM, Bobby Holley bobbyhol...@gmail.com wrote: I'm not wild about this idea. Switching styles entirely would be several times more churn and work than just making our existing codebase conform to our existing style guide. Consistency with Google's style might be a nice bonus, and there might be subjective arguments for one or the other, but none of that seems worth the churn and disruption this would cause, IMO. On Tue, Jul 14, 2015 at 11:23 AM, Benjamin Smedberg benja...@smedbergs.us wrote: On 7/8/2015 7:31 AM, Nathan Froyd wrote: If somebody is willing to do the formatting, I'm willing to do the review. I think the thread has reached the point of people repeating ad nauseum what was already said earlier in the thread, so it's time for a decision. Benjamin? Aww, I was avoiding getting into this thread. I personally have no strong preference, and our existing community is pretty deeply divided. I doubt we're going to come to consensus here, and this is a pretty tough decision to make on its own. I do believe that consistency trumps module/personal preference in terms of coding style. 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. 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 There is good research that underscore_names are more readable, and many of these will be more familiar to new contributors. Also we have a fair bit of shared code with Google. If there is a decision to be made here, I'd like to make this RFC: * switch our codebase wholesale to the Google C++ style guide With the following implementation plan: * For now, code should continue to be written in the current style with aFoo, mFoo, and camelCase. * get our code -Wshadow clean * Ask poiru to investigate auto-renaming of our variables including mFoo, aFoo, and camelCase to the google-standard local variable names. * Do not make any changes to the style guide or standard practice until we're comfortable that we can do automatic changes. * Make the automatic changes and change our style guide at roughly the same time. * Go back and deal with class names (nsFoo) as a separate/later pass. --BDS ___ 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 ___ 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 Thu, Jul 16, 2015 at 4:54 AM, Martin Thomson m...@mozilla.com wrote: On Wed, Jul 15, 2015 at 4:12 AM, mar...@marcosc.com wrote: some people believe that web applications should be installable I don't subscribe to that theory. The web is comprised of pages, not apps. (I mostly agree with Alex, but not regarding the perceived need for app discoverability; I hear Google has a way to solve that problem.) 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. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ 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 5:47 PM, Andrew Sutherland wrote: Would it be crazy for us to resort to a poll on these things? A poll will not be useful for informing this decision. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement HTMLMediaElement.srcObject partially
Hooray! Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ 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 Wed, Jul 15, 2015 at 2:26 PM, Gregory Szorc g...@mozilla.com wrote: The public source code for Firefox has existed for 17+ years (since ~April 1998). We can only assume it will be around for another 10+ years. I believe you have to take the long view on the cost benefit analysis and realize that a lot of pain in the short term (e.g. switching styles entirely) will be a fraction of the cost for tolerating inconsistent styles for years more. Yes, it will be painful to transition. But for software with a history measured in decades as opposed to months, being short-sighted will only burden us with various forms of debt in the years to come. There are two uses of consistency being thrown around. One is internal consistency within the project (with our style guide), the other is consistency with Google C++ style (and lack of consistency with other things, like JS). I don't believe at all that the lack of the latter is a burden or a debt that will hamper our ability to effectively evolve Gecko, and we can get the former much more cheaply. Why make it harder for ourselves? ___ 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++)
Would it be crazy for us to resort to a poll on these things? I propose abusing the mozillans.org skills field in profiles. For example, I have created the following sets of skills on mozillians.org by question, and which should autocomplete if you go to the edit page for your profile at https://mozillians.org/en-US/user/edit/ a prefixing of arguments: * style-args-no-a * style-args-yes-a * style-args-dont-care Switching wholesale to the google code style: * style-google-no * style-google-yes * style-google-dont-care My rationale is: * Everyone should have a mozillians.org account and if you don't and this provides the motivation... hooray! * This avoids vote stuffing, more or less * I guess someone could easily filter it down to valid committer accounts? * This requires no work on my part after this point. * The autocomplete logic should let people add other options if they're quick on their feet. Andrew ___ 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 Wednesday, July 15, 2015 at 3:34:42 PM UTC+10, Anne van Kesteren wrote: On Wed, Jul 15, 2015 at 12:00 AM, mar...@marcosc.com wrote: * It's not clear what problems manifest solves This is by far the biggest problem. I think we ended up with manifests because packages have manifests and iOS/Android use packages for applications, but none of that translates well to the web. * Extra HTTP request could yield a performance penalty (even if deprioritized)... though probably not a concern in a HTTP2 world. It's still a concern. You'll still need to duplicate all the metadata that the client needs immediately in the HTML. We were careful to not have any immediately required metadata in the manifest. The stuff in the manifest is only applied after the web application is installed to a user's device and the application is run from the home screen (see Chrome's implementation). One reason that was mentioned in favor of manifests was don't repeat yourself. The way the web has dealt with that for two decades is server-side templating. You might be forgetting, you know, link rel stylesheet and script src + anything that has a `src` attribute that relies on pulling stuff from the web and putting it into the browser cache so it can be applied across multiple pages. The idea with the manifest is the same: it is applied to a web application across multiple pages, like CSS, JS, etc. This is why it uses link rel and it is not inlined. I agree with Martin that focusing on concrete problems to solve is a more worthwhile endeavor. Agree. I want to do two concrete things immediately: 1. Enhance browser tiles: many sites have nice logos/icons, and they have an application-name. I want to show the application-name and icon or logo them in tiles in the new tab page. 2. Page previews suck today: they are mostly broken, don't show the right content, they are badly zoomed, and don't lead me to the right place. Be nice if developers could provide a link to a page I can render in a tile + a preferred start URL. As a developer, I want this tile to get updated using a push notification and I want it to work offline. Those are the concrete problems I, and others, care about solving. We can solve those with web manifest, but I'm all ears if you folks want to propose something else :) ___ 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 Wed, Jul 15, 2015 at 1:12 PM, mar...@marcosc.com wrote: Do we even agree on the above? I agree with some of it... But, I don't really see the point of trying to merge web and native (other than turning the browser into the OS). And I really don't see the point of trying to play by native's rules when doing so. As long as you talk about web and native as side-by-side, the web will lose since native is controlled by a single vendor. The way we compete is by making the web work better and playing to the strengths of the web. Playing to the strengths of native seems like a losing proposition. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship Service Worker Notification API
Yes, please! On 2015-07-14 3:22 PM, nsm.nik...@gmail.com wrote: Hello, Target release: Firefox 42 Implementation and shipping bug: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=1114554 Specification: https://notifications.spec.whatwg.org/#service-worker-api This is a follow up to the Notification API on worker support that landed in Firefox 41 [1]. These patches implement support for the `showNotification()` and `getNotifications()` methods on ServiceWorkerRegistration. The `Notification` constructor is available on ServiceWorkers but throws an error if actually used. Potential for abuse? This API allows service workers to show notifications to the user. This can happen even when a tab/window for the origin is not open in the browser. Service Workers can only run when the UA decides to run them and ideally only for a short time. If we notice abuse, we could restrict the ability to show notifications only to certain events (like push) and forbid them in others (like fetch events which occur several orders of magnitude more often), but we do not do that right now. Platforms: Available on all platforms. But Firefox for Android has limitations on its notification subsystem that prevents this from working. Support in other engines: Blink - shipped in Chrome 42/Opera 29- https://groups.google.com/a/chromium.org/d/topic/blink-dev/Cr7_GRSd2zM/discussion Webkit - not supported Edge/Trident: not supported Developer documentation: https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/showNotification [1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/CsM4I2Y9tS0 Best, Nikhil ___ 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
