Closed Bug 466089 Opened 16 years ago Closed 16 years ago

Customizing toolbars breaks Menus on l10n builds

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: tchung, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre For l10n builds, trying to customize the toolbar will break the menu bar after saving the changes. This causes the menu bar to be inoperable. No repro on en-US builds. On DE: Fehler: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIStringBundle.GetStringFromName]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: chrome://browser/content/browser.js :: anonymous :: line 4212" data: no] on enGB: Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIStringBundle.GetStringFromName]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: chrome://browser/content/browser.js :: anonymous :: line 4187" data: no] Reproducible: Always Steps to Reproduce: 1. open any l10n nightly build (eg. DE or en-GB) 2. Right click toolbar area > Customize... 3. DnD any toolbar icon to the toolbar 4. Save changes, and verify the Browser menu options are all disabled [File|Edit|View|..] Actual Results: File menu should still be working after customizing toolbars on l10n builds. Expected Results: File menu is disabled, and nsIStringBundle.GetStringFromName error is thrown.
Can't reproduce on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b2pre) Gecko/20081120 Minefield/3.1b2pre nor Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b2pre) Gecko/20081120 Minefield/3.1b2pre Those are more current than what we do in Beta 2 from what I can tell, so we should verify this on the Beta 2 candidate builds.
PS: It's totally possible that we uploaded builds with missing strings at a point. The current builds aren't checked against anything there, if there are no missing files, they go live.
I take it that that's the case, resolving INCOMPLETE.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.