Re: OS.File and shutdown
On 5/10/13 4:45 PM, Felipe Gomes wrote: Hi, does OS.File guarantees that write tasks that have started will be completed if a shutdown occurs? My use case is for writeAtomic but I'm interested about the behavior of both write and writeAtomic. Corner case: what if I call write/writeAtomic from an xpcom-shutdown observer? I'm not sure about the rest of this question. But you should not be performing any I/O after profile-before-change. See https://wiki.mozilla.org/XPCOM_Shutdown and note that after profile-before-change, we are working on immediately exiting the browser and skipping XPCOM shutdown. xpcom-shutdown is definitely too late! --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Rendering meeting, May 13, 2:30 PM US/Pacific
Hello, Ahead of the Taipei work week (in two weeks), the next Rendering meeting will take this Monday May 13 at 2:30 PM US/Pacific time. That could be Tuesday in your timezone. The Rendering meeting is about all things Gfx, Image, Layout, and Media. It is expected to take place roughly every second Monday. Please first add your agenda items there: https://wiki.mozilla.org/Platform/GFX/2013-May-13 * Every second Monday at 2:30 PM Pacific Time * +1 650 903 0800 x92 Conf# 99366 * +1 416 848 3114 x92 Conf# 99366 * +1 800 707 2533 (pin 369) Conf# 99366 (toll free, Skype) * Video (Vidyo) link: https://v.mozilla.com/flex.html?roomdirect.html&key=vu1FKlkBlT29 * Vidyo room 9366 (if you have LDAP and can log in at https://v.mozilla.com) See you, Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
OS.File and shutdown
Hi, does OS.File guarantees that write tasks that have started will be completed if a shutdown occurs? My use case is for writeAtomic but I'm interested about the behavior of both write and writeAtomic. Corner case: what if I call write/writeAtomic from an xpcom-shutdown observer? Another question: are the write tasks queued and completed in order, or can two writeAtomic calls to the same file race each other and the 2nd call finish first (only to have the 1st call finish and write older data) Thanks, Felipe ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: It's time to remove plugin support from Firefox mobile
On 5/10/13 1:54 PM, David Keeler wrote: [bcc'd to many lists for wide visibility - discussion should probably be on mobile.firefox.dev (https://mail.mozilla.org/listinfo/mobile-firefox-dev )] TL;DR: Now is a good time to remove plugin support from Firefox for Android. Consider: * We do not support plugins for Firefox OS and do not plan to * The only plugin that most users care about is Flash. Adobe stopped development for Flash on Android in November of 2011, which is a year and a half ago[1]. * Popular sites that use plugins have native apps. This includes YouTube, Netflix, Hulu, and so on. Other sites can follow suit or use modern web technologies like HTML5. Addons are also an option. * Plugins are a security hazard * Plugins drain battery life and make Firefox seem slow Let's be bold, let's protect our users, and let's move the web forward. [1] http://blogs.adobe.com/conversations/2011/11/flash-focus.html This was cross posted to the mobile-firefox-dev mailing list and conversation is happening there. https://mail.mozilla.org/listinfo/mobile-firefox-dev ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
It's time to remove plugin support from Firefox mobile
[bcc'd to many lists for wide visibility - discussion should probably be on mobile.firefox.dev (https://mail.mozilla.org/listinfo/mobile-firefox-dev )] TL;DR: Now is a good time to remove plugin support from Firefox for Android. Consider: * We do not support plugins for Firefox OS and do not plan to * The only plugin that most users care about is Flash. Adobe stopped development for Flash on Android in November of 2011, which is a year and a half ago[1]. * Popular sites that use plugins have native apps. This includes YouTube, Netflix, Hulu, and so on. Other sites can follow suit or use modern web technologies like HTML5. Addons are also an option. * Plugins are a security hazard * Plugins drain battery life and make Firefox seem slow Let's be bold, let's protect our users, and let's move the web forward. [1] http://blogs.adobe.com/conversations/2011/11/flash-focus.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Help with migrating to clang 3.3
On 2013-05-10 1:06 PM, Justin Lebar wrote: If we wanted to check out the RC from svn, is that trunk, or is it one of the branches? It's not really clear how the SVN repo is set up, or how to check out the right rev for llvm + clang. http://llvm.org/svn/llvm-project/llvm http://llvm.org/svn/llvm-project/cfe http://llvm.org/svn/llvm-project/llvm/branches/release_33 http://llvm.org/svn/llvm-project/cfe/branches/release_33 http://llvm.org/svn/llvm-project/compiler-rt/branches/release_33 But note that Rail has compiled clang 3.3 binaries which are available from tooltool on the try server, so if you want to test things on try you just need to use the manifests he has attached to the bug, and won't need to build your own compiler. Also the basic build with clang 3.3 works fine, I usually build with tip of tree clang locally. Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Help with migrating to clang 3.3
If we wanted to check out the RC from svn, is that trunk, or is it one of the branches? It's not really clear how the SVN repo is set up, or how to check out the right rev for llvm + clang. http://llvm.org/svn/llvm-project/llvm http://llvm.org/svn/llvm-project/cfe On Fri, May 10, 2013 at 12:51 PM, Ehsan Akhgari wrote: > Hi all, > > clang 3.3 is in RC stage right now, and it would be really great if we can > start testing it to ensure that we can migrate our Mac builds to 3.3. once > it's released, and also that clang 3.3 doesn't contain any regressions that > will prevent us from building Firefox with it. > > Rail has prepared the required manifests in bug 870173, but we currently > don't have anybody who can push it to try and look at test results and > performance numbers, etc. It would be great if somebody could volunteer to > do that. > > Please get in touch with me or Rail about this. > > Thanks! > Ehsan > ___ > 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
Help with migrating to clang 3.3
Hi all, clang 3.3 is in RC stage right now, and it would be really great if we can start testing it to ensure that we can migrate our Mac builds to 3.3. once it's released, and also that clang 3.3 doesn't contain any regressions that will prevent us from building Firefox with it. Rail has prepared the required manifests in bug 870173, but we currently don't have anybody who can push it to try and look at test results and performance numbers, etc. It would be great if somebody could volunteer to do that. Please get in touch with me or Rail about this. Thanks! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Error on startup when registering content policy from bootstrapped extension
On 5/10/13 10:55 AM, Matthew Gertner wrote: Apparently the constructor is being called before the docShell is there. I can't see why registering a category entry with type "content-policy" would cause this, however. From the code it looks like the entry just gets put into the list maintained by nsContentPolicy (it uses nsCategoryCache for this). The list is iterated in CheckPolicy. Why this would cause the to be instantiated prematurely is not clear to me. Is your policy being called with the subject set to the ? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Error on startup when registering content policy from bootstrapped extension
I'm registering a content policy (implemented in JavaScript) from the startup() function of my bootstrap.js. When I do so, I get an error in the Error Console: Timestamp: 5/10/13 4:50:56 PM Error: this.webNavigation is null Source File: chrome://global/content/bindings/browser.xml Line: 721 Apparently the constructor is being called before the docShell is there. I can't see why registering a category entry with type "content-policy" would cause this, however. From the code it looks like the entry just gets put into the list maintained by nsContentPolicy (it uses nsCategoryCache for this). The list is iterated in CheckPolicy. Why this would cause the to be instantiated prematurely is not clear to me. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
I'd even go as far as limiting it to 16kb. (possibly with a transition phase during which going above 16kb only prints warnings) On 5/10/13 12:47 AM, Robert Kaiser wrote: > FWIW, we had a pretty high-ranking topcrash in > https://bugzilla.mozilla.org/show_bug.cgi?id=836263 where an add-on > stored strings up to at least 128MB in prefs, and Nightly now limits > prefs to 1MB max, and that add-on switched to indexedDB instead. This > should happen more, for sure. I'd think that anything larger than a few > KB probably doesn't belong in a pref. > We couldn't easily set that limit mentioned above as low as we'd like > because up to now we had no limit at all and some add-ons definitely > store large stuff in prefs. Given that we probably read prefs in startup > and before we can do anything useful with the launched Firefox, I wonder > how much of a perf problem those large prefs tend to be, actually. > > Robert Kaiser > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
