Closed Bug 335026 Opened 19 years ago Closed 18 years ago

Erroneous UA string in trunk builds


(Camino Graveyard :: General, defect)

Not set


(Not tracked)



(Reporter: phiw2, Assigned: mark)



User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; chrome://navigator/locale/; rv:1.9a1) Gecko/20060422 Camino/1.2+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; chrome://navigator/locale/; rv:1.9a1) Gecko/20060422 Camino/1.2+

The UA string now contains: chrome://navigator/locale/;
Don't think this is intended.

First noticed with an own build (checkout start: Thu Apr 20 10:24:25 JST 2006),
confirmed with the  2006042022 (1.2+) build

I guess bug 334756, which landed shortly before I build my own Camino.

Reproducible: Always
Actual regression window:

This is a trunk-only bug, which rules out bug 334756, as does the regression range.

That range sorta fingers the SM changes to ifdefs in chrome (the stuff that goes into embed.jar, which is about 0.1 MB smaller and missing folders in 4-19 build), bug 332400?
Ever confirmed: true
Yes, 332400.  See bug 332400 comment 18 and 19.

I checked in bug 331576 to pluck the UA locale out of the lproj in use, but we still rely on what we get in embed.jar as a fallback in case we can't figure out the language based on the lproj (which should never happen...)  I'm leaving this bug open for that reason - either embed.jar should be fixed or we should change our fallback behavior.  The former is probably better, to account for other users of embed.jar.
I wonder why a) was in embed.jar b) what you need it for
Benjamin Smedberg told me we could ignore Camino as xpfe-based app, as it would be XULRunner-based soon. That was the reason why I didn't care about possible impacts on Camino over in bug 332400 - apparantly this bug was caused by that kind of ignorance.
I don't think that testing is the riught thing to get the selected language anyways though.
And I'll stick by that general notion: cooperation and communication is necessary, but getting rid of xpfe is necessary, and it will be necessary for Camino to do some work to stay up with that. embed.jar is total hack, and we need to figure out a short path to get Camino to a toolkit-based (hopefully XULRunner-based) app, just aas SM is doing.
This also apparently breaks Real Player 10.0.0 on Camino trunk (bug 336061).
Blocks: 336061
Blocks: 336523
*** Bug 336523 has been marked as a duplicate of this bug. ***
No longer blocks: 336523
Severity: trivial → critical
*** Bug 343986 has been marked as a duplicate of this bug. ***
Assignee: nobody → mark
Fixed by bug 331576
Closed: 18 years ago
Keywords: fixed1.8.1.1
Resolution: --- → FIXED
Trunk-only bug :P
Keywords: fixed1.8.1.1
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.