arni2033 Reporter
	Description • 8 years ago

Read Note (1), Note (2)

STR:
1. Create new profile using current Nightly, launch it, disable updates
2. Download and extract russian Firefox Developer Edition 45:  https://ftp.mozilla.org/pub/firefox/nightly/2015/12/2015-12-22-00-40-10-mozilla-aurora-l10n/firefox-45.0a2.ru.win32.zip
3. Launch the profile from Step 1 in russian Firefox Developer Edition 45
4. Click Australis Menu button (≡) -> [?] -> "О Firefox"   ("About Firefox")
5. Click button "Проверить на обновления"   ("Check for updates")

AR:  The window says "Установлена последняя версия" ("You're using the latest vesion")
ER:  The window should provide a way to update russian Firefox Developer Edition 45

Note:
1) !!!   This is issue with the site   !!!
2) In Network tab I see the following link:
> https://aus5.mozilla.org/update/3/Firefox/45.0a2/20151222004010/WINNT_x86-msvc-x64/ru/aurora/Windows_NT%206.1.1.0%20(x64)/default/default/update.xml?force=1
 The response is:
> <?xml version="1.0"?>
> <updates>
> </updates>

 In english version of Firefox Developer Edition 45 I see another link
> https://aus5.mozilla.org/update/3/Firefox/45.0a2/20151222004010/WINNT_x86-msvc-x64/en-US/aurora/Windows_NT%206.1.1.0%20(x64)/default/default/update.xml?force=1
 The response is OK, it contains a link to some real update.

	Rail Aliiev [:rail]
	Comment 1 • 8 years ago

We looked into this last week.

The buildID is caught by Firefox-mozilla-aurora-nightly-20151223004004 which is a watershed to make sure users update to the 20151223004004 build, which enables the SHA2 cert used in further builds. Apparently some win32 locales (including "ru") are missing in that build.

One of the ideas how to fix the Firefox-mozilla-aurora-nightly-20151223004004 blob was to manually add entries using either one of the previous or next builds. I'm not sure if this is going to work, because:

1) if we add a build built before Firefox-mozilla-aurora-nightly-20151223004004, it won't accept SHA2 signed updater.exe used by latest builds. Also we would need to add a special rule to avoid the watershed catching this build

2) if we add a build after Firefox-mozilla-aurora-nightly-20151223004004, this means we are skipping the watershed, and the updates will fail.

bhearsum, any ideas?

	bhearsum@mozilla.com (:bhearsum)
	Comment 2 • 8 years ago

(In reply to Rail Aliiev [:rail] from comment #1)
> We looked into this last week.
> 
> The buildID is caught by Firefox-mozilla-aurora-nightly-20151223004004 which
> is a watershed to make sure users update to the 20151223004004 build, which
> enables the SHA2 cert used in further builds. Apparently some win32 locales
> (including "ru") are missing in that build.
> 
> One of the ideas how to fix the
> Firefox-mozilla-aurora-nightly-20151223004004 blob was to manually add
> entries using either one of the previous or next builds. I'm not sure if
> this is going to work, because:
> 
> 1) if we add a build built before
> Firefox-mozilla-aurora-nightly-20151223004004, it won't accept SHA2 signed
> updater.exe used by latest builds. Also we would need to add a special rule
> to avoid the watershed catching this build
> 
> 2) if we add a build after Firefox-mozilla-aurora-nightly-20151223004004,
> this means we are skipping the watershed, and the updates will fail.

Ah, good points. Honestly, I don't think it's worth fixing for nightly and aurora given this. The populations (especially localized) versions are minimal and relatively knowledgeable. The few users that are stuck should be able to get up to date on their own.

The only actual solution to this I can think of us to respin those locales...and I don't know how easy or possible that is 4 months later.

	arni2033 Reporter
	Comment 3 • 8 years ago

(In reply to Rail Aliiev [:rail] from comment #1)
> The buildID is caught by Firefox-mozilla-aurora-nightly-20151223004004 which
> is a watershed to make sure users update to the 20151223004004 build, which
> enables the SHA2 cert used in further builds. Apparently some win32 locales
> (including "ru") are missing in that build.
Are you going to fix the update system or keep it completely broken?   (Why do you even have this system if users are supposed (sic!) to update manually, and where's support page saying so)

	Rail Aliiev [:rail]
	Comment 4 • 8 years ago

Unfortunately fixing this issue may take unknown amount of time. We would need to create custom builds, sign them with the sha1 cert, generate updates, publish them, etc.

Given that this issue is applicable only to Developer Edition and assuming that people on this channel are usually OK being on the bleeding edge, I'm going to resolve this as WONTFIX.

	arni2033 Reporter
	Comment 5 • 8 years ago

(In reply to Rail Aliiev [:rail] from comment #4)
> Given that this issue is applicable only to Developer Edition and assuming
> that people on this channel are usually OK being on the bleeding edge,
I'm not OK with that unless there's a support page explicitly saying that update system doesn't work on Firefox DE channel. That's what I expect from this bug report - such page should tell that this bug
is intended outcome (So that I knew that this bug isn't worth reporting when I encounter it in future)

	arni2033 Reporter
	Comment 6 • 8 years ago

I agree: Aurora is a simple alpha channel, with no guarantees. But Firefox DE is not Aurora.
User's intent when installing an alpha version is to test and don't expect anything to work. The intent when installing "a browser for developers" is to get some new features on fully supported channel. This is why it seemed strange that Mozilla simply changed the label of the product and now expects users to think it's indeed a well-thought browser for developers. It really looks like a lie.

That's my general notes regarding DE. This bug is specifically about official DE description not mentioning that users are intended to update manually.   https://www.mozilla.org/firefox/developer/

	Chris AtLee [:catlee]
	Comment 7 • 8 years ago

I'd like to provide a little clarification to your last point: users are not intended to update manually in general. Automatic updates on DE/aurora work most of the time.

The bug you're hitting is due to some changes that were required to the Windows signing / update process earlier this year. Unfortunately some locales weren't properly handled, and users like yourself got stranded without updates.

Installing a recent version of DE will get you an updated version of Firefox, and future updates should continue to work.

	Rail Aliiev [:rail]
	Comment 8 • 8 years ago

I just installed the build mentioned above, using the installer, to make sure it also installs the maintenance service. I checked the registry and found 2 keys under HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\MaintenanceService\$UID for both sha2 and sha1 certs. I deleted the sha2 cert entry, rebooted the machine, changed the channel to auroratest ad checked the updates. Everything worked fine, no UI prompts or something like that (weird).

Maybe we can just disable this watershed and let people update?

	arni2033 Reporter
	Comment 9 • 8 years ago

(In reply to Chris AtLee [:catlee] from comment #7)
> I'd like to provide a little clarification to your last point: users are not intended to update
> manually in general. Automatic updates on DE/aurora work most of the time.
Hmm, how do you know it works most of the time? There're no tests to ensure it's working, otherwise this bug would be detected right away. I waited a long time before reporting it, hoping it'll be fixed

I know that it's impossible to make a test for each locale and build ID, but what is possible is (for 
example) send the latest available en-US build as an extra XML attribute for Firefox to ensure that update doesn't happen for long time for some reason - and open already existing UI for failed update.
So, that could provide reliable (auto)update UI _forever_
In my view, the worst part is not thousands of bugs, it's the attitude.

Also, I know there're some "traps" and "checkpoints" regarding updates.
"Checkpoints" are a strange order of updates. For example, my Firefox 42 (Release) haven't updated straight to the 45, but 45 was available. It first updated to 43, then to 45. That is strange, but I suppose that's intended, and otherwise my profile would be broken in some way. Are you completely sure that updating to the latest version wouldn't break the profile in any unexpected way?   v_v
("Traps" are some breakages occuring when the same profile is launched in Nightly, then in Release/ESR
 Such bugs are usually Wontfix'ed and were mentioned only to emphasize that updating isn't that easy)

	Rail Aliiev [:rail]
	Comment 10 • 8 years ago

I'm going to resolve this as INCOMPLETE.

	arni2033 Reporter
	Comment 11 • 8 years ago

(In reply to Rail Aliiev [:rail] from comment #10)
> I'm going to resolve this as INCOMPLETE.
Reason? The browser still can't be updated.
Resolving this as "incomplete" is illogical. I described the issue, and it is real to this day.
The site still does not provide any info (works poorly), and there's still no mechanism in the browser that could help to avoid this bug in future. If you don't want to build a reliable update system or stop claiming that it works fine, please close this as WONTFIX.

I still think that as a result of this bug at least one of the following should happen:
 X) Mozilla's site should reliably provide updates
 Y) Products that can't update, should inform user about that
 Z) Products that can't update, should inform user what how exactly they should be updated
 T) Mozilla developers should avoid unsubstantiated claims that Firefox can ever update automatically
   (you can see how comment 7 says that _hypothetically_ Firefox can sometimes update)

	Rail Aliiev [:rail]
	Comment 12 • 8 years ago

I don't think that someone has time to look at this anytime soon. This is the main reason why I closed it as INVALID.

I know, it's frustrating when something isn't working as expected, but we don't have unlimited resources to address every single bug we have. :(

Rail, not-superman. :)