Closed Bug 1065509 Opened 11 years ago Closed 11 years ago

Windows Nightly and Aurora stub installer never starts download of Firefox binaries

Categories

(Firefox :: Installer, defect)

Product:
Firefox
Component:
Installer
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 35
Tracking Flags:
Tracking Status
firefox33 + verified
firefox34 + verified
firefox35 + verified

People

(Reporter: vladan, Assigned: spohl)

References

Details

Attachments

(1 file)

Patch (bump to 70 MB)
1015 bytes, patch
robert.strong.bugs
: review+
lmandel
: approval-mozilla-aurora+
lmandel
: approval-mozilla-beta+
Details | Diff | Splinter Review
STR: 1. Visit http://nightly.mozilla.org/ 2. Choose Windows (Express) for the stub installer, open the downloaded file, grant UAC permissions 3. Start installation process The installer never advances past "Downloading Nightly..", the progress bar keeps spinning, and it doesn't seem to download anything at all.
Summary: Windows Nightly stub installer never starts download → Windows Nightly stub installer never starts download of Firefox binaries
Flags: needinfo?(robert.strong.bugs)
This is likely due once again to either the bouncer config or the bits not being pushed out.
Flags: needinfo?(robert.strong.bugs) → needinfo?(bhearsum)
http://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US and download.mozilla.org/?product=firefox-stub&os=win&lang=en-US both work for me. I probably can't dig deeper into this today (I'm on a work week).
Flags: needinfo?(bhearsum)
(In reply to Ben Hearsum [:bhearsum] from comment #2) > http://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US and > download.mozilla.org/?product=firefox-stub&os=win&lang=en-US both work for > me. I probably can't dig deeper into this today (I'm on a work week). Downloding the installers in a browser works fine. The problem is that the stub installer itself can't download the full Firefox binaries
Flags: needinfo?(bhearsum)
Nothing has changed in the stub installer between beta and release besides the url params which have been in place and have worked for quite a while. So, I highly doubt it is the stub and that something server side changed or wasn't updated.
Just realized that the NSIS upgrade on the build system is another change. I'll look into this.
Old nightly stub installers from prior to the NSIS upgrade which were previously working are also affected.
I also verified that after changing the url to download to release that the stub downloads successfully. This and my other comments lead me to believe that this is either a server side change or something server side wasn't updated and not the stub installer. I need to focus on the Mac v2 signing work and won't be able to look into this more. Not sure what the right component should be but I believe the right people are cc'd to this bug so I am not changing it at this time.
Summary: Windows Nightly stub installer never starts download of Firefox binaries → Windows Nightly and Aurora stub installer never starts download of Firefox binaries
Looks like download.m.o is set up ok: $ curl -sIL "http://download.mozilla.org/?product=firefox-nightly-latest&os=win&lang=en-US" | egrep '^HTTP|^Location' HTTP/1.1 302 Found Location: http://download-installer.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-central/firefox-35.0a1.en-US.win32.installer.exe HTTP/1.1 200 OK $ curl -sIL "http://download.mozilla.org/?product=firefox-aurora-latest&os=win&lang=en-US" | egrep '^HTTP|^Location' HTTP/1.1 302 Found Location: http://download.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-aurora/firefox-34.0a2.en-US.win32.installer.exe HTTP/1.1 200 OK NB: Comment #2 refers to the release case, rather than nightly. vladan, do you get an en-US installer or localized from nightly.mozilla.org ? We don't support localized stub for nightly/aurora, only lang=en-US works on those download.m.o links
Flags: needinfo?(bhearsum)
I saw this with the en-US stub from both nightly.mozilla.org and aurora.mozilla.org. I verified the url was correct. I also verified that this fails with a locally built stub installer. I also verified that this succeeds with the same locally built stub installer after only changing the nightly download url to the release download url.
Ok, that's great info. Unfortunately I can't reproduce with the latest stub for nightly from nightly.mozilla.org (sha1: b8f08b692a74a42c8a5db8dfd5ad6f2e). It shows 'Downloading Nightly...' for a while, data is being downloaded, then a Nightly Setup process appears on the task bar, then I get a dialog about the download being interrupted. This is on WinXP. Might be a CDN issue. Where should I look to see what the stub has downloaded ? I'm interested in checking the size & hash.
If you are getting an indeterminate progress bar it is trying to start the download which is what I am getting. After it times out then you will get the download interrupted message (it is a generic message). So, if it isn't downloading as I suspect then there wouldn't be anywhere to look to see what the stub has downloaded.
The progress bar is indeterminate, but there's quite a bit of network traffic going on too (~600KB/s). Strangely wireshark sees lots of requests for download.m.o, when I was expecting just one at the start then a request for download-installer.cdn.mozilla.net (which turns into edgecast for me). On a couple of occasions the stub has locked up. The full installer does work, when downloaded via nightly.m.o (ie via ftp.m.o). And I get the same hash for that and for http://download.mozilla.org/?product=firefox-nightly-latest&os=win&lang=en-US, as well as the ftp server (sha1:8c97581513e736d6e1a2eb84e5e70d1e6ff458a8).
And I see RST from 117.18.232.191 (edgecast) immediately prior to the extra requests to download.m.o.
It is likely retrying after failure. Also note that the exact same code with a release url works.
The CDN is using the same origin server for both nightly/aurora and release cases, the only differences are * cache timeout - looks like 1 day for nightly, 7 days for releases * the nightly file changes (at least) once a day, the releases one is static * release files are requested a lot more, so are likely to be cached already But I don't see how to get from that to nightly not working, given I can download the nightly with wget with no problems.
Not sure what changed but it wasn't the stub (also indicated by the fact that the same stub fails when pointed to nightly or aurora and succeeds when pointed to release). http://hg.mozilla.org/mozilla-central/filelog/bad6a9fc2bf0/browser/installer/windows/nsis/stub.nsi
gozer, any clues ?
Flags: needinfo?(gozer)
Note: I also tested with the 8/11 nightly stub and it also fails even though this regression is much more recent. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-08-11-03-02-03-mozilla-central/firefox-34.0a1.en-US.win32.installer-stub.exe
(In reply to Nick Thomas [:nthomas] from comment #12) > The progress bar is indeterminate, but there's quite a bit of network > traffic going on too (~600KB/s). Strangely wireshark sees lots of requests > for download.m.o, when I was expecting just one at the start then a request > for download-installer.cdn.mozilla.net (which turns into edgecast for me). > On a couple of occasions the stub has locked up. Would be nice to see the full network capture for this. But yes, there should be one quick request to download.m.o (bouncer), followed by an actual download from one of our CDNs. Did you mean you saw lots of traffic for ftp.m.o maybe, but certainly not download.m.o ? > The full installer does work, when downloaded via nightly.m.o (ie via > ftp.m.o). And I get the same hash for that and for > http://download.mozilla.org/?product=firefox-nightly-latest&os=win&lang=en- > US, as well as the ftp server > (sha1:8c97581513e736d6e1a2eb84e5e70d1e6ff458a8). (In reply to Nick Thomas [:nthomas] from comment #13) > And I see RST from 117.18.232.191 (edgecast) immediately prior to the extra > requests to download.m.o. Allright, this is getting me interested. Could you grab and attach a full packet capture of this?
Flags: needinfo?(gozer)
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #14) > It is likely retrying after failure. Also note that the exact same code with > a release url works. That's very odd, given that our CDN doesn't even know the difference, in either case, release/nightly, it goes back to ftp.m.o as the origin for the files.
Okay, I've managed to reproduce this with Nightly on my own machine, and I've been able to do packet capture to see what's going on. So far, I can see that bouncer is doing the right thing, with many duplicate requests like this one: GET /?os=win&lang=en-US&product=firefox-nightly-latest HTTP/1.1 User-Agent: NSIS InetBgDL (Mozilla) Host: download.mozilla.org Connection: Keep-Alive HTTP/1.1 302 Found Server: Apache X-Backend-Server: bouncer2.webapp.phx1.mozilla.com Cache-Control: max-age=60 Content-Type: text/html; charset=UTF-8 Date: Fri, 12 Sep 2014 17:51:00 GMT Location: http://download-installer.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-central/firefox-35.0a1.en-US.win32.installer.exe Keep-Alive: timeout=3, max=495 Connection: Keep-Alive Set-Cookie: dmo=74.58.204.229.1410544260140852; path=/; expires=Sat, 12-Sep-15 17:51:00 GMT X-Cache-Info: caching Content-Length: 0
In my particular trace, I could see the stub installer trying over and over to get the actual installer. It would ask bouncer successfully, then go to http://download-installer.cdn.mozilla.net/ via Edgecast (93.184.215.191). From the packet captures I've done, it looks like the stub installer is the one terminating the connection with Edgecast before having finished downloading the installer. How does the stub installer determine the authenticity of the installer its downloading, since it's downloading it over http:// ? Could the stub installer somehow decide to abort and retry the download for some reason? Here is what one of these aborted connections looks like: No. Time Source Destination Protocol Length Info 1370 10.222710 93.184.215.191 172.16.x.y TCP 1514 [TCP segment of a reassembled PDU] Frame 1370: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) Ethernet II, Src: Vmware_fe:XX:xx (00:50:56:fe:XX:xx), Dst: Vmware_2e:YY:yy (00:0c:29:2e:YY:yy) Internet Protocol Version 4, Src: 93.184.215.191 (93.184.215.191), Dst: 172.16.x.y (172.16.x.y) Transmission Control Protocol, Src Port: http (80), Dst Port: 49730 (49730), Seq: 1048281, Ack: 205, Len: 1460 No. Time Source Destination Protocol Length Info 1371 10.222737 172.16.x.y 93.184.215.191 TCP 54 49730 > http [ACK] Seq=205 Ack=1048281 Win=64240 Len=0 Frame 1371: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Ethernet II, Src: Vmware_2e:YY:yy (00:0c:29:2e:YY:yy), Dst: Vmware_fe:XX:xx (00:50:56:fe:XX:xx) Internet Protocol Version 4, Src: 172.16.x.y (172.16.x.y), Dst: 93.184.215.191 (93.184.215.191) Transmission Control Protocol, Src Port: 49730 (49730), Dst Port: http (80), Seq: 205, Ack: 1048281, Len: 0 0000 00 50 56 fe 30 b3 00 0c 29 2e 32 8a 08 00 45 00 .PV.0...).2...E. 0010 00 28 0c 7b 40 00 80 06 50 4c ac 10 bc 80 5d b8 .(.{@...PL....]. 0020 d7 bf c2 42 00 50 40 7c dd 82 7d 96 90 43 50 10 ...B.P@|..}..CP. 0030 fa f0 28 6f 00 00 ..(o.. No. Time Source Destination Protocol Length Info 1372 10.222797 172.16.x.y 93.184.215.191 TCP 54 49730 > http [ACK] Seq=205 Ack=1049741 Win=64240 Len=0 Frame 1372: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Ethernet II, Src: Vmware_2e:YY:yy (00:0c:29:2e:YY:yy), Dst: Vmware_fe:XX:xx (00:50:56:fe:XX:xx) Internet Protocol Version 4, Src: 172.16.x.y (172.16.x.y), Dst: 93.184.215.191 (93.184.215.191) Transmission Control Protocol, Src Port: 49730 (49730), Dst Port: http (80), Seq: 205, Ack: 1049741, Len: 0 0000 00 50 56 fe 30 b3 00 0c 29 2e 32 8a 08 00 45 00 .PV.0...).2...E. 0010 00 28 0c 7c 40 00 80 06 50 4b ac 10 bc 80 5d b8 .(.|@...PK....]. 0020 d7 bf c2 42 00 50 40 7c dd 82 7d 96 95 f7 50 10 ...B.P@|..}...P. 0030 fa f0 22 bb 00 00 .."... No. Time Source Destination Protocol Length Info 1373 10.222867 172.16.x.y 93.184.215.191 TCP 54 49730 > http [FIN, ACK] Seq=205 Ack=1049741 Win=64240 Len=0 Frame 1373: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Ethernet II, Src: Vmware_2e:YY:yy (00:0c:29:2e:YY:yy), Dst: Vmware_fe:XX:xx (00:50:56:fe:XX:xx) Internet Protocol Version 4, Src: 172.16.x.y (172.16.x.y), Dst: 93.184.215.191 (93.184.215.191) Transmission Control Protocol, Src Port: 49730 (49730), Dst Port: http (80), Seq: 205, Ack: 1049741, Len: 0 0000 00 50 56 fe 30 b3 00 0c 29 2e 32 8a 08 00 45 00 .PV.0...).2...E. 0010 00 28 0c 7d 40 00 80 06 50 4a ac 10 bc 80 5d b8 .(.}@...PJ....]. 0020 d7 bf c2 42 00 50 40 7c dd 82 7d 96 95 f7 50 11 ...B.P@|..}...P. 0030 fa f0 22 ba 00 00 .."... No. Time Source Destination Protocol Length Info 1374 10.222874 172.16.x.y 93.184.215.191 TCP 54 49730 > http [RST, ACK] Seq=206 Ack=1049741 Win=0 Len=0 Frame 1374: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Ethernet II, Src: Vmware_2e:YY:yy (00:0c:29:2e:YY:yy), Dst: Vmware_fe:XX:xx (00:50:56:fe:XX:xx) Internet Protocol Version 4, Src: 172.16.x.y (172.16.x.y), Dst: 93.184.215.191 (93.184.215.191) Transmission Control Protocol, Src Port: 49730 (49730), Dst Port: http (80), Seq: 206, Ack: 1049741, Len: 0 0000 00 50 56 fe 30 b3 00 0c 29 2e 32 8a 08 00 45 00 .PV.0...).2...E. 0010 00 28 0c 7e 40 00 80 06 50 49 ac 10 bc 80 5d b8 .(.~@...PI....]. 0020 d7 bf c2 42 00 50 40 7c dd 83 7d 96 95 f7 50 14 ...B.P@|..}...P. 0030 00 00 1d a7 00 00 ...... No. Time Source Destination Protocol Length Info 1375 10.222887 93.184.215.191 172.16.x.y TCP 54 http > 49730 [ACK] Seq=1049741 Ack=206 Win=64239 Len=0 Frame 1375: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Ethernet II, Src: Vmware_fe:XX:xx (00:50:56:fe:XX:xx), Dst: Vmware_2e:YY:yy (00:0c:29:2e:YY:yy) Internet Protocol Version 4, Src: 93.184.215.191 (93.184.215.191), Dst: 172.16.x.y (172.16.x.y) Transmission Control Protocol, Src Port: http (80), Dst Port: 49730 (49730), Seq: 1049741, Ack: 206, Len: 0 0000 00 0c 29 2e 32 8a 00 50 56 fe 30 b3 08 00 45 00 ..).2..PV.0...E. 0010 00 28 e2 e1 00 00 80 06 b9 e5 5d b8 d7 bf ac 10 .(........]..... 0020 bc 80 00 50 c2 42 7d 96 95 f7 40 7c dd 83 50 10 ...P.B}...@|..P. 0030 fa ef 22 bb 00 00 .."...
The stub installer could very well be doing that but it would most likely be due to a server side change since this has only started recently while the stub installer hasn't changed and the same stub installer using the nightly url that fails succeeds when only the url is changed.
I believe I've found a very likely candidate for the problem. Looking at http://hg.mozilla.org/mozilla-central/file/bad6a9fc2bf0/browser/installer/windows/nsis/stub.nsi#l158 ; Minimum size expected to download in bytes !define DownloadMinSizeBytes 15728640 ; 15 MB ; Maximum size expected to download in bytes !define DownloadMaxSizeBytes 36700160 ; 35 MB That constant is set at 35Mb, but looking at the current nightly: $> lwp-request -m HEAD https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-35.0a1.en-US.win32.installer.exe 200 OK Cache-Control: max-age=3600 [...] Content-Length: 40648224 Shows me it's at around 40Mb now, so. Looking at the stub installer code, it will abort files it tries to download that are bigger than DownloadMaxSizeBytes. This would explain the behaviour we are seeing, without a change client-side or server-side.
[Tracking Requested - why for this release]: Looks like we tipped over that limit a long time ago in Nightly: -rw-r--r-- 1 ffxbld firefox 35941952 Jun 25 15:06 06/2014-06-25-03-02-06-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 35983432 Jun 26 14:38 06/2014-06-26-03-02-01-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36036232 Jun 27 14:06 06/2014-06-27-03-02-12-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36327496 Jun 28 13:53 06/2014-06-28-03-02-01-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36329264 Jun 29 13:58 06/2014-06-29-03-02-06-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36342560 Jun 30 14:08 06/2014-06-30-03-02-02-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 37146864 Jul 1 13:16 07/2014-07-01-03-02-02-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 37155256 Jul 2 13:22 07/2014-07-02-03-02-01-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 37172520 Jul 3 13:26 07/2014-07-03-03-02-00-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 37202872 Jul 4 13:25 07/2014-07-04-03-02-08-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 37199448 Jul 5 13:16 07/2014-07-05-03-02-03-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 37216872 Jul 6 13:21 07/2014-07-06-03-02-26-mozilla-central/firefox-33.0a1.en-US.win32.installer.exe And then it rode the train to Aurora: -rw-r--r-- 1 ffxbld firefox 35672456 Jul 19 12:15 07/2014-07-19-00-40-01-mozilla-aurora/firefox-32.0a2.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 35687576 Jul 19 19:17 07/2014-07-19-07-46-40-mozilla-aurora/firefox-32.0a2.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 35673112 Jul 20 11:58 07/2014-07-20-00-40-02-mozilla-aurora/firefox-32.0a2.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 35684240 Jul 21 11:51 07/2014-07-21-00-40-01-mozilla-aurora/firefox-32.0a2.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36813808 Jul 22 12:01 07/2014-07-22-00-40-02-mozilla-aurora/firefox-33.0a2.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36815304 Jul 23 11:45 07/2014-07-23-00-40-01-mozilla-aurora/firefox-33.0a2.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36821480 Jul 24 11:45 07/2014-07-24-00-40-02-mozilla-aurora/firefox-33.0a2.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36818880 Jul 25 11:57 07/2014-07-25-00-40-02-mozilla-aurora/firefox-33.0a2.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36824984 Jul 26 11:45 07/2014-07-26-00-40-02-mozilla-aurora/firefox-33.0a2.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36809424 Jul 27 11:46 07/2014-07-27-00-40-02-mozilla-aurora/firefox-33.0a2.en-US.win32.installer.exe -rw-r--r-- 1 ffxbld firefox 36822680 Jul 28 11:35 07/2014-07-28-00-40-05-mozilla-aurora/firefox-33.0a2.en-US.win32.installer.exe We're not quite at the limit for beta yet, probably because of differently build config options. We're extremely close though: -rw-r--r-- 2 ffxbld firefox 36433160 Sep 16 08:44 Firefox Setup 33.0b4.exe We should probably bump this on Beta ASAP, maybe before 33.0b5.
tracking-firefox33: --- → ?
Flags: needinfo?(sledru)
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(lmandel)
Figured it can't hurt to have a patch on file in case we simply want to bump this to twice the current max size.
Attachment #8490935 - Flags: review?(robert.strong.bugs)
Holy crap! Excellent sleuthing! We've seen sizes that were larger than expected sent from the server in the past so this check was added. A lot has changed since then so I'm taking a quick look at the download sizes in the stub data ping to see if it is still happening and if so, the max and min sizes these values should be set to.
Flags: needinfo?(robert.strong.bugs)
I'm marking 33 as affected even thought the issue does not yet reproduce there yet as it will be impacted if the size exceed 35 MB.
status-firefox33: --- → affected
status-firefox34: --- → affected
status-firefox35: --- → affected
tracking-firefox33: ? → +
tracking-firefox34: --- → +
tracking-firefox35: --- → +
Flags: needinfo?(lmandel)
Comment on attachment 8490935 [details] [diff] [review] Patch (bump to 70 MB) Approval Request Comment [Feature/regressing bug #]: installer size has increased past the stub installer max size check. [User impact if declined]: stub installer won't work [Describe test coverage new/current, TBPL]: tested locally [Risks and why]: none. just increasing the max value [String/UUID change made/needed]: none
Attachment #8490935 - Flags: review?(robert.strong.bugs)
Attachment #8490935 - Flags: review+
Attachment #8490935 - Flags: approval-mozilla-beta?
Attachment #8490935 - Flags: approval-mozilla-aurora?
Keywords: checkin-needed
Comment on attachment 8490935 [details] [diff] [review] Patch (bump to 70 MB) We know the cause of breakage here and are unlikely to get any meaningful feedback from our existing Nightly user populate. Approved for Beta and Aurora.
Attachment #8490935 - Flags: approval-mozilla-beta?
Attachment #8490935 - Flags: approval-mozilla-beta+
Attachment #8490935 - Flags: approval-mozilla-aurora?
Attachment #8490935 - Flags: approval-mozilla-aurora+
Flags: needinfo?(sledru)
Assignee: nobody → spohl.mozilla.bugs
status-firefox33: affected → fixed
status-firefox34: affected → fixed
Wow. good catch on the max size. We've been increasing a few MB every few releases pretty consistently since Firefox 4. 70MB should be suffice for now and hopefully we don't let Firefox grow to that size. There is already a pretty big conversion rate to install for parts of the world with lower internet speeds, but that's a different conversation all together.
Blocks: 1058017
We'll have to wait until there is a mozilla-central nightly build containing the fix, as the on-change builds don't build or upload the stub installer.
https://hg.mozilla.org/mozilla-central/rev/e31e24c2bd28
Status: NEW → RESOLVED
Closed: 11 years ago
status-firefox35: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
(In reply to Chris More [:cmore] from comment #33) > Wow. good catch on the max size. We've been increasing a few MB every few > releases pretty consistently since Firefox 4. 70MB should be suffice for now > and hopefully we don't let Firefox grow to that size. There is already a > pretty big conversion rate to install for parts of the world with lower > internet speeds, but that's a different conversation all together. Can we add a unit test to check the size of the built installer against this number, at least on opt builds? This is almost certainly going to bite us again.
I think the check can be removed now instead and I'll check if that is the case after Mac v2 signing is done. If it can't it should be possible to perform a check during packaging.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #37) > I think the check can be removed now instead and I'll check if that is the > case after Mac v2 signing is done. If it can't it should be possible to > perform a check during packaging. Yeah, if we can remove the hard coded size check and find another way to verify, that would be cool. Though, 70MB should buy us *lots* lot time.
Reproduced the initial issue with Nightly 35 and Aurora 34 stub installers from September 15th. The issue no longer reproduced on Win 7 x64 using: - latest Nightly 35 - BuildID=20140918030202 - latest Aurora 34 - BuildID=20140918004100 There is also no issue running the 33 Beta 5 stub installer, but then again Beta was not (yet) affected by this. I'm assuming that if the current verification system changes then it will be tracked in a separate issue, so marking this as Verified.
Status: RESOLVED → VERIFIED
status-firefox33: fixed → verified
status-firefox34: fixed → verified
status-firefox35: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: