Closed Bug 162593 (compreg.dat) Opened 22 years ago Closed 22 years ago

we should register components if mozilla is newer than the registry (compreg.dat ) - "Cyrillic [also Hebrew, Chinese and other intl stuff] shown as garbage, profile manager breaks

Categories

(Core Graveyard :: Cmd-line Features, defect)

Product:
Core Graveyard
Component:
Cmd-line Features
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: ezh, Assigned: dveditz)

References

Details

(Keywords: intl, regression)

Attachments

(1 file)

restore "autoreg after install" functionality
679 bytes, patch
emaijala+moz
: review+
alecf
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
Downloaded a 2002081304 build - cyrillic is shown as crap.
Found that this regression does not have build 2002081209, but have 2002081308.

http://www.menelon.ee/netscape/moz/ - here you can find how moz displays
cyrillic. Also css is not applyed...

PS trunk builds.
Severity: normal → critical
Keywords: regression
-> Int
Assignee: Matti → yokoyama
Component: Browser-General → Internationalization
QA Contact: asa → ruixu
Keywords: intl
QA Contact: ruixu → ylong
This problem only in trunk build but not in branch build.
OS: Windows XP → All
Hardware: PC → All
Summary: Cyrillic is not shown → [trunk]Cyrillic is not shown
This worksforme on the URL you cite with a current trunk build on Linux....
(2002-08-13-08).
Blocks: 162633
this works for me on WinXP with 2002-08-13-08 trunk build. The charset points to
Windows-1251 and displays correctly. I tried with Autodetect off, Universal and
i don't see the regression that Eugene observes...
reporter: which os are you running on?
assign to shanjian
Assignee: yokoyama → shanjian
XP...

I'll try with todays build.
OK. I have some intresting to tell you.

Build 2002081409 under XP does not work for me either.

The charecter set points to Win-1251, but 2 things happens:

1) cyrillic is not shown 
2) the CSS also does not applayed

Look at http://www.menelon.ee/netscape/moz/ - I posted 2 new screenshots. 

iso-8859-1.jpg - with character set iso-8859-1
win-1251.jpg  - --"-- win-1251


You can also go to the www.kaspersky.ee and play with character set. With one
you'll see the css is applyed and with others doesn't.
Eugene, when i said that the charset points to 1251 i meant it displays
correctly as well... Yuing, do you see the gibberish display of cyrillic chars
on that page? I am not able to repro the problem.
I'm able, also with a new profile...

I'll try out on a second computer.
I saw the page rus.defli.ee is displayed wrong in Mac OS 10.1.5 TRUNK build,
while BRANCH build is OK.

From reporter's build ID, it looks like trunk build also.

Eugene:
Is there any posible that you can install a BRANCH build to see if you still see
the same problem? thanks!
i've seen this problem on Ying MacOSX10.1.5 with the trunk build but on my
system MacOSX 10.1 i am not able to reproduce it, neither do i see it on windows
XP (latest XP build with SP1) nor on Linux. 
This bug is only in Installer build. Zip build doesn't have this bug.
Same problem with hebrew sites.
http://www.walla.co.il
Build 2002081409, win XP.
Also charst windows-1250 doesn't work correctly.
Also css styles seems seems to be broken.
This worked 2-3 days before.
try http://www.sme.sk
1.1 - WFM
zipped trunk build - WFM
>This bug is only in Installer build. Zip build doesn't have this bug.
cc to alecf, this might be related to the uconv change
>this might be related to the uconv change
I mean bug 157993.
I find it interesting that its only the installer build. 
Can you look in your components directory, and look for the following dlls:
ucv*.dll
uconv.dll

and tell me the size of uconv.dll?
ideally you only have ucvmath.dll and uconv.dll, and uconv.dll should be about 745k

can you also try the installer build on a fresh installation rather than
installing over an old copy? the installer is SUPPOSED to remove the old ucv*
dlls (i.e. ucvcn.dll, ucvlatin.dll, etc) but maybe its not?

I know that the Netscape Commercial builds from 2002 08 13 did not remove these
dlls, but the next build should. However, the mozilla builds should not be
suffering from this problem.

Removing components/compreg.dat makes this problem disappear.
Installer should remove the old compreg.dat.

*** Bug 162633 has been marked as a duplicate of this bug. ***
huh. the newer files are supposed to overwrite the entries in compreg.dat...
makes me wonder if autoreg either isn't running, or if its not supposed to run
why the machine that builds compreg.dat isn't picking up the new file.

cc'ing dougt and dveditz for autoreg and installer questions.
I can confirm that deleting compreg.dat cured it for me too.
similarly, chinese web page(e.g. www.yahoo.com.hk) doesn't work on nightly
build/w2k.
So this does not look like a i18n problem. Reassign to alec. Please redirect to
the right person if it is not in your domain.
Assignee: shanjian → alecf
this is an installer problem... compreg.dat needs to be regenerated after every
build.
Assignee: alecf → dveditz
Component: Internationalization → Installer
QA Contact: ylong → bugzilla
Keywords: nsbeta1
*** Bug 163206 has been marked as a duplicate of this bug. ***
We're starting to get all kinds of weird errors because of this. I saw myself on
one system that the whole app was quite hosed because compreg.dat was not
up-to-date (bookmarks not showing, personal toolbar not populating, start page
not loading, url bar not updating etc).
Summary: [trunk]Cyrillic is not shown → [trunk]Cyrillic is not shown (compreg.dat not updated)
*** Bug 163194 has been marked as a duplicate of this bug. ***
*** Bug 162803 has been marked as a duplicate of this bug. ***
No crash/dataloss

==> Severity = major
No longer blocks: 162633
Severity: critical → major
Summary: [trunk]Cyrillic is not shown (compreg.dat not updated) → [trunk] Cyrillic [also Hebrew, Chinese and other intl stuff] shown as garbage (compreg.dat not updated)
I suppose my bug could also rightly be filed under this one...

Bug bug 162423

*** Bug 162423 has been marked as a duplicate of this bug. ***
*** Bug 163471 has been marked as a duplicate of this bug. ***
cc some release people - we need traction here, we're getting lots of dupes -
someone needs to make sure the builds get compreg.dat regenerated.. I don't know
why this isn't happening on installer builds.
*** Bug 162728 has been marked as a duplicate of this bug. ***
Summary: [trunk] Cyrillic [also Hebrew, Chinese and other intl stuff] shown as garbage (compreg.dat not updated) → [trunk] Force update or compreg.dat (or erase it altogether) during installation (was: "Cyrillic [also Hebrew, Chinese and other intl stuff] shown as garbage (compreg.dat not updated)")
Updated summary (note: though it looks excessively long, please do not trim it
as having proper keywords there simplifies dupe search)
*** Bug 163513 has been marked as a duplicate of this bug. ***
*** Bug 163625 has been marked as a duplicate of this bug. ***
*** Bug 163662 has been marked as a duplicate of this bug. ***
*** Bug 163607 has been marked as a duplicate of this bug. ***
*** Bug 163692 has been marked as a duplicate of this bug. ***
*** Bug 163695 has been marked as a duplicate of this bug. ***
*** Bug 160980 has been marked as a duplicate of this bug. ***
*** Bug 163624 has been marked as a duplicate of this bug. ***
*** Bug 163745 has been marked as a duplicate of this bug. ***
*** Bug 163761 has been marked as a duplicate of this bug. ***
A lot of dupes, shoudn't the summary say something about missing back and
forward buttons and also about the bookmarks tool that disappears?
I think this causes such a variety of symptoms that we can't possibly have them
all in the subject.
Summary: [trunk] Force update or compreg.dat (or erase it altogether) during installation (was: "Cyrillic [also Hebrew, Chinese and other intl stuff] shown as garbage (compreg.dat not updated)") → [trunk] Force update of compreg.dat (or erase it altogether) during installation (was: "Cyrillic [also Hebrew, Chinese and other intl stuff] shown as garbage (compreg.dat not updated)")
bug 160980 (marked as duplicate of this one) seems to have gone away
in the newer build (try reinstalling Mozilla w/o deleting any file
in the directory).
Alias: compreg.dat
*** Bug 163862 has been marked as a duplicate of this bug. ***
About the summary, the problem that I had was missing back and forward button +
bookmarks (got duped into this one), if I would run into this bug today I would
think that bug 126826 would be my problem, which is not.
cc'ing asasaki - Aki please work with dveditz and find out where this
compreg.dat file is being munged.
*** Bug 163980 has been marked as a duplicate of this bug. ***
*** Bug 163952 has been marked as a duplicate of this bug. ***
*** Bug 164048 has been marked as a duplicate of this bug. ***
*** Bug 164032 has been marked as a duplicate of this bug. ***
*** Bug 164303 has been marked as a duplicate of this bug. ***
Any news here?
*** Bug 164534 has been marked as a duplicate of this bug. ***
*** Bug 164586 has been marked as a duplicate of this bug. ***
*** Bug 164587 has been marked as a duplicate of this bug. ***
as mentioned in e-mail, this bug is impeding the DLL consolidation effort,
because when components move from one DLL to another, this change isn't picked
up in compreg.dat, and we more or less lose the functionality of that component.
Blocks: 163737
CC'ing myself
*** Bug 162192 has been marked as a duplicate of this bug. ***
Should we add bug #126836 to the "Bug 162593 blocks: 163737"?  For bug triage 
purpose?  I leave this matter into your hand.
Gee!  Typo error, I meant bug #126826 from comment #65.
Bug 126826, Bug 163184 has been both been duped to bug 126826, where they maybe
should have been duped to this one..
*** Bug 164971 has been marked as a duplicate of this bug. ***
*** Bug 164790 has been marked as a duplicate of this bug. ***
*** Bug 165306 has been marked as a duplicate of this bug. ***
The last dupe is more precisely a dupe of bug 165199 (adding dependency). The
many dupes here and there show, that it makes Mozilla completely useless to most
users, they cannot even start in many cases. So this here should be a blocker.

We know exactly when the problem occured. So the obvious fix would be to remove
whatever caused this problem or refix this change.

pi
Blocks: 165199
I also think, it shows up as blocker. One open question at this place:
if it is so complicated, just to fix that bug, why then don't You delete
compreg.dat from setup? This workaround could ease the problem
> The last dupe is more precisely a dupe of bug 165199 (adding dependency).

I've re-duped bug 165306 to bug 165199 where I think it belongs.  It's not clear
to me that bug 165199 is a complete dupe of this bug - so far, some different
symptoms are showing up there.  (You were right to mark it dependent though.) 
If this bug were fixed it would clear up a lot of the confusion over what's
causing the other problems.
*** Bug 165481 has been marked as a duplicate of this bug. ***
Blocks: 165459
Blocks: 165604
Depends on: 113593
No longer blocks: 165604
The workaround in Comments 72 is a good answer.  Still, the original problem 
will still be there and it isn't a good idea to sweep that under the rug.  
We're going to be delaying more problem later on.
See bug 165199 comment 35.  Does running regxpcom.exe from the Mozilla folder
fix the problems here?  Just deleting compreg.dat does *not* always fix bug
165199, but some people are reporting that running regxpcom.exe always does fix
things there.  Is anybody in a position to test that resolution here - or to
know that it won't work similarly?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/2002082818

I see three problems:

1) – and — are displayed as ?.

2) Manage bookmarks open an empty window with title "mozilla-bin".

3) Sometimes in the MailNews-Editor there is a grey area at the bottom. It does
not cause any problem, though.

I guess all this is related to this bug here. I started
/usr/lib/mozilla-1.1b/regxpcom, but it did not change compreg.dat and hence did
not solve my problems.

pi
None of the problems I described in the previous comment went away by manually
deleting compreg.dat. It wasn't newly created either. Then I tried regxpcom and
got a new one. It was worse. Now the MailNews window did not work anymore. It
had no content. The only way out was to overwrite with the saved old version:-(

This sucks big time.

pi
You can add another item to the list of things that are horked, and fixed, by
deleting compreg.dat.

Since 8/29 I'd been unable to use ftp:// as a URL.  The status bar would end up
saying "Done" (after "Beginning FTP transaction...") but nothing would appear. 
(No files or folders from the FTP site.)  After deleting compreg.dat, I was
immediately able to use ftp:// again.
I was just wondering if this is really a recent regression or if we just
stumbled on it now when there were some bigger changes in components. Unless, of
course, compreg.dat used to be deleted or something when uninstalling.
*** Bug 165873 has been marked as a duplicate of this bug. ***
*** Bug 166046 has been marked as a duplicate of this bug. ***
*** Bug 165199 has been marked as a duplicate of this bug. ***
*** Bug 161736 has been marked as a duplicate of this bug. ***
from my dupe, this is the right thing to do.

steps to fix:
1. implement method to find mozilla application (place in nsICmdLineService?)
2. in appshell, get application object, check it's date against the component
registry. If the applicaiton is newer, force a registration.

Note that this problem existed in the days of registry.dat too, we've just been
moving a lot faster recently which is how we've managed to continuously run into
this problem.
Assignee: dveditz → law
Component: Installer → XP Apps: Cmd-line Features
QA Contact: bugzilla → sairuh
Summary: [trunk] Force update of compreg.dat (or erase it altogether) during installation (was: "Cyrillic [also Hebrew, Chinese and other intl stuff] shown as garbage (compreg.dat not updated)") → we should register components if mozilla is newer than the registry (compreg.dat ) - "Cyrillic [also Hebrew, Chinese and other intl stuff] shown as garbage, profile manager breaks
Re: comment 79: That sounds like it might be an interaction with the new FTP
parser.
Keywords: mozilla1.2
This patch restores the "autoreg after install" functionality we used to have
with component.reg. This will not solve the problems that running regxpcom
didn't solve -- this bug has morphed to include several different things.

re comment 85: startup used to do this kind of check in the component.reg days,
too. dp didn't want it in the component manager itself in case some embeddors
didn't want the hit (they'd never change anything) so it was checked for by
nsAppRunner.cpp (using macros supplied by xpinstall headers). Those appear to
be gone, unless doug moved them into component manager itself.
Not to say that I know enough about this, but maybe the other problems could be
caused by registrations of components that don't exist anymore, like the
components combined to uconv. Autoregistration just updates registration for
changed components, right? Maybe it should also iterate the registry and check
that all the registered components exist. 
Comment on attachment 97817 [details] [diff] [review]
restore "autoreg after install" functionality

sr=alecf, though I can't claim to know how this fixes the problem :)
Attachment #97817 - Flags: superreview+
oops, I loaded another bug before the bugmail went out.
note to ere: in the case of uconv, uconv itself has changed, so autoreg will
pick that up, and thus recognize the new components in that DLL.. all the
component entries will switch from whichever old library (ucvja, etc) to the new
(existing) dll, uconv.dll.

sr=alecf on that patch...lets get this puppy in!
Re: Comment#88

Would this also allow a Calendar installation - or other add-ons - to survive a
new installation?
Comment on attachment 97817 [details] [diff] [review]
restore "autoreg after install" functionality

Alec: good good, then I think this might actually do the trick :) 

I hope it's ok that I mark r=, at least I think I know how this should fix it
:P
Attachment #97817 - Flags: review+
*** Bug 166679 has been marked as a duplicate of this bug. ***
OK, this bug is starting to get rather annoying.

First, it prevented Mozilla from starting. And then, today, it broke View
Page-Source (see Bug #166679).

I'd really like to know what the root cause of the problem is.
> First, it prevented Mozilla from starting. And then, today, it broke View
> Page-Source

> I'd really like to know what the root cause of the problem is.

The "root cause" is different in each case.  Determine what code was checked-in
such that before the check-in View Source worked and, after the check-in, it
didn't.  That's the *specific* cause of that problem.  (Although fixing the
installer may resolve the situation in general.)
If the cause is always different, then changing the installer is only going to
hide the real problem. That is, IMHO, a lot is going on without appropriate
tight control on the fundamental aspects of Mozilla. And, it appears that
compreg.dat is one of those fundamental parts of Mozilla which has to be
right.....or else!
verbal r=dougt, taking bug from Bill
Assignee: law → dveditz
Comment on attachment 97817 [details] [diff] [review]
restore "autoreg after install" functionality

a=asa (on behalf of drivers) for checkin to 1.2a
Attachment #97817 - Flags: approval+
Fix checked into 1.2a. This fixes the original regression of not autoregistering
after an upgrade. If running regxpcom didn't solve your problem then this fix
won't either and your bug was not a true duplicate. In those cases please reopen
the bug wrongly marked duplicate, NOT this one.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Jason, I'd say it's just the opposite. The root cause of all problems is that
changed components were not registered correctly. There are different symptoms
depending on the component, but the cause is same. You can argue that a checkin
is the cause of one specific problem, but when there is nothing wrong with the
checkin, there is also no reason to blame it. Besides, I wouldn't define "root
cause" anything that is specific to just one case.
<OT>

> There are different symptoms depending on the component, but the cause is same.

A body ends up at the morgue where and autopsy is done.  Upon further medical
and criminal investigation it's determined that the woman was a diabetic and had
died because her husband deliberately injected her with concentrated sugar
rather than her regular insulin.  The husband is arrested and put in jail.

What's the root cause?  The fact that her husband killed her by exploiting her
already existing condition and giving her a lethal amount sugar.

Analogously, while "curing" the diabetes prior to the injection may have saved
her life, the excessive amount of concentrated sugar would *still* have been a
problem (although not as critical) and was something that shouldn't have been done.

</OT>

Dropping bug since it's fixed.
Flawed analogy. You won't (probably) get arrested by changing a component.
*** Bug 162757 has been marked as a duplicate of this bug. ***
What I was hinting at in comment #96, and I will now become more blatant about
is this. The R, SR and A process should catch those checkins which would cause a
problem with compreg.dat and ensure the patch writer registers the new component
(or change in component) properly.

Yes, I know everyone is busy (I have low-profile patches waiting attention), but
some things need to be high priority. I'd hate to see 1.2final released, and
then have to tell people upgrading from 1.1 to delete a, to them, obscure file
to get Mozilla to work. (Sorta reminds me of the Netscape 6.0 debacle).

Oh well, this has been swept under the rug, so my comments are moot. But, mind
those new bumps in the rug ;-)

well, assuming the problem was just that the installer failed to properly tell
mozilla that it needed to update compreg.dat, then your assertion is wrong.
I will not disagree with Comment #99 because it make sense.  I don't agree with 
comment #101, what everyone need to remember is that you have to be a 
programmer to understand this.  If you're not a programmer than you're only 
seeing it from a different perspective.  It just take a different perspective 
to see this.
please take this conversation to the newsgroups.  
dgk: all that stuff happens automatically... there's nothing for a human to do.
See comment 90.
*** Bug 167422 has been marked as a duplicate of this bug. ***
*** Bug 163204 has been marked as a duplicate of this bug. ***
ktrina / paw, qa-triage as needed.
QA Contact: sairuh → ktrina
Blocks: majorbugs
Re-assigning to ylong for now.  Yuying, can you verify this for international? 
Thanks.
QA Contact: ktrina → ylong
Cycillic (as well as some other languages) characters are showed fine on latest
trunk build with both web contains (CSS...etc) and profile manger.

I'm marking this as verified per i18n point of view.
Status: RESOLVED → VERIFIED
Blocks: CouldNotBeRead
Based on all the Dups in Bug #171441 and the fact that the solution is to delete
COMPREG.DAT, I'm reopening this bug.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Keywords: relnote
Fixed, as per checkin for Bug # 171441.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
No longer blocks: 165459
Same i18n result as in comment #113 on latest build, mark as verified.
Status: RESOLVED → VERIFIED
Keywords: relnote
No longer blocks: majorbugs
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: