Re: Moratorium on new XUL features

[Yonggang Luo]

在 2014年10月14日星期二UTC+8下午8时29分04秒，Boris Zbarsky写道：
> On 10/13/14, 11:28 PM, Yonggang Luo wrote:
> 
> > If the XUL is truly dead, then mozilla community should consider to remove 
> > it totally from the codebase
> 
> 
> 
> Working on it.  It's a big project.  ;)
Well, indeed, i've seen so much simulated tree in HTML, it's totally slow and 
not performance good, and do not support for big data(1000,000+) indeed. So if 
mozilla community are working on it, there should be some equivalent for tree 
in HTML.
> 
> 
> 
> -Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

WARNING: bugzilla "review granted" emails no longer contain review comments

[L. David Baron]

There is a regression in bugzilla.mozilla.org such that "review
granted", "feedback granted", etc., emails no longer contain the
comments made when granting the review.

This bug is tracked in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1082887

Until this bug is fixed, if you get a "review granted" email with no
comments in it, you need to look at the bug to see what the comments
were, rather than assuming review was granted with no comments.

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Mike Hoye]

On 2014-10-14 10:14 PM, Ehsan Akhgari wrote:

On 2014-10-14, 10:09 PM, Mike Hommey wrote:


I'm not saying we shouldn't strive for better, but I'm questioning 
the fact

that download size would be affecting our growth. If the download size
of our competitors is not affecting theirs, why would it affect ours?
(and again, the premise is an interrogation)
That's a fair objection. One possible explanation for that would be 
the hypothesis that they have more directly focused on markets where 
broadband Internet is prevalent through, let's say TV ads in the case 
of Chrome.  Of course I don't know whether that's true, but I don't 
think we can necessarily assume a similar growth impact potential here 
for different browsers.
For whatever it's worth I think we're conflating bits-on-the-disk with 
bits-on-the-wire here, which isn't necessarily the how things need to work.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Breakdown of Firefox full installer

[Robert Strong]

- Original Message -
> From: "Mike Hommey" 
> To: "Ehsan Akhgari" 
> Cc: "Chris More" , dev-platform@lists.mozilla.org, "Daniel 
> Veditz" 
> Sent: Tuesday, October 14, 2014 7:09:30 PM
> Subject: Re: Breakdown of Firefox full installer
> 
> On Tue, Oct 14, 2014 at 09:03:30PM -0400, Ehsan Akhgari wrote:
> > On 2014-10-14, 6:53 PM, Mike Hommey wrote:
> > >On Tue, Oct 14, 2014 at 11:11:01AM -0700, Chris More wrote:
> > >>Very interesting. When Firefox 4 was launched, it was 12MB. When
> > >>Australis was launched it was 28MB. Now, Firefox 33 is 35MB. That's
> > >>almost a 200% increase. I did an A/B test last year when the installer
> > >>was 22MB and there was a strong correlation between average internet
> > >>speed in a specific region of the world and install-rate of Firefox.
> > >>If world-wide internet speeds are not increasing faster than the
> > >>growth of the installer, it could be having a negative impact on
> > >>adoption of the product. By how much? No one is for sure as the A/B
> > >>test was just testing the current size of Firefox and one 3MB bigger.
> > >>The conclusion of the test was that 22mB vs 25MB didn't have a
> > >>statistical difference in conversion rate, but now a year later, we
> > >>are more than 10MB bigger.
> > >>
> > >>It looks like everyone provided helpful information and this is a
> > >>great start. I am going to work on creating a document to help to
> > >>quantify what are the drivers in the growth of the installer. After
> > >>that we can decide what does this tell us and if the growth of the
> > >>installer has negative impacts.
> > >
> > >On the other hand, what is the download size of the downloadable
> > >alternatives to Firefox? What is their adoption in regions with poor
> > >internet speeds? If the answer to both those questions is "bigger",
> > >(which I genuinely don't know if it is) there is nothing wrong with
> > >our download size.
> > 
> > Coming from a country with typically slow Internet connections, I strongly
> > disagree.  We should absolutely strive to be better than the competition by
> > providing a smaller download size.  Only matching the competition should be
> > the minimum bar. :)
> 
> I'm not saying we shouldn't strive for better, but I'm questioning the fact
> that download size would be affecting our growth. If the download size
> of our competitors is not affecting theirs, why would it affect ours?
> (and again, the premise is an interrogation)
Also agreed. The study with the 3 MB increase shows that it didn't 
significantly affect conversions. I personally think it would be better to 
allocate resources to make the stub installer download phase more resilient for 
the poor network connectivity case though resourcing this work is not possible 
from my end with the other work currently going on.

It would also be a good thing to fully understand and show why there is such a 
dramatic difference between the entire conversion process (~70%) vs. the stub 
installer process (~90%). As I understand it a large portion is due to bots 
repeatedly downloading the full installer without ever performing an install 
and the first run page not being shown under certain conditions though I 
wouldn't be surprised at all if there were several others. I've repeatedly 
asked for this and asked that when that number is presented to people that 
caveat is included since it is consistently assumed that if we just changed the 
stub installer we could improve the install process conversion rate by an 
amount that isn't even available to the stub installer.

Robert
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Ehsan Akhgari]

On 2014-10-14, 10:09 PM, Mike Hommey wrote:

On Tue, Oct 14, 2014 at 09:03:30PM -0400, Ehsan Akhgari wrote:

On 2014-10-14, 6:53 PM, Mike Hommey wrote:

On Tue, Oct 14, 2014 at 11:11:01AM -0700, Chris More wrote:

Very interesting. When Firefox 4 was launched, it was 12MB. When
Australis was launched it was 28MB. Now, Firefox 33 is 35MB. That's
almost a 200% increase. I did an A/B test last year when the installer
was 22MB and there was a strong correlation between average internet
speed in a specific region of the world and install-rate of Firefox.
If world-wide internet speeds are not increasing faster than the
growth of the installer, it could be having a negative impact on
adoption of the product. By how much? No one is for sure as the A/B
test was just testing the current size of Firefox and one 3MB bigger.
The conclusion of the test was that 22mB vs 25MB didn't have a
statistical difference in conversion rate, but now a year later, we
are more than 10MB bigger.

It looks like everyone provided helpful information and this is a
great start. I am going to work on creating a document to help to
quantify what are the drivers in the growth of the installer. After
that we can decide what does this tell us and if the growth of the
installer has negative impacts.


On the other hand, what is the download size of the downloadable
alternatives to Firefox? What is their adoption in regions with poor
internet speeds? If the answer to both those questions is "bigger",
(which I genuinely don't know if it is) there is nothing wrong with
our download size.


Coming from a country with typically slow Internet connections, I strongly
disagree.  We should absolutely strive to be better than the competition by
providing a smaller download size.  Only matching the competition should be
the minimum bar. :)


I'm not saying we shouldn't strive for better, but I'm questioning the fact
that download size would be affecting our growth. If the download size
of our competitors is not affecting theirs, why would it affect ours?
(and again, the premise is an interrogation)


That's a fair objection. One possible explanation for that would be the 
hypothesis that they have more directly focused on markets where 
broadband Internet is prevalent through, let's say TV ads in the case of 
Chrome.  Of course I don't know whether that's true, but I don't think 
we can necessarily assume a similar growth impact potential here for 
different browsers.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Mike Hommey]

On Tue, Oct 14, 2014 at 09:03:30PM -0400, Ehsan Akhgari wrote:
> On 2014-10-14, 6:53 PM, Mike Hommey wrote:
> >On Tue, Oct 14, 2014 at 11:11:01AM -0700, Chris More wrote:
> >>Very interesting. When Firefox 4 was launched, it was 12MB. When
> >>Australis was launched it was 28MB. Now, Firefox 33 is 35MB. That's
> >>almost a 200% increase. I did an A/B test last year when the installer
> >>was 22MB and there was a strong correlation between average internet
> >>speed in a specific region of the world and install-rate of Firefox.
> >>If world-wide internet speeds are not increasing faster than the
> >>growth of the installer, it could be having a negative impact on
> >>adoption of the product. By how much? No one is for sure as the A/B
> >>test was just testing the current size of Firefox and one 3MB bigger.
> >>The conclusion of the test was that 22mB vs 25MB didn't have a
> >>statistical difference in conversion rate, but now a year later, we
> >>are more than 10MB bigger.
> >>
> >>It looks like everyone provided helpful information and this is a
> >>great start. I am going to work on creating a document to help to
> >>quantify what are the drivers in the growth of the installer. After
> >>that we can decide what does this tell us and if the growth of the
> >>installer has negative impacts.
> >
> >On the other hand, what is the download size of the downloadable
> >alternatives to Firefox? What is their adoption in regions with poor
> >internet speeds? If the answer to both those questions is "bigger",
> >(which I genuinely don't know if it is) there is nothing wrong with
> >our download size.
> 
> Coming from a country with typically slow Internet connections, I strongly
> disagree.  We should absolutely strive to be better than the competition by
> providing a smaller download size.  Only matching the competition should be
> the minimum bar. :)

I'm not saying we shouldn't strive for better, but I'm questioning the fact
that download size would be affecting our growth. If the download size
of our competitors is not affecting theirs, why would it affect ours?
(and again, the premise is an interrogation)

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Robert Strong]

Agreed. We should always strive to do the best that we possibly can and focus 
our efforts on the areas with the greatest impact.

- Original Message -
> From: "Ehsan Akhgari" 
> To: "Mike Hommey" , "Chris More" 
> Cc: dev-platform@lists.mozilla.org, "Daniel Veditz" 
> Sent: Tuesday, October 14, 2014 6:03:30 PM
> Subject: Re: Breakdown of Firefox full installer
> 
> On 2014-10-14, 6:53 PM, Mike Hommey wrote:
> > On Tue, Oct 14, 2014 at 11:11:01AM -0700, Chris More wrote:
> >> Very interesting. When Firefox 4 was launched, it was 12MB. When
> >> Australis was launched it was 28MB. Now, Firefox 33 is 35MB. That's
> >> almost a 200% increase. I did an A/B test last year when the installer
> >> was 22MB and there was a strong correlation between average internet
> >> speed in a specific region of the world and install-rate of Firefox.
> >> If world-wide internet speeds are not increasing faster than the
> >> growth of the installer, it could be having a negative impact on
> >> adoption of the product. By how much? No one is for sure as the A/B
> >> test was just testing the current size of Firefox and one 3MB bigger.
> >> The conclusion of the test was that 22mB vs 25MB didn't have a
> >> statistical difference in conversion rate, but now a year later, we
> >> are more than 10MB bigger.
> >>
> >> It looks like everyone provided helpful information and this is a
> >> great start. I am going to work on creating a document to help to
> >> quantify what are the drivers in the growth of the installer. After
> >> that we can decide what does this tell us and if the growth of the
> >> installer has negative impacts.
> >
> > On the other hand, what is the download size of the downloadable
> > alternatives to Firefox? What is their adoption in regions with poor
> > internet speeds? If the answer to both those questions is "bigger",
> > (which I genuinely don't know if it is) there is nothing wrong with
> > our download size.
> 
> Coming from a country with typically slow Internet connections, I
> strongly disagree.  We should absolutely strive to be better than the
> competition by providing a smaller download size.  Only matching the
> competition should be the minimum bar. :)
> ___
> 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: Breakdown of Firefox full installer

[Ehsan Akhgari]

On 2014-10-14, 6:53 PM, Mike Hommey wrote:

On Tue, Oct 14, 2014 at 11:11:01AM -0700, Chris More wrote:

Very interesting. When Firefox 4 was launched, it was 12MB. When
Australis was launched it was 28MB. Now, Firefox 33 is 35MB. That's
almost a 200% increase. I did an A/B test last year when the installer
was 22MB and there was a strong correlation between average internet
speed in a specific region of the world and install-rate of Firefox.
If world-wide internet speeds are not increasing faster than the
growth of the installer, it could be having a negative impact on
adoption of the product. By how much? No one is for sure as the A/B
test was just testing the current size of Firefox and one 3MB bigger.
The conclusion of the test was that 22mB vs 25MB didn't have a
statistical difference in conversion rate, but now a year later, we
are more than 10MB bigger.

It looks like everyone provided helpful information and this is a
great start. I am going to work on creating a document to help to
quantify what are the drivers in the growth of the installer. After
that we can decide what does this tell us and if the growth of the
installer has negative impacts.


On the other hand, what is the download size of the downloadable
alternatives to Firefox? What is their adoption in regions with poor
internet speeds? If the answer to both those questions is "bigger",
(which I genuinely don't know if it is) there is nothing wrong with
our download size.


Coming from a country with typically slow Internet connections, I 
strongly disagree.  We should absolutely strive to be better than the 
competition by providing a smaller download size.  Only matching the 
competition should be the minimum bar. :)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Ehsan Akhgari]

On 2014-10-14, 7:25 PM, Chris More wrote:

Great question and we've discussed the same thing last year. Last year, Chrome 
was about the same size if not slightly bigger and that looks to be the same 
case now. It is still worthwhile to understand about our installer size, the 
driver of growth each release, and if there is any impact.

Chrome full installer is currently 40MB on Windows:

https://dl.google.com/update2/installers/ChromeStandaloneSetup.exe

It is not as easy to look at their growth because I cannot find any FTP 
directories or other websites that have their installer sizes over time.


You can find them here for Chromium: 



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Robert Strong]

Another example, if the omni.jar is not compressed the installer can compress 
it about as well as if they were individual files and the minimal compression 
currently used by omni.jar makes it so the installer is not able to compress 
the omni.jar nearly as well which increases the installer size.

Robert

- Original Message -
> From: "Gregory Szorc" 
> To: "Neil" , dev-platform@lists.mozilla.org
> Sent: Tuesday, October 14, 2014 5:31:54 PM
> Subject: Re: Breakdown of Firefox full installer
> 
> On 10/14/14 5:12 PM, Neil wrote:
> > Gregory Szorc wrote:
> >
> >> If you are looking for ideas on how to reduce download size, the way
> >> omni.ja is included in the installer could be reduced by 4+ MB. Both
> >> omni.ja and browser/omni.ja are zip archives, where each file has a
> >> separate compression context. If you treat all files from those two
> >> archives as a single compression context (like tar+bz2) and stuff them
> >> in a single archive, you get size reductions of 4+ MB due to the
> >> compression engine sharing state between files. We can't install
> >> omni.ja like this on client systems because it is bad for performance
> >> (we want the ability to extract individual files without reading a
> >> large compression context - this is a benefit of the zip format). But
> >> we could ship the files optimized for size (or have installer's
> >> compression handle the files individually) and have the installer
> >> re-encode them to omni.ja so they are optimized for performance.
> >
> > I'm not sure what you're trying to say here. As far as I can see what
> > you're suggesting is using some RAR-like rather than ZIP-like format for
> > the installer. Why would the way you're compressing the two omni.ja
> > files into the installer affect the installed omni.ja files?
> 
> The more data you throw into the compression engine, the greater the
> chances there will be redundant data and you won't have duplicate
> representations of that data inside the compressed result. There's a lot
> of data inside both omni.ja and it turns out that many forms of
> compression will find those duplicate patterns and prevent the redundancy.
> 
> Also, we're not talking about changing omni.ja as it exists in the
> installed application: only how data within omni.ja is "packaged" and
> shipped in the installer. Discussions on whether omni.ja should be e.g.
> lzma or laid out differently on disk are orthogonal but still important
> to have (because they impact performance, especially start times).
> ___
> 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: Breakdown of Firefox full installer

[Gregory Szorc]

On 10/14/14 5:12 PM, Neil wrote:

Gregory Szorc wrote:


If you are looking for ideas on how to reduce download size, the way
omni.ja is included in the installer could be reduced by 4+ MB. Both
omni.ja and browser/omni.ja are zip archives, where each file has a
separate compression context. If you treat all files from those two
archives as a single compression context (like tar+bz2) and stuff them
in a single archive, you get size reductions of 4+ MB due to the
compression engine sharing state between files. We can't install
omni.ja like this on client systems because it is bad for performance
(we want the ability to extract individual files without reading a
large compression context - this is a benefit of the zip format). But
we could ship the files optimized for size (or have installer's
compression handle the files individually) and have the installer
re-encode them to omni.ja so they are optimized for performance.


I'm not sure what you're trying to say here. As far as I can see what
you're suggesting is using some RAR-like rather than ZIP-like format for
the installer. Why would the way you're compressing the two omni.ja
files into the installer affect the installed omni.ja files?


The more data you throw into the compression engine, the greater the 
chances there will be redundant data and you won't have duplicate 
representations of that data inside the compressed result. There's a lot 
of data inside both omni.ja and it turns out that many forms of 
compression will find those duplicate patterns and prevent the redundancy.


Also, we're not talking about changing omni.ja as it exists in the 
installed application: only how data within omni.ja is "packaged" and 
shipped in the installer. Discussions on whether omni.ja should be e.g. 
lzma or laid out differently on disk are orthogonal but still important 
to have (because they impact performance, especially start times).

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Robert Strong]

I found my previous analysis of the stub installer:
Stub installs without a Firefox profile and not installing on top of an 
existing install (e.g. new installs) have a 90.32% success rate for Firefox 30 
during the first 2 weeks starting the Friday after release.

Robert

- Original Message -
> From: "Justin Dolske" 
> To: dev-platform@lists.mozilla.org
> Sent: Tuesday, October 14, 2014 12:34:53 PM
> Subject: Re: Breakdown of Firefox full installer
> 
> On 10/14/14 2:20 AM, Robert Strong wrote:
> 
> >> * (Countries' average) Internet speed dramatically affected conversion
> >> rates: 70% success in the fastest countries and 30% in the slowest
> > countries.
> > Note that these conversion rates are from download to hitting the first
> > run page and there are several factors that dramatically lower the
> > conversion rate outside of the actual stub installer portion of the
> > process. When just measuring the conversion rate from clicking install in
> > the stub installer the conversion rate is actually close to 90%.
> 
> Interesting; this is what I was asking about in my other post.
> 
> If we're getting ~90% conversion in the stub installer, that implies
> download size improvements may have little effect. A max of the missing
> 10%, and presumably some portion of that is due to other factors.
> 
> Justin
> ___
> 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: Breakdown of Firefox full installer

[Neil]

Gregory Szorc wrote:

If you are looking for ideas on how to reduce download size, the way 
omni.ja is included in the installer could be reduced by 4+ MB. Both 
omni.ja and browser/omni.ja are zip archives, where each file has a 
separate compression context. If you treat all files from those two 
archives as a single compression context (like tar+bz2) and stuff them 
in a single archive, you get size reductions of 4+ MB due to the 
compression engine sharing state between files. We can't install 
omni.ja like this on client systems because it is bad for performance 
(we want the ability to extract individual files without reading a 
large compression context - this is a benefit of the zip format). But 
we could ship the files optimized for size (or have installer's 
compression handle the files individually) and have the installer 
re-encode them to omni.ja so they are optimized for performance.


I'm not sure what you're trying to say here. As far as I can see what 
you're suggesting is using some RAR-like rather than ZIP-like format for 
the installer. Why would the way you're compressing the two omni.ja 
files into the installer affect the installed omni.ja files?


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Chris More]

Also, it may be "challenging" to contact the Chrome team and ask them for their 
conversion rates to install by country, but I would imagine they are probably 
facing similar challenges. They may also have other methods of distribution to 
get around the constraints or have enough marketing $$ to offsets organic 
growth in emerging markets.

If anyone does have any non-Firefox information to share, it would be helpful. 
This is probably a challenge with any kind of download, browser or not.

Chris

- Original Message -
From: "Mike Hommey" 
To: "Chris More" 
Cc: "Daniel Veditz" , dev-platform@lists.mozilla.org
Sent: Tuesday, October 14, 2014 3:53:34 PM
Subject: Re: Breakdown of Firefox full installer

On Tue, Oct 14, 2014 at 11:11:01AM -0700, Chris More wrote:
> Very interesting. When Firefox 4 was launched, it was 12MB. When
> Australis was launched it was 28MB. Now, Firefox 33 is 35MB. That's
> almost a 200% increase. I did an A/B test last year when the installer
> was 22MB and there was a strong correlation between average internet
> speed in a specific region of the world and install-rate of Firefox.
> If world-wide internet speeds are not increasing faster than the
> growth of the installer, it could be having a negative impact on
> adoption of the product. By how much? No one is for sure as the A/B
> test was just testing the current size of Firefox and one 3MB bigger.
> The conclusion of the test was that 22mB vs 25MB didn't have a
> statistical difference in conversion rate, but now a year later, we
> are more than 10MB bigger. 
> 
> It looks like everyone provided helpful information and this is a
> great start. I am going to work on creating a document to help to
> quantify what are the drivers in the growth of the installer. After
> that we can decide what does this tell us and if the growth of the
> installer has negative impacts.

On the other hand, what is the download size of the downloadable
alternatives to Firefox? What is their adoption in regions with poor
internet speeds? If the answer to both those questions is "bigger",
(which I genuinely don't know if it is) there is nothing wrong with
our download size.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Chris More]

Great question and we've discussed the same thing last year. Last year, Chrome 
was about the same size if not slightly bigger and that looks to be the same 
case now. It is still worthwhile to understand about our installer size, the 
driver of growth each release, and if there is any impact.

Chrome full installer is currently 40MB on Windows:

https://dl.google.com/update2/installers/ChromeStandaloneSetup.exe

It is not as easy to look at their growth because I cannot find any FTP 
directories or other websites that have their installer sizes over time.

Chris

- Original Message -
From: "Mike Hommey" 
To: "Chris More" 
Cc: "Daniel Veditz" , dev-platform@lists.mozilla.org
Sent: Tuesday, October 14, 2014 3:53:34 PM
Subject: Re: Breakdown of Firefox full installer

On Tue, Oct 14, 2014 at 11:11:01AM -0700, Chris More wrote:
> Very interesting. When Firefox 4 was launched, it was 12MB. When
> Australis was launched it was 28MB. Now, Firefox 33 is 35MB. That's
> almost a 200% increase. I did an A/B test last year when the installer
> was 22MB and there was a strong correlation between average internet
> speed in a specific region of the world and install-rate of Firefox.
> If world-wide internet speeds are not increasing faster than the
> growth of the installer, it could be having a negative impact on
> adoption of the product. By how much? No one is for sure as the A/B
> test was just testing the current size of Firefox and one 3MB bigger.
> The conclusion of the test was that 22mB vs 25MB didn't have a
> statistical difference in conversion rate, but now a year later, we
> are more than 10MB bigger. 
> 
> It looks like everyone provided helpful information and this is a
> great start. I am going to work on creating a document to help to
> quantify what are the drivers in the growth of the installer. After
> that we can decide what does this tell us and if the growth of the
> installer has negative impacts.

On the other hand, what is the download size of the downloadable
alternatives to Firefox? What is their adoption in regions with poor
internet speeds? If the answer to both those questions is "bigger",
(which I genuinely don't know if it is) there is nothing wrong with
our download size.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Mike Hommey]

On Tue, Oct 14, 2014 at 11:11:01AM -0700, Chris More wrote:
> Very interesting. When Firefox 4 was launched, it was 12MB. When
> Australis was launched it was 28MB. Now, Firefox 33 is 35MB. That's
> almost a 200% increase. I did an A/B test last year when the installer
> was 22MB and there was a strong correlation between average internet
> speed in a specific region of the world and install-rate of Firefox.
> If world-wide internet speeds are not increasing faster than the
> growth of the installer, it could be having a negative impact on
> adoption of the product. By how much? No one is for sure as the A/B
> test was just testing the current size of Firefox and one 3MB bigger.
> The conclusion of the test was that 22mB vs 25MB didn't have a
> statistical difference in conversion rate, but now a year later, we
> are more than 10MB bigger. 
> 
> It looks like everyone provided helpful information and this is a
> great start. I am going to work on creating a document to help to
> quantify what are the drivers in the growth of the installer. After
> that we can decide what does this tell us and if the growth of the
> installer has negative impacts.

On the other hand, what is the download size of the downloadable
alternatives to Firefox? What is their adoption in regions with poor
internet speeds? If the answer to both those questions is "bigger",
(which I genuinely don't know if it is) there is nothing wrong with
our download size.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing ancient and unused code from tools/

[Nicholas Nethercote]

On Sun, Oct 12, 2014 at 9:36 PM, Nicholas Nethercote
 wrote:
>
> - tools/performance/pageload -- is this Talos(tp)? Bug 342089 added this.
> - tools/performance/startup -- has seen various more changes than all the
>to-be-removed stuff above; philor removed a
>chunk of it in bug 591717, and sfink removed
>another chunk in bug 579571

jmaher says we don't need either of these directories, and bug 1082554
is now tracking their removal.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moratorium on new XUL features

[Joshua Cranmer 🐧]

On 10/14/2014 5:12 PM, Robert O'Callahan wrote:

On Tue, Oct 14, 2014 at 4:56 PM, Joshua Cranmer 🐧 
wrote:


 From another point of view: Mozilla, for over a decade, provided a
relatively featureful toolkit for building UIs known as XUL. If the
argument is that we should be using HTML instead of XUL, then wouldn't it
make sense to provide an at-least-as-featureful HTML toolkit to make
migration easy and relatively painless?


I already said I'm not proposing a wholesale migration here. Please stop
misconstruing me.


Nor am I proposing a wholesale migration.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moratorium on new XUL features

[Robert O'Callahan]

On Tue, Oct 14, 2014 at 4:56 PM, Joshua Cranmer 🐧 
wrote:

> From another point of view: Mozilla, for over a decade, provided a
> relatively featureful toolkit for building UIs known as XUL. If the
> argument is that we should be using HTML instead of XUL, then wouldn't it
> make sense to provide an at-least-as-featureful HTML toolkit to make
> migration easy and relatively painless?


I already said I'm not proposing a wholesale migration here. Please stop
misconstruing me.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Justin Dolske]

On 10/14/14 2:20 AM, Robert Strong wrote:


* (Countries' average) Internet speed dramatically affected conversion
rates: 70% success in the fastest countries and 30% in the slowest

countries.
Note that these conversion rates are from download to hitting the first
run page and there are several factors that dramatically lower the
conversion rate outside of the actual stub installer portion of the
process. When just measuring the conversion rate from clicking install in
the stub installer the conversion rate is actually close to 90%.


Interesting; this is what I was asking about in my other post.

If we're getting ~90% conversion in the stub installer, that implies 
download size improvements may have little effect. A max of the missing 
10%, and presumably some portion of that is due to other factors.


Justin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposed W3C Charter: Scalable Vector Graphics (SVG) Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Scalable Vector Graphics (SVG) Working Group
  http://www.w3.org/Graphics/SVG/2014/charter
  http://lists.w3.org/Archives/Public/public-new-work/2014Sep/0010.html

Mozilla has the opportunity to send comments or objections through
next Monday, October 20.

Mozilla is involved in this working group (see membership at
https://www.w3.org/2000/09/dbwg/details?group=19480&public=1&order=org )
and I currently intend to support the charter.

Please reply to this thread if you think there's something else we
should say.

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Chris More]

Very interesting. When Firefox 4 was launched, it was 12MB. When Australis was 
launched it was 28MB. Now, Firefox 33 is 35MB. That's almost a 200% increase. I 
did an A/B test last year when the installer was 22MB and there was a strong 
correlation between average internet speed in a specific region of the world 
and install-rate of Firefox. If world-wide internet speeds are not increasing 
faster than the growth of the installer, it could be having a negative impact 
on adoption of the product. By how much? No one is for sure as the A/B test was 
just testing the current size of Firefox and one 3MB bigger. The conclusion of 
the test was that 22mB vs 25MB didn't have a statistical difference in 
conversion rate, but now a year later, we are more than 10MB bigger. 

It looks like everyone provided helpful information and this is a great start. 
I am going to work on creating a document to help to quantify what are the 
drivers in the growth of the installer. After that we can decide what does this 
tell us and if the growth of the installer has negative impacts.

Thanks everyone!
Chris

- Original Message -
From: "Daniel Veditz" 
To: "Chris More" , dev-platform@lists.mozilla.org
Sent: Tuesday, October 14, 2014 9:27:52 AM
Subject: Re: Breakdown of Firefox full installer

On 10/13/2014 4:54 PM, Chris More wrote:
> For example, the win32 installer for Firefox 32 is 34MB.

Remember the days when Asa would jump all over people for breaking the
5Mb barrier? https://wiki.mozilla.org/Download_Size

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GGC not enabled in XULRunner

[Kyle Huey]

Anybody has the right to submit patches.  Try producing a patch and
asking ":terrence" for review.

- Kyle

On Tue, Oct 14, 2014 at 9:14 AM,   wrote:
> The confvars.sh in XULrunner doesn't have JSGC_GENERATIONAL enabled.  As a 
> result, XULrunner doesn't have GGC enabled although the code has been there 
> since v31.
>
> I've filed a bug in bugzila 
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1063911) bug but haven't got 
> any feedback so far.  Can someone with the rights to submit patches help 
> rectify this?
>
> Thanks
> ___
> 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: Breakdown of Firefox full installer

[Daniel Veditz]

On 10/13/2014 4:54 PM, Chris More wrote:
> For example, the win32 installer for Firefox 32 is 34MB.

Remember the days when Asa would jump all over people for breaking the
5Mb barrier? https://wiki.mozilla.org/Download_Size

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Daniel Veditz]

On 10/13/2014 9:25 PM, Chris Peterson wrote:
> Going forward, it would be interesting to see a dashboard track Firefox
> installer size every day (or show every changeset's delta on Treeherder).

We used to have http://arewesmallyet.com -- I found references to it as
late as a year ago but it seems to be someone else now. I think this is
the code for it: https://github.com/ttaubert/arewesmallyet.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tool for generation of regression-range links

[Robert Helmer]

On Tue, Oct 14, 2014 at 8:48 AM, Gregory Szorc  wrote:
> On 10/13/14 12:17 PM, Benjamin Smedberg wrote:
>>
>> tl;dr: I have a tool for generating regression-range links from
>> buildids. http://bsmedberg.github.io/firefox-regression-range-finder/
>>
>> Often times when we're investigating regressions (crashes, etc), we have
>> the build ID of the nightly where the regression started. But it's not
>> the easiest thing in the world to turn that into an actual pushlog link
>> which lists the commits in the regression range.
>>
>> To help fix this, I've created a tool that lets you paste in a buildid
>> or two and automatically figures out the proper regression range link,
>> and also links you to the nightly build directories.
>>
>> This tool is pretty hacky: it loads http://ftp.mozilla.org directory
>> listings to find builds, and then loads the .txt files describing the
>> revisions involved. If we ever changed webserver for ftp.mozilla.org the
>> tool would likely break. But since it's something I do at least once a
>> week and I know other QA people do this even more regularly, I figured
>> it was worth automating.
>>
>> Right now the tool uses ES6 features `let` and `for...of` and so it only
>> works in Firefox and not in Chrome. I figured for this audience that
>> wouldn't be a problem.
>
>
> FWIW, Robert Helmer wrote a tool for scraping the FTP server, storing the
> relevant bits in a database, and exposing the result via HTTP+JSON. It used
> to run on Mozilla's Stackato deployment, but he turned off his instance for
> reasons I can't recall. The service was really useful: someone should look
> into deploying this again.
>
> https://github.com/rhelmer/releases-api/


The code for this was pulled out of Socorro and modified to run as a
standalone service, the reasons I decided not to go forward at that
time were:

1) the code in Socorro was undergoing big changes and it was hard to
keep in sync
2) I'd rather work with releng to expose this in a more direct way

My plan at the time was to move Socorro over to using this service too
(so point 1 would be moot) but I didn't have time to pull it off right
then.

I am ambivalent about the second point, we could probably put up a
REST API that scrapes FTP now and change the way it works internally
later without breaking the API.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

GGC not enabled in XULRunner

[allencblee]

The confvars.sh in XULrunner doesn't have JSGC_GENERATIONAL enabled.  As a 
result, XULrunner doesn't have GGC enabled although the code has been there 
since v31.

I've filed a bug in bugzila 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1063911) bug but haven't got any 
feedback so far.  Can someone with the rights to submit patches help rectify 
this?

Thanks
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Test Informant Report - Week of 2014-10-05

[Andrew Halberstadt]

On 14/10/14 11:58 AM, Bill McCloskey wrote:

On Tue, Oct 14, 2014 at 8:45 AM, Dave Townsend  wrote:

Is there any way to see the breakdown of which testsgot enabled. I'm
surprised to see mochitest-plain rise by 3456 yet mochitest-plain-e10s rise
by only 28. I'd love to find out which tests got turned on on one but not
the other.


If you go to the full report link in the original email, you can click
on each line to get deltas. The 3456 enabled mochitest-plain tests
look like mostly Android tests.

-Bill


Yep, we just started collecting data for Android last week, so in the 
eyes of the test-informant every android mochitest was "added". The fact 
that this shows up in the summary is a bug that I should probably fix..


Andrew


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Test Informant Report - Week of 2014-10-05

[Bill McCloskey]

On Tue, Oct 14, 2014 at 8:45 AM, Dave Townsend  wrote:
> Is there any way to see the breakdown of which testsgot enabled. I'm
> surprised to see mochitest-plain rise by 3456 yet mochitest-plain-e10s rise
> by only 28. I'd love to find out which tests got turned on on one but not
> the other.

If you go to the full report link in the original email, you can click
on each line to get deltas. The 3456 enabled mochitest-plain tests
look like mostly Android tests.

-Bill
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tool for generation of regression-range links

[Gregory Szorc]

On 10/13/14 12:17 PM, Benjamin Smedberg wrote:

tl;dr: I have a tool for generating regression-range links from
buildids. http://bsmedberg.github.io/firefox-regression-range-finder/

Often times when we're investigating regressions (crashes, etc), we have
the build ID of the nightly where the regression started. But it's not
the easiest thing in the world to turn that into an actual pushlog link
which lists the commits in the regression range.

To help fix this, I've created a tool that lets you paste in a buildid
or two and automatically figures out the proper regression range link,
and also links you to the nightly build directories.

This tool is pretty hacky: it loads http://ftp.mozilla.org directory
listings to find builds, and then loads the .txt files describing the
revisions involved. If we ever changed webserver for ftp.mozilla.org the
tool would likely break. But since it's something I do at least once a
week and I know other QA people do this even more regularly, I figured
it was worth automating.

Right now the tool uses ES6 features `let` and `for...of` and so it only
works in Firefox and not in Chrome. I figured for this audience that
wouldn't be a problem.


FWIW, Robert Helmer wrote a tool for scraping the FTP server, storing 
the relevant bits in a database, and exposing the result via HTTP+JSON. 
It used to run on Mozilla's Stackato deployment, but he turned off his 
instance for reasons I can't recall. The service was really useful: 
someone should look into deploying this again.


https://github.com/rhelmer/releases-api/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Test Informant Report - Week of 2014-10-05

[Dave Townsend]

Is there any way to see the breakdown of which testsgot enabled. I'm
surprised to see mochitest-plain rise by 3456 yet mochitest-plain-e10s rise
by only 28. I'd love to find out which tests got turned on on one but not
the other.

Dave

On Tue, Oct 14, 2014 at 6:57 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:

> Test Informant report for 2014-10-12.
>
> State of test manifests at revision f547cf19d104.
> Using revision 9ee9e193fc48 as a baseline for comparisons.
> Showing tests enabled or disabled between 2014-10-06 and 2014-10-12.
>
> 79% of tests across all suites and configurations are enabled.
>
>
> Summary
> ---
> marionette- ↑0↓1600 - 93%
> mochitest-a11y- ↑0↓0   - 99%
> mochitest-browser-chrome  - ↑72↓0  - 95%
> mochitest-browser-chrome-e10s - ↑16↓0  - 29%
> mochitest-chrome  - ↑10↓0  - 97%
> mochitest-plain   - ↑3456↓0 - 75%
> mochitest-plain-e10s  - ↑28↓136 - 66%
> xpcshell  - ↑988↓0 - 92%
>
>
> Full Report
> ---
> http://people.mozilla.org/~ahalberstadt/informant-
> reports/weekly/2014-10-12.informant-report.html
>
>
> Notes
> -
> * Marionette webapi tests were wrongfully counted as being run on desktop
> platforms (now fixed, ignore the 1600 disabled tests there)
> * android-opt now being tracked under mochitest-plain and xpcshell
> ___
> 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: Breakdown of Firefox full installer

[Andreas Gal]

I looked at lzma2 a while ago for FFOS. I got pretty consistently 30% smaller 
omni.ja with that. We could add it pretty easily to our decompression code but 
it has slightly different memory behavior.

Andreas

On Oct 13, 2014, at 5:39 PM, Gregory Szorc  wrote:

> On 10/13/14 4:54 PM, Chris More wrote:
>> Does anyone know or could any of you create a breakdown of the major blocks 
>> of the Firefox installer and each of their respective sizes or percentage of 
>> the whole?
>> 
>> For example, the win32 installer for Firefox 32 is 34MB. The Firefox Growth 
>> team [1] like to know of that 34MB, what is the percentage or size of each 
>> of the components within the 34MB. As for the granularity of the breakdown, 
>> it would be by some logic way of breaking down Firefox. For example, 
>> SpiderMonkey, tools, XUL, etc. I'll leave the granularity up to you on what 
>> you consider a logic block to quantify together.
>> 
>> Why am I asking this?
>> 
>> The win32 Firefox full installer continues to grow (see attachment) each 
>> release and it has been on an increasing growth since Firefox 29. Like 
>> anything on the web, the time it takes to download something (webpage, 
>> binary file, etc.) affects the key conversion rate by some amount. The 
>> Firefox Growth team has a project to understand what features/changes in 
>> Firefox are contributing to the growth or size of the installer. We've asked 
>> a few times previously, but it doesn't look like the documentation or 
>> analysis exist.
>> 
>> Would anyone be able to take on this project as it would be very helpful to 
>> the team? I am imagining a pie chart of the the current installer and then a 
>> table of the name of each component, their size (KB or MB), and any 
>> additional meta data.
> 
> If you are looking for ideas on how to reduce download size, the way omni.ja 
> is included in the installer could be reduced by 4+ MB. Both omni.ja and 
> browser/omni.ja are zip archives, where each file has a separate compression 
> context. If you treat all files from those two archives as a single 
> compression context (like tar+bz2) and stuff them in a single archive, you 
> get size reductions of 4+ MB due to the compression engine sharing state 
> between files. We can't install omni.ja like this on client systems because 
> it is bad for performance (we want the ability to extract individual files 
> without reading a large compression context - this is a benefit of the zip 
> format). But we could ship the files optimized for size (or have installer's 
> compression handle the files individually) and have the installer re-encode 
> them to omni.ja so they are optimized for performance.
> 
> I'm not sure if this has been considered or attempted before. Things are 
> slightly complicated by the fact that omni.ja is a slightly customized zip 
> format. We'd need to ship code to encode omni.ja.
> ___
> 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: Breakdown of Firefox full installer

[Irving Reid]

On 2014-10-13 8:48 PM, Mike Hommey wrote:
> Note a significant amount of the omni.ja and browser/omni.ja data is
> used for jsloader/jssubloader data: 4744949 and 1560499 bytes from those
> files are that. These jsloader/jssubloader data are there for startup
> benefits on Firefox first run (if the data wasn't there, it would be
> generated on the first run and stored in the user profile). This was
> added a while ago, and we've been wondering if the js parser speed had
> been improved enough for those to now be useless for a while. It seems
> to me there's a lot to gain in download size from stripping those if we
> can confirm they are not helping in a significant way anymore. Who wants
> to check?

Aaron Klotz (aklotz) has done some preliminary work on this in bug
873638. I'm planning to take this on in this quarter, unless other
priorities intervene.

 - irving -

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Test Informant Report - Week of 2014-10-05

[Andrew Halberstadt]

Test Informant report for 2014-10-12.

State of test manifests at revision f547cf19d104.
Using revision 9ee9e193fc48 as a baseline for comparisons.
Showing tests enabled or disabled between 2014-10-06 and 2014-10-12.

79% of tests across all suites and configurations are enabled.


Summary
---
marionette- ↑0↓1600 - 93%
mochitest-a11y- ↑0↓0   - 99%
mochitest-browser-chrome  - ↑72↓0  - 95%
mochitest-browser-chrome-e10s - ↑16↓0  - 29%
mochitest-chrome  - ↑10↓0  - 97%
mochitest-plain   - ↑3456↓0 - 75%
mochitest-plain-e10s  - ↑28↓136 - 66%
xpcshell  - ↑988↓0 - 92%


Full Report
---
http://people.mozilla.org/~ahalberstadt/informant-reports/weekly/2014-10-12.informant-report.html


Notes
-
* Marionette webapi tests were wrongfully counted as being run on 
desktop platforms (now fixed, ignore the 1600 disabled tests there)

* android-opt now being tracked under mochitest-plain and xpcshell
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moratorium on new XUL features

[Dirkjan Ochtman]

On Tue, Oct 14, 2014 at 2:29 PM, Boris Zbarsky  wrote:
> Working on it. It's a big project. ;)

Is there a tracker for this?

Cheers,

Dirkjan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: HTML5

[Boris Zbarsky]

On 10/14/14, 1:29 AM, L. David Baron wrote:

(2) While it would be helpful to have the recommendation contain


The "While" seems extraneous.

The rest looks great!

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moratorium on new XUL features

[Boris Zbarsky]

On 10/13/14, 11:28 PM, Yonggang Luo wrote:

If the XUL is truly dead, then mozilla community should consider to remove it 
totally from the codebase


Working on it.  It's a big project.  ;)

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

I was trying to monitoring the 'tree' row count change, how to do that.

[Yonggang Luo]

Thanks in advance..
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Breakdown of Firefox full installer

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/14/2014 02:09 AM, Kyle Huey wrote:
> The simplest way to break the installer down is by the files in
> it.
> 
> e.g. http://khuey.pastebin.mozilla.org/6781501

For future reference:

> mozilla@KHUEY-19294 /c/dev/scratch $ wget
> ftp://ftp.mozilla.org/pub/firefox/releases/latest/win32/en-US/Firefox%20Setup%2032.0.3.exe
>
> 
- --16:59:06--
ftp://ftp.mozilla.org/pub/firefox/releases/latest/win32/en-US/Firefox%20Setup%2032.0.3.exe
> => `Firefox Setup 32.0.3.exe' Resolving ftp.mozilla.org...
> 63.245.215.46, 63.245.215.56 Connecting to
> ftp.mozilla.org|63.245.215.46|:21... connected. Logging in as
> anonymous ... Logged in! ==> SYST ... done.==> PWD ... done. 
> ==> TYPE I ... done.  ==> CWD
> /pub/firefox/releases/latest/win32/en-US ... done.
> 
> ==> PASV ... done.==> RETR Firefox Setup 32.0.3.exe ... done. 
> Length: 35,285,328 (34M) (unauthoritative)
> 
> 100%[>] 35,285,328   967.16K/s
> ETA 00:00
> 
> 17:00:07 (617.58 KB/s) - `Firefox Setup 32.0.3.exe' saved
> [35285328]
> 
> mozilla@KHUEY-19294 /c/dev/scratch $ ls Firefox Setup 32.0.3.exe
> 
> mozilla@KHUEY-19294 /c/dev/scratch $ 7z x Firefox\ Setup\
> 32.0.3.exe
> 
> 7-Zip 4.42  Copyright (c) 1999-2006 Igor Pavlov  2006-05-14
> 
> Processing archive: Firefox Setup 32.0.3.exe
> 
> Extracting  core\precomplete Extracting  core\removed-files 
> Extracting
> core\browser\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd}\icon.
>
> 
png
> Extracting  core\browser\chrome.manifest Extracting
> core\browser\components\components.manifest Extracting
> core\browser\searchplugins\amazondotcom.xml Extracting
> core\browser\searchplugins\bing.xml Extracting
> core\browser\blocklist.xml Extracting
> core\browser\searchplugins\eBay.xml Extracting
> core\browser\searchplugins\google.xml Extracting
> core\browser\searchplugins\twitter.xml Extracting
> core\browser\searchplugins\wikipedia.xml Extracting
> core\browser\searchplugins\yahoo.xml Extracting
> core\defaults\pref\channel-prefs.js Extracting
> core\application.ini Extracting
> core\browser\crashreporter-override.ini Extracting
> core\crashreporter.ini Extracting  core\platform.ini Extracting
> core\update-settings.ini Extracting  core\updater.ini Extracting
> core\webapprt\webapprt.ini Extracting  core\crashreporter.exe 
> Extracting  core\firefox.exe Extracting  core\uninstall\helper.exe 
> Extracting  core\maintenanceservice.exe Extracting
> core\maintenanceservice_installer.exe Extracting
> core\plugin-container.exe Extracting  core\plugin-hang-ui.exe 
> Extracting  setup.exe Extracting  core\updater.exe Extracting
> core\webapp-uninstaller.exe Extracting  core\webapprt-stub.exe 
> Extracting  core\AccessibleMarshal.dll Extracting
> core\breakpadinjector.dll Extracting
> core\browser\components\browsercomps.dll Extracting
> core\D3DCompiler_43.dll Extracting  core\d3dcompiler_46.dll 
> Extracting  core\freebl3.dll Extracting  core\gkmedias.dll 
> Extracting  core\icudt52.dll Extracting  core\icuin52.dll 
> Extracting  core\icuuc52.dll Extracting  core\libEGL.dll Extracting
> core\libGLESv2.dll Extracting  core\mozalloc.dll Extracting
> core\mozglue.dll Extracting  core\mozjs.dll Extracting
> core\msvcp100.dll Extracting  core\msvcr100.dll Extracting
> core\nss3.dll Extracting  core\nssckbi.dll Extracting
> core\nssdbm3.dll Extracting  core\softokn3.dll Extracting
> core\xul.dll Extracting  core\dictionaries\en-US.aff Extracting
> core\freebl3.chk Extracting  core\nssdbm3.chk Extracting
> core\softokn3.chk Extracting  core\dictionaries\en-US.dic 
> Extracting  core\browser\omni.ja Extracting  core\webapprt\omni.ja 
> Extracting  core\omni.ja Extracting  core\dependentlibs.list 
> Extracting
> core\browser\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd}\install.rdf
>
> 
Extracting  core\webapprt
> Extracting  core\uninstall Extracting  core\dictionaries Extracting
> core\defaults\pref Extracting  core\defaults Extracting
> core\browser\searchplugins Extracting
> core\browser\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd} 
> Extracting  core\browser\extensions Extracting
> core\browser\components Extracting  core\browser Extracting  core
> 
> Everything is Ok
> 
> mozilla@KHUEY-19294 /c/dev/scratch $ rm Firefox\ Setup\ 32.0.3.exe
> 
> mozilla@KHUEY-19294 /c/dev/scratch $ find . -type f -printf "%s@
> %p\n" | sort -nr 25027184@ ./core/xul.dll 11174488@ ./core/omni.ja 
> 10397296@ ./core/icudt52.dll 8930647@ ./core/browser/omni.ja 
> 4877424@ ./core/gkmedias.dll 3715184@ ./core/mozjs.dll 3231696@
> ./core/d3dcompiler_46.dll 2106216@ ./core/D3DCompiler_43.dll 
> 1803376@ ./core/nss3.dll 1023600@ ./core/icuin52.dll 897688@
> ./core/uninstall/helper.exe 800368@ ./core/icuuc52.dll 770384@
> ./core/msvcr100.dll 684984@ ./setup.exe 638064@
> ./core/libGLESv2.dll 622592@ ./core/dictionaries/en-US.dic 421200@
> ./core/msvcp100.dll 413296@ ./core/nssckbi.dll 331376@
> ./core/freebl3.dll 275568@ ./core/firefox.exe 273008@
> 

RE: Breakdown of Firefox full installer

[Robert Strong]

> -Original Message-
> From: dev-platform [mailto:dev-platform-
> bounces+rstrong=mozilla@lists.mozilla.org] On Behalf Of Chris
Peterson
> Sent: Monday, October 13, 2014 9:25 PM
> To: dev-platform@lists.mozilla.org
> Subject: Re: Breakdown of Firefox full installer
> 
> On 10/13/14 5:37 PM, Chris Hofmann wrote:
> > and from last year  " Firefox installer size: How big is too big? -
2013"
> >
> > https://groups.google.com/forum/#!searchin/mozilla.dev.planning/instal
> > ler$20size/mozilla.dev.planning/hPgUBzweL70/NeOjEf0hsh0J
> 
> That thread about installer size was regarding the (controversial)
inclusion of 3
> MB of ICU data for SpiderMonkey's ECMA-402 i18n API.
> 
> Chris More organized a funnelcake experiment (bug 933847) to inflate the
> Firefox 25 installer by 3 MB. The report's conclusions:
> 
> * Increasing the download size from 22MB to 25MB had no statistical
affect on
> conversion rates, so we landed ICU.
> 
> * (Countries' average) Internet speed dramatically affected conversion
> rates: 70% success in the fastest countries and 30% in the slowest
countries.
Note that these conversion rates are from download to hitting the first
run page and there are several factors that dramatically lower the
conversion rate outside of the actual stub installer portion of the
process. When just measuring the conversion rate from clicking install in
the stub installer the conversion rate is actually close to 90%.

Robert

> Going forward, it would be interesting to see a dashboard track Firefox
installer
> size every day (or show every changeset's delta on Treeherder).
> 
> 
> chris
> ___
> 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

-remote is no more

[Mike Hommey]

Hi,

I landed earlier today, on mozilla-inbound, the death of the -remote
option on Linux (and some other Unix).

See http://hg.mozilla.org/integration/mozilla-inbound/rev/8044e5199fe2
for the detailed rationale.

I invite third-party application developers to remove the part of their
command line handler that handles the -remote argument for their
application, if they have such support.

Cheers,

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform