Closed Bug 312510 Opened 19 years ago Closed 19 years ago

Win32 installer download size > 5MB

Categories

(Firefox :: General, defect, P1)

Product:
Firefox
Component:
General
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bryner, Assigned: benjamin)

References

Details

(Keywords: fixed1.8)

Attachments

(2 files)

patch
17.43 KB, patch
benjamin
: review-
Details | Diff | Splinter Review
Checkpoint
15.17 KB, patch
bryner
: review+
mscott
: approval1.8rc1+
Details | Diff | Splinter Review 
We've been trying hard to keep the download size for the win32 installer under 5
MB, but it regressed between 9/22 and 9/23 branch builds.  Likely culprit looks
like addition of new languages to DOM Inspector.  I'd propose that we split out
the Inspector locales so that the en-US installer just has the en-US inspector
(currently it includes 17 languages).
This should block release IMO, it will create a perception that we've bloated
significantly since 1.0.x.
Flags: blocking1.8rc1?
While you're at it, strip down the 'reporter', too - it brings 39 locales along
currently... :-/
I agree, this should be a blocker.
Flags: blocking1.8rc1? → blocking1.8rc1+
Attached patch patch — — Splinter Review 
With this patch, we'll only package the inspector and reporter locale for the
corresponding localized installer.  For example, the en-US installer will only
include the en-US inspector and reporter localizations.  This puts us back in
the neighborhood of 4.7 MB in my testing (same fix applies for the Linux
installer; I haven't figured out how the Mac localized builds are generated so
I'm not sure what to do there).
Attachment #199635 - Flags: superreview-
Attachment #199635 - Flags: review?(benjamin)
Comment on attachment 199635 [details] [diff] [review]
patch

oops, mouse must have slipped.
Attachment #199635 - Flags: superreview-
Comment on attachment 199635 [details] [diff] [review]
patch

We should be shipping what we build in-tree, so if this is what we want to do
then we should go back and stop building the non-English locales. However, this
was changed on purpose to include the same locales in our shipped build that
will exist in the AMO version, and I checked pretty carefully that adding all
the locales would not significantly increase the download size (assuming they
were preprocessed properly to avoid license headers etc.) And this will break
locale repackaging also.

Part of the problem is that we don't have the capability to support separate
locale-packs for extensions.
Attachment #199635 - Flags: review?(benjamin) → review-
Or, we could build reporter directly into firefox, instead of building it as an
extension (I'm not quite sure why it is an extension).
Clearly it did increase download size though, by nearly 300 KB.  What locale
repackaging is broken by this change?
This seems like pretty simple math to me -- Inspector locales range anywhere
from 10KB-20KB.  We're shipping _17_ of them with _every_ localized installer. 
Figure in similar numbers for reporter (but with 38 locales there) and it's no
surprise the download size has gone up so much.  We absolutely should not be
shipping all of these locales with every installer, even if it means we have to
put up something different on AMO.
Bryner speaks the truth.
> Or, we could build reporter directly into firefox, instead of building it as an
> extension (I'm not quite sure why it is an extension).

It is packaged as an extension because the user is given the option in the win32
installer to not install reporter.  If you recall, we decided that optionally
installed components would need to be installed as extensions in order to play
nicely with binary patching.
actually, since most folks in developed countries now have broadband, rather
than dialup, the final install file size is not such a big deal like it once
was.  If we want to work on a real area of bloat, it should be memory leaks &
RAM usage, which is currently considerably higher than IE and nearly as high as
the bloated Opera.
Download size is the first impression that you get from a firefox release.
Please do not tell me that the download size isn't important...

An calling opera bloated...
You know that it has the smaller download size although extra tools like mail
etc are included?
If you're not directly involved in the development of Firefox, please do not
comment here. We don't need a long advocacy discussion for or against size
reduction.
Consensus: remove DOMI from the default install of Firefox. Make reporter
builtin code instead of an extension (which means that we only need to ship the
one locale being released at that moment).
Assignee: nobody → benjamin
Priority: -- → P1
I think that is possibly the biggest mistake of the entire 1.5 release. THE
DOCUMENT INSPECTOR IS ONE OF THE GREATEST TOOLS TO WEB DEVELOPERS. By requiring
that authors download an extra extension we are DRAMATICALLY reducing the value
of the product. In the face of Microsoft doing the opposite (developing and
potentially shipping authoring tools with their IE7 browser) this could have a
huge effect on Web developer's use of Firefox.

Having Web authors use Firefox is the single most important thing to increase
our market share.

Removing this from the default build is stupid.
I'll dive in here and comment on this too.  I think the Inspector is a great
gateway for everyday users to begin working with our tools, and also possibly
contribute back to the project.  I know Firefox is very product focused these
days, but as Hixie said, Microsoft continues to take major steps towards getting
users to become authors and beyond.  I think the common notion that users will
only stay users is incorrect, as evidenced by the huge explosion of blogs and
personal publishing.  DOMI is a fantastic tool for folks designing and creating
websites, and it's fairly unique in its function.  It's also part of the package
that makes extensions such a huge success.  Removing it both removes another
pathway for folks to begin to learn how to contribute to both the project and
the product, as well as removes a large advantage the product has for authors. 
I think it would be a tragic mistake.
First step is to incorporate reporter, then see where we are WRT codesize.
> I think that is possibly the biggest mistake of the entire 1.5 release. THE
> DOCUMENT INSPECTOR IS ONE OF THE GREATEST TOOLS TO WEB DEVELOPERS. By 

On the other hand, shipping DOMI in English only or shiping two versions of DOMI
(one in English and the other with all locales) is inadmissible for me because
English users mustn't be favouritism just because the core developers speak
English. 

The ideal solution seems to me to ship Firefox with DOMI and reporter as a
extension with only one locale in the extension jar file and put the extensions
with all locales at AMO. Unfortunately this would require an extra two steps in
the repackaging process and it wouldn'n probably play nicely with binary patching :(

How about suggesting some alternatives to help us not pay the download size
prize for all the DOMI and reporter locales. 

We could ship just the english locales and not support localized version of DOMI
and Reporter in the product. 

Or we could do a combination of:

1) Ship DOMI as an extension but only ship the english strings
2) Make reporter part of the build and not an extension so we ship the right
locale without shipping all of the locales.
Attached patch Checkpoint — — Splinter Review 
This is a checkpoint, not fully tested (although you're welcome to review it).
Attachment #199845 - Flags: review?
We should just ship the correct locale of Inspector when we ship the correct
locale of Firefox. How this is done is an implementation detail. :-) I'm
obviously not suggesting that we should have English only, or that we should
have one build which has one locale and another with all the other locales or
anything like that.
It appears that just the reporter refactoring is sufficient to bring the size to
4.88 MB... I'm happy with that for 1.5.
Comment on attachment 199845 [details] [diff] [review]
Checkpoint

>--- extensions/reporter/Makefile.in	2 Oct 2005 12:06:01 -0000	1.11
>+++ extensions/reporter/Makefile.in	17 Oct 2005 20:56:01 -0000
>@@ -39,24 +39,17 @@
> 
> DEPTH		= ../..
> topsrcdir	= @top_srcdir@
> srcdir		= @srcdir@
> VPATH		= @srcdir@
> 
> include $(DEPTH)/config/autoconf.mk
> 
>-ifdef MOZ_XUL_APP
>-XPI_NAME               = reporter
>-USE_EXTENSION_MANIFEST = 1
>-NO_JAR_AUTO_REG        = 1
>-INSTALL_EXTENSION_ID   = reporter@mozilla.org
>-XPI_PKGNAME            = reporter-$(MOZ_APP_VERSION)
>-endif
>-
>+ifdef BUILD_ALL_LOCALES

When is this defined?  lxr doesn't seem to know anything about it.

You can remove the RPT_SHORT and RPT_LONG strings in installer.inc as well. 
r=me, in any case.
Attachment #199845 - Flags: review? → review+
To clarify one thing for the people jumping on the "Save DOM Inspector"
bandwagon:  We don't install it by default as is, so the majority of users don't
have it.  Users have to choose Developer Tools in the Custom install to get it.

Aside from codesize, which to me is a secondary concern, there's a question of
what is the best way to fill this niche.  If we just ship DOMI, and focus on
better stuff for 2.0, that's a long time to wait.  Shipping from AMO gives us
the flexibility to ship new features/tools as part of the update, without
worrying about download size.  This includes Venkman, more web developer tools,
and possibly bits from the extension developer extension.
> Shipping from AMO gives us the flexibility to ship new features/tools as part 
> of the update, without worrying about download size.

Mike: Shipping DOMI with FF does not preclude users from downloading an enhanced
version from AMO.  Recall that XPIs installed into the user's profile take
highest priority.  This means that you could install DOMI in both the user's
profile as well as in the global location, and FF would use the one installed in
the user's profile.  Moreover, user's can also manually disable the global DOMI
extension if they favor some other extension (with a different ID) that also
provides DOMI or some close variation on it.
BUILD_ALL_LOCALES is not defined anywhere in the build system: it would only be
used from a command-line to build an XPI or something like that.
Darin, can we point the installer-based DOMI to AMO so it gets updates from
there?  I don't know EM/update well enough to know how this interacts, but I was
under the impression that installer-bundled extensions couldn't update separately.
> Darin, can we point the installer-based DOMI to AMO so it gets updates from
> there?  I don't know EM/update well enough to know how this interacts, but I was
> under the impression that installer-bundled extensions couldn't update 
> separately.

Right, there is no support for installer-based DOMI updating itself against AMO
independently.  There's no good way to support that and partial application
update.  In other words, users would have to download DOMI from AMO, so that
they would then be able to track updates to DOMI independent from the
application's version of DOMI.
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Attachment #199845 - Flags: approval1.8rc1?
Comment on attachment 199845 [details] [diff] [review]
Checkpoint

I'll approve this is someone with a trunk build can verify that the reporter
tool is working as expected on the trunk. (i.e. a trunk verification :)).
Successfully Transmitted Report RMO11296784943551

and Reporter's no longer showing as an extension

build used was most recent trunk nightly:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051018
Firefox/1.6a1 ID:2005101813

Sorry for the bugspam
Comment on attachment 199845 [details] [diff] [review]
Checkpoint

great. Thanks for testing out reporter on the trunk.

approving for the branch.

Benjamin, do we need to be updating the removed files list for the old reporter
as an extension files? Oh never mind, you did that already.
Attachment #199845 - Flags: approval1.8rc1? → approval1.8rc1+
Fixed, 1.8 branch.
Keywords: fixed1.8
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051018 
Firefox/1.5 ID:2005101822

Reporter went mia in the latest hourly builds.
Not sure if that due to this bug or the versionnumber upgrade to 1.5
Does this mean that we're going to move the reporter l10n files back to the
l10n repository for 2.0? Or rather, just trunk?
my $0,02 (for what it's worth *S*): I would very much like for the DOMi and
Reporter extensions (and all other extensions that need l10n) to be moved to the
/l10n repository...

From a localizers viewpoint, it seems odd to have ones sources lying somewhere
else that /l10n, when the general move seems to centralize l10n workings/issues
to the /l10n tree (browser, toolkit, now mail ;-) )

localizers also only have commit access to the /l10n tree - which implies
approval bugs for even such simple things as fixing a spelling error or changing
an accesskey...

And of course : xx-XX localized versions of Firefox should only ship with the
xx-XX locale - not all locales ;-)
Depends on: 313894
Jesse pointed out that our Windows installer is now precisely 5.0 MB.  I verified this by viewing http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-10-25-19-mozilla1.8/.  What repercussions does that have on this bug?
(In reply to comment #39)
> Jesse pointed out that our Windows installer is now precisely 5.0 MB.  I
> verified this by viewing
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-10-25-19-mozilla1.8/.
>  What repercussions does that have on this bug?
> 

None really. In the IE download manager that size gets converted to 4.97 MB. As long as the number that shows up there is < 5 MB we are meeting our goal. AFAIK
IE's download manager says it's 4.97 MB, but Firefox's download manager says it's 5.0 MB.
Please, this bug is NOT Resolved/Fixed as it leaves out some localizations of Inspector (see bug 311079).

How did you decide which localizations are good for inclusion and which not?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #42)
> 
> How did you decide which localizations are good for inclusion and which not?
> 

That decision was never made. I checked in new locales happily until this turned
out to be a problem, and then stopped.
Which locales are in is based on "we didn't back those out".
This bug is unrelated to which locales are in DOMI. I posted announcements about how to get locales in DOMI months ago.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
(In reply to comment #44)
> This bug is unrelated to which locales are in DOMI. I posted announcements
> about how to get locales in DOMI months ago.

Unrelated? Really? So why in the bug 311079 (written following your announcement, no mentions of a size or temporal limit) in the comment #2 Axel wrote:
> not granting approval, we have issues with the download size, see bug 312510.

Why Axel mentioned this bug if it is unrelated??

And why as Italian should I download more of 200kB of localizations that doesn't include Italian, when it was included in FX 1.0?


(In reply to comment #11)
> > Or, we could build reporter directly into firefox, instead of building it as an
> > extension (I'm not quite sure why it is an extension).
> 
> It is packaged as an extension because the user is given the option in the
> win32
> installer to not install reporter.  If you recall, we decided that optionally
> installed components would need to be installed as extensions in order to play
> nicely with binary patching.
> 
It could be a REAL extension, and not even be an option in the installer, and just be located on the extensions page. A list of "suggested" extensions and their location could be a part of a "README" which is viewable after install, which is pretty common practice with most software.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: