523324 - Fallback update cannot be downloaded for 3.5.4 build 1

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: screenshot

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091007 Firefox/3.5.4 (.NET CLR 3.5.30729) ID:20091007001339

When users have installed the build 1 of Firefox 3.5.4 the fallback update cannot be downloaded. Under such a condition the disabled license pane of the update wizard is shown and there is no way to continue the download process. See the attached screenshot.

The fallback update should work for users running a build 1 on Windows. Testing on Linux doesn't expose this problem. Is that update channel related?

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

That happens on all platforms. Mozmill was lying to me because we are still able to click on hidden elements. That's really something we should have to fix.

By running the normal process of a fallback updates I see the same on OS X.

Comment 2

[Chris Cooper [:coop] (he/him)]

This is WONTFIX, sorry.

We're specifically only providing complete updates for the build1->build3 scenario. The fallback would be the same MAR file again, and if it's missing on the first pass, we don't gain anything by trying again.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

That's a bit unclear why you have wontfixed this bug. We are doing those tests for a long time now and fallback updated for complete mar's for build1->build3 are not different from the ones for e.g. 3.5->3.5.4. While the latter one is working perfect we fail in the build1->build3 case.

Can you please explain why this should be different?

Comment 4

[Al Billings [:abillings - ex-MoCo]]

As Henrik says, we do fallback in complete updates all the time. The fallback for a complete update is to attempt the complete update again. I assume that is the way it is configured on the server generally so I would guess that this is just a configuration problem this time and the server isn't set up to send the complete mar file as the fallback as it normally does.

Comment 5

[[e-mail] (:bhearsum)]

(In reply to comment #3)
> That's a bit unclear why you have wontfixed this bug. We are doing those tests
> for a long time now and fallback updated for complete mar's for build1->build3
> are not different from the ones for e.g. 3.5->3.5.4. While the latter one is
> working perfect we fail in the build1->build3 case.
> 
> Can you please explain why this should be different?

Because the process we have for generating snippets between candidate builds does not include copying partials.

Given that:
* The "partial" and complete snippets would be exactly the same
* The beta channel for 3.5.x is a small subset of our users
* It's rare anyone would need to fallback when the first MAR they try is the complete
and
* If the first attempt _does_ fail, they can re-try with 'check for updates'

I see no reason to change this.

(In reply to comment #4)
> As Henrik says, we do fallback in complete updates all the time. The fallback
> for a complete update is to attempt the complete update again. I assume that is
> the way it is configured on the server generally so I would guess that this is
> just a configuration problem this time and the server isn't set up to send the
> complete mar file as the fallback as it normally does.

It's not configuration in the "flip a switch" sense of the word. Changing this involves finnicky modifications to an already finnicky process.