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: