Re: ICU proposing to drop support for WinXP (and OS X 10.6)
On Sun, May 1, 2016 at 6:54 AM, Henri Sivonenwrote: > > What bothers me the most regarding size of what we ship is > > * Failure to make the most out of compression (i.e. Zopfli) before > objecting to the addition of new things stuff. I've brought this up > before, but just now, I downloaded the (en-US API level 15) APK for > Fennec 46 and ran ImageOptim (https://imageoptim.com/mac) on the PNG > files included directly in the APK (i.e. not the one hidden inside > omni.ja). ImageOptim says: "Saved 311KB out of 1.7MB. 28.6% per file > on average (up to 94.3%)." (There wasn't a single already-optimal PNG > there!) Additionally, the same exercise could be repeated for images > in omni.ja. We do optimize images before they land in the tree, although we usually use pngcrush, and there may be some older assets that landed before we made this common practice. However, Sebastian ran an analysis recently and found that there's actually not much left to optimize (~35kb): https://bugzilla.mozilla.org/show_bug.cgi?id=1266156 What you may actually be seeing is the fact that AAPT's optimization tool may actually increase the size of optimized PNGs: https://bugzilla.mozilla.org/show_bug.cgi?id=1266156 > Then all the XML and JS could be Zopflified. The bundled > .ttf files could be turned into Brotli-compressed WOFF2 files. We recently landed a change to make fonts downloadable by default, so these aren't even included in our APK anymore: https://bugzilla.mozilla.org/show_bug.cgi?id=1194338 We also have a GSoC student this summer who's going to work on making more parts of the APK downloadable at runtime. On Mon, May 2, 2016 at 3:28 AM, Henri Sivonen wrote: > On Mon, May 2, 2016 at 2:37 AM, Jim Blandy wrote: > > What are the distributions of memory and flash sizes for the devices > people > > currently run Fennec on? It'll be almost impossible to have a good > > discussion about Fennec size without those numbers. I seem to remember > that > > is data we felt was okay to collect. > > We should also be data-driven about understanding where the bytes go. > In particular, I think functionality-neutral size reductions should be > done before blocking new functionality from landing. In addition to > unoptimally compressed PNGs, there's unminified JS in Fennec (i.e. the > JS comments are shipped). > We landed a change a while back to minify JS, and we verified this morning that all JS seems to be minified in components/chrome/toolkit: https://bugzilla.mozilla.org/show_bug.cgi?id=1039902 I think the Firefox for Android APK size issue merits its own discussion, outside the context of this ICU thread. I'd encourage anyone who's interested in helping out to take a look at the meta bug where we've been tracking our effort to reduce APK size: https://bugzilla.mozilla.org/show_bug.cgi?id=942609 There are a lot of ideas in there, but we haven't had time to explore fixing them all. Margaret ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Transitioning from FHR to Telemetry
For Android, we are planning to start sending key metrics in a mobile "core data" ping. We're designing the specifics of that ping here: https://docs.google.com/document/d/1Ap5Z48Rh4t1r5lKmDAVCHNWpLS4nJIG4abZmw0nQiq4/edit#heading=h.my2y0xqb6c91 We haven't started implementation work on this yet, so we're probably looking at landing code in Firefox 46, but hopefully we can uplift this. Here is the meta bug that we're using to more generally track this transition to unified telemetry: https://bugzilla.mozilla.org/show_bug.cgi?id=1220177 We've also discussed taking advantage of some more features of Adjust [1] to hold us over in the meantime, but we haven't committed to any decisions about that. Margaret [1] https://gecko.readthedocs.org/en/latest/mobile/android/base/fennec/adjust.html On Thu, Dec 3, 2015 at 11:20 AM, Hamilton Ulmerwrote: > Hello - > > Those responsible for Android-related FHR-based metrics are not aware of > the timeline for Android's transition, and I doubt we're prepared for that > transition at this point. It'd be great to know the timeline for this. The > bug linked to above does not include that information. > > ~ Hamilton > > ___ > mobile-firefox-dev mailing list > mobile-firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [feature] open certain domains into a private window
For Android, we have been discussing building a feature like this around tab queues (the new open later feature we've been working on), but I don't know of any desktop plans for something like this. I agree the UX/product work around this idea could be tricky, so I'm not sure dev-platform is the right place for this discussion. I would encourage you to talk to Javaun about new ideas for private browsing, since he's the product manager leading our private browsing 2.0 initiative. Margaret On Wed, Jun 24, 2015 at 4:31 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-06-23 8:57 PM, Andreas Tolfsen wrote: On 23 Jun 2015, at 20:24, Karl Dubost kdub...@mozilla.com wrote: Le 23 juin 2015 à 19:16, Eric Shepherd esheph...@mozilla.com a écrit : I thought we had an open in new private window option when right clicking links. Not a total solution but helps. My I'm reading an email with a link to Google Doc was assuming an email client (not webmail), could be IRC, or anything else outside of the browser. Is it an option to register two browser handlers in the operating system for Firefox? One for regular Firefox, and one for Firefox in private mode? We already have that, but that won't help for Karl's use case. The technical work involved in fixing what Karl is asking for is simple. The UX we want to expose the feature through is the more interesting question IMO. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fennec build unusable with own build
Hi Martijn, On Sat, Mar 30, 2013 at 7:41 AM, Martijn martijn.mart...@gmail.com wrote: I tried building Fennec for a patch that I made, but the build that came out of it seemed to be useless on the Galaxy Nexus phone. Fennec would start up all right, but I could not load anything in the browser. I built on MacOS X lion. I'm running OS X 10.8.2, and I've been building successfully for the Galaxy Nexus (and all other devices I've tested). My mozconfig looks basically like what you have, expect for the ndk version. My .mozconfig file: # Add the correct paths here: ac_add_options --with-android-ndk=$HOME/android-ndk-r8e I have ndk-r8c in my mozconfig (and that's what's listed on the wiki), so I think this may be your problem. ac_add_options --with-android-toolchain=$HOME/android-ndk-r8e/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_64 (And I don't think you need this line anymore) Best, Margaret ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: jsm source (mercurial )
Which jsm files are you looking for? You can browse the mozilla-central repo (and download individual files) on the web here: http://hg.mozilla.org/mozilla-central/ Margaret On Mon, Dec 31, 2012 at 9:59 AM, rvj r...@rolemodels.net wrote: do I need to install windows mercurial to download the jsm files .. or is there an alternative (simpler) method? __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform