The default bug view has changed. See this FAQ.

Launching of a web application with a l10n build results in a XUL error - app fails to launch

VERIFIED FIXED in Firefox 17

Status

Firefox Graveyard
Web Apps
P1
critical
VERIFIED FIXED
5 years ago
a year ago

People

(Reporter: jsmith, Assigned: glandium)

Tracking

({regression})

16 Branch
Firefox 17
regression
Bug Flags:
in-testsuite -

Details

(Whiteboard: [blocking-webrtdesktop1+], [qa!])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Steps:

1. Install a l10n build here - ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/ for a particular locale (I tested AF and JA)
2. Launch the build
3. Install a web app from apps.mozillalabs.coma/appdir
4. Launch the web app

Expected:

The app should launch - menus should be localized.

Actual:

The app fails to launch with a XUL error. So far seen on AF and JA locales.

Example error in Japanese:

XML パースエラー: 定義されていない実体が使用されています。
URL: chrome://webapprt/content/webapp.xul
行番号: 32, 列番号: 3:  <key id="key_undo"
--^
(Reporter)

Updated

5 years ago
Blocks: 762864
(Reporter)

Updated

5 years ago
Keywords: regression
(Reporter)

Comment 1

5 years ago
Regression testing has shown so far:

- 7/17/2012 l10n build: Busted
- 7/14/2012 l10n build: Busted
- 7/11/2012 l10n build: Working
The error translates to (courtesy of Google translate):

XML parse error: entity not defined has been used.
URL: chrome://webapprt/content/webapp.xul
line number 32, column number 3: <key id = "key_undo"
Okay, I was able to reproduce this on a en-GB build. Definitely a l10n issue.
An app fails to launch with any localized version. Likely an issue with the DTD include in webapp.xul.

Comment 5

5 years ago
Unpacking omni.ja from these builds show no webapprt directory:

chrome/en-GB/locale/webapprt doesn't exist

Only these directories exist at chrome/en-GB/locale:

branding       browser        browser-region en-GB          feedback       pdfviewer
Regression is from bug 762864.
Assignee: nobody → mh+mozilla

Comment 7

5 years ago
I do see the expected locale files here,
webapprt/chrome/en-GB/locale/webapprt

Perhaps this isn't the right way to reference that file:
chrome://webapprt/locale/webapp.dtd

Comment 8

5 years ago
contents of webapprt/chrome/en-GB.manifest:
locale webapprt en-GB en-GB/locale/webapprt/

with this directory structure for chrome:

./chrome
./chrome/en-GB
./chrome/en-GB/locale
./chrome/en-GB/locale/webapprt
./chrome/en-GB/locale/webapprt/webapp.dtd
./chrome/en-GB/locale/webapprt/webapp.properties
./chrome/en-GB.manifest
(Reporter)

Updated

5 years ago
tracking-firefox16: --- → ?
(Assignee)

Comment 9

5 years ago
The problem is that webapprt/omni.ja!/chrome.manifest contains manifest chrome/en-US.manifest instead of manifest chrome/$(AB_CD).manifest.
(Assignee)

Comment 10

5 years ago
Created attachment 643262 [details] [diff] [review]
Fix webapprt l10n after bug 762864
(Assignee)

Updated

5 years ago
Attachment #643262 - Flags: review?(benjamin)
Attachment #643262 - Flags: review?(benjamin) → review+
(Reporter)

Updated

5 years ago
Priority: -- → P1
Whiteboard: [blocking-webrtdesktop1+]
(Reporter)

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/179df699d81f
Flags: in-testsuite-
Keywords: checkin-needed
(Assignee)

Comment 12

5 years ago
https://hg.mozilla.org/mozilla-central/rev/768eb7111521
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox16: --- → affected
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Target Milestone: --- → Firefox 17

Comment 13

5 years ago
Jason, it'd be great if you could verify this, AFAICT, we should get aurora approval on this.
Keywords: qawanted
(Assignee)

Comment 14

5 years ago
This is not in a nightly yet. I was waiting for a nightly to come up to double check and request an aurora approval.
(Assignee)

Comment 15

5 years ago
7/19 nightlies are up and the l10n packages look good. Jason, please confirm that they work properly. Thanks.
https://hg.mozilla.org/mozilla-central/rev/179df699d81f
(Reporter)

Updated

5 years ago
Whiteboard: [blocking-webrtdesktop1+] → [blocking-webrtdesktop1+], [qa+]
(Reporter)

Comment 17

5 years ago
Verified on the 7/19 l10n build on Windows 7 by installing and launching 4 distinct apps. Note although launching is fixed, there's still problems in the menu and notification localization (i.e. it isn't being localized), but I'll file separate bugs for that. That shouldn't block an uplift though.

Please nominate for aurora uplift when you get the chance.
Status: RESOLVED → VERIFIED
Keywords: qawanted
Whiteboard: [blocking-webrtdesktop1+], [qa+] → [blocking-webrtdesktop1+], [qa!]
(Reporter)

Comment 18

5 years ago
I should clarify - When I say it isn't being localized, I mean not everything is localized. The words "File," "Quit," "Edit", and everything in the application installed notification isn't localized. The menu under the edit menu is localized.
(Assignee)

Comment 19

5 years ago
(In reply to Jason Smith [:jsmith] from comment #18)
> I should clarify - When I say it isn't being localized, I mean not
> everything is localized. The words "File," "Quit," "Edit", and everything in
> the application installed notification isn't localized. The menu under the
> edit menu is localized.

How was it before bug 762864 landed?
(Reporter)

Comment 20

5 years ago
(In reply to Mike Hommey [:glandium] from comment #19)
> (In reply to Jason Smith [:jsmith] from comment #18)
> > I should clarify - When I say it isn't being localized, I mean not
> > everything is localized. The words "File," "Quit," "Edit", and everything in
> > the application installed notification isn't localized. The menu under the
> > edit menu is localized.
> 
> How was it before bug 762864 landed?

I re-tested this actually on the most recent nightly again. This looks okay now. I cc-ed you on two l10n bugs though that I did recently pick up from testing this. See bug 776362 and bug 776365.
(Assignee)

Comment 21

5 years ago
Comment on attachment 643262 [details] [diff] [review]
Fix webapprt l10n after bug 762864

[Approval Request Comment]
Regression caused by bug 762864 
User impact if declined: Launching web apps doesn't work on non en-US builds
Testing completed (on m-c, etc.): see comments 17, 18 and 20
Risk to taking this patch (and alternatives if risky): Low risk
String or UUID changes made by this patch: None
Attachment #643262 - Flags: approval-mozilla-aurora?

Updated

5 years ago
tracking-firefox16: ? → +

Updated

5 years ago
Attachment #643262 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 22

5 years ago
http://hg.mozilla.org/releases/mozilla-aurora/rev/ce2e8871ebd8
status-firefox16: affected → fixed
(Reporter)

Updated

5 years ago
Whiteboard: [blocking-webrtdesktop1+], [qa!] → [blocking-webrtdesktop1+], [qa+]
(Reporter)

Updated

5 years ago
status-firefox16: fixed → verified
Whiteboard: [blocking-webrtdesktop1+], [qa+] → [blocking-webrtdesktop1+], [qa!]
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.