Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Nightly Firefox 3.5 builds offered current build as update even when current




Application Update
7 years ago
7 years ago


(Reporter: abillings, Assigned: rstrong)



1.9.1 Branch
Mac OS X

Firefox Tracking Flags

(blocking1.9.1 .16+, status1.9.1 .16-fixed)


(Whiteboard: [mozmill])



7 years ago
It was noticed today that if you do a manual check for updates in a current 1.9.1 nightly build, you will be offered an update to "3.5.16pre". This update will be the same build as you already have.

I'm running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101105 Shiretoko/3.5.16pre and I keep getting offered a new build if I manually check and it is the same build after I restart for the update. 

The culprit may be the checkin two days ago into the 1.9.1 update code but I'm not sure. See 

Logging this under RelEng as requested by John O'Duinn.
Could that be happening because of the following patch which has been landed on 1.9.1 and now quits earlier with a JS error: "abi" not defined?


7 years ago
blocking1.9.1: --- → .16+
status1.9.1: --- → wanted
Keywords: regression
Fixing this broken check-in solved the problem for me and no more update is listed. So it's clearly a regression from bug 552924.

Adding Mozmill whiteboard entry because we detected this with our Mozmill test-runs.
Blocks: 552924
Hardware: x86 → All
Whiteboard: [mozmill]
Component: Release Engineering → Application Update
Product: → Toolkit
QA Contact: release → application.update
Version: other → 1.9.1 Branch
The follow-up patch which has been landed on bug 552924, didn't fix the problem for me gAbi is still undefined:

Error: reference to undefined property "gAbi"
Source File: file:///Applications/
Line: 1155
If you manually added that I would expect that error. It should be gABI which is what landed.
Gotcha! That's it. Now it's working fine. Thanks Rob!

Fixed with:
Assignee: nobody → robert.bugzilla
Last Resolved: 7 years ago
status1.9.1: wanted → .16-fixed
Resolution: --- → FIXED
As Al discovered we also have to push this fix to 1.9.2.
blocking1.9.2: --- → ?
status1.9.2: --- → ?
On 1.9.2 it's not a problem with this patch. Nick was able to fix the update problem server-side. So no need for this patch on 1.9.2, even it would be useless, because there is nothing to fix.
blocking1.9.2: ? → ---
status1.9.2: ? → ---
You need to log in before you can comment on or make changes to this bug.