21647 - [BETA] locale/chrome.rdf hangs or causes funky window

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[tao]

I tested dec-10-99 mozilla build and dec-13-99 commercial build on NT. It does
 not crash anymore; instead, when a chrome.rdf presents in a locale/ directory,
the first attempt to bring up the affected window (e.g. Addressbook) will
cause a funky browser frame to pop up with an oversized canvas/pixmap.
If you close this funky window and reopen it (Addressbook) again, the new
window will just render fine with the proper localized UI.

On Linux w/ dec-13-99 commercial build, this causes the client to hang.

To reproduce this problem, create a chrome.rdf w/ the following content

  <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns="http://chrome.mozilla.org/rdf#">
      <RDF:Description about="chrome://addressbook/locale/">
        <name>en-US</name>
      </RDF:Description>
  </RDF:RDF>

and drop it into chrome/addressbook/locale.

Then, open up the Mozilla client and then the Addressbook window. On NT,
the funky window shows up (for the first attempt). On Linux, it simply
hangs the client.

This is a L10n blocker.

Comment 1

[msanz]

Adding beta to the summary

Comment 2

[rickg]

David -- I think this is an issue you can deal with better than I can.

Comment 3

[Peter Trudelle]

reproduced hang in today's build on Linux. targetting p1 for m13. rewrote
summary to fit field and emphasize the hang.

Comment 4

[Henrik Lynggaard Hansen]

Adding myself to the CC list as im dependent on this bug

Comment 5

[tao]

Add Laura to the CC list. This is a L10n blocker.

Comment 6

[tao]

Hi, Hyatt:

This is a localization blocker and we plan to localize beta1. Is it possible
that we fix this by M14. Marking it M15 is making me nervous.

Do we have a clue of the root cause of this problem yet? I can spend some cycles
on this if you don't have bandwidth.

Comment 7

[leger]

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.

Comment 8

[David Hyatt]

I tested this using the addressbook and specifying a chrome.rdf file for all 
three cases (skin, locale, and content).  In all three cases if the files were 
found in the location specified by chrome.rdf, then the window came up just fine 
on the very first try.

I tried the exact RDF file pasted into the bug below, and it worked just fine.

Marking as WORKSFORME.

Comment 9

[tao]

Which day's build you are running? I just tested it with 2000-01-21-09 NT 
commercial build (2000012108). On this first attempt of 
opening the Addressbook, a huge bogus frame popup with ghost shadow in it.
I needed to close the window and reopen the addressbook again to have the 
correct rendering of the whole frame with content. This is exactly what I 
observed on NT in logging the bug.

I haven't tested it on Linux yet. But, reopen the bug, anyway.

Comment 10

[tao]

Hyatt:


Could it be a memory corruption such as un-initialized memory references? Since
it behaved differently platforms and probably different development. The bug
might not surface in your development build.

Comment 11

[David Hyatt]

I tried the exact test you supplied and verified that the chrome.rdf file is 
being used, and everything works fine for me.  Weird.  You aren't testing chrome 
switching or anything, are you?  You're just putting the file in the directory, 
launching the app, and experiencing trouble?

Comment 12

[David Hyatt]

Darnit, I guess it's probably occurring in optimized builds only?

Comment 13

[tao]

No, plain chroome.rdf with en-US as the locale provider.

Comment 14

[David Hyatt]

Ok, I'm running Win98, so maybe it's different from NT.  Let me try this on some 
other platforms (debug and optimized) so we can get a tally of which ones work 
and which ones don't.

Comment 15

[David Hyatt]

Tao, do me a favor.  Try using a chrome.rdf in skin.  See if those work for you. 
 You should be able to replace "locale" with "skin", and "en-US" with "default". 
 Then just move the file over to chrome/addressbook/skin.

This worked for me also.  Let me know if it works for you or not.  If it does 
work for you, I suspect something to do with DTD/XML parsing.  IF it doesn't 
work for you, I suspect the chrome registry.

Comment 16

[tao]

Skin is fine.

Comment 17

[tao]

Hi, Hyatt:


The configurable chrome works fine on WIN98. Now we know the skin portion works on NT. 
I remember that the URL chrome conversion also works. Guess the only thing suspecious is
 XML/DTD parsing.  I'll try to purify it on NT tomorrow to see if I can catch some abnomalty.

Comment 18

[tao]

I ran a purify session on a 01-14-2000 Mozilla build on NT. I didn't see any
memory corruption incidence appeared in opening up Addressbook. However, I hit
an assertion ("Reflowing tree row group with unconstrained height!!!!") at
http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsTreeRowGroupFrame.cp
p#992. 

This is consistent with the bogus frame rendered with enormous huge height. Any 
idea who owns layout reflow? Is it vidur?


Thanks.

Comment 19

[tao]

Another thing I observed is that nsTreeRowGroupFrame::ReflowBeforeRowLayout()
did not get called before the bogus frame poped up; it does when Addressbook 
chrome is rendered properly. Hope that this helps.

Comment 20

[David Hyatt]

Ok, this seems to fail practically everywhere.  It doesn't appear to have 
anything to do with the chrome registry. I believe it's a parser problem.  
Reassigning to nisheeth.

Comment 21

[tao]

Yes, this bug appears whenever there is a chrome.rdf in 
any chrome/[package]/locale; it's not an Addressbook specific problem.

One question I have is: 

     what is the sequence of chrome.rdf loading and the external *.dtd. 

In theory, the former shall goes first and then the latter 
(sequentially). Also, the cache of that particular DTD shall be blown.

It's interesting that the first attempt always fails but not the 
subsequent ones.
away.

Comment 22

[David Hyatt]

The parser may not be re-entrant here or something, e.g., the parser of the XUL 
doc is wanting to load a DTD, but it now has to parse an RDF/XML file 
synchronously first.  Only once that file is parsed can the chrome registry give 
the DTD name.  

Comment 23

[tao]

But, how's this different from loading chrome/registry.rdf? Isn't it just a RDF
datasource?

 

Comment 24

[David Hyatt]

registry.rdf was originally loaded up front when the first XUL file was loaded 
(and we know that works).  

The new scheme is lazier, i.e., it waits until a request comes in and loads a 
little fragment file (chrome.rdf) instead.  So this is the first time that an 
RDF file is being loaded synchronously when the parser is in a mode where it's 
trying to load a DTD.
 

Comment 25

[tao]

Add Vidur to cc list.

When beta localization is done, all chrome/[package] directories, including 
global, prefs, xpinstall, navigator, etc...,  will have a "chrome.rdf" in their 
locale/. I suppose this implies a localized Mozilla client will not even start!

Is this going to be big fix in the parser side? If so, is there a walkaround 
inbetween the parser modoule and chrome registry?

Comment 26

[Nisheeth Ranjan]

The XML tokenizer was using static data and was not re-entrant.  I have code in 
my tree that makes it re-entrant.  I'll check it in once I have it tested 
properly by the end of this week.

Comment 27

[tao]

Hi, Nisheeth:


Mind if I have a sneak preview on the re-entrant patch? I'd like to see how it
works with the new configurable chrome scheme.


Thanks

Comment 28

[Nisheeth Ranjan]

The changes are on my tree at home.  I'm debugging an assertion that fires in 
the XBL service when it loads up the bindings file.  Once I get that debugged, 
I'll attach the patch to this bug report before continuing to test it.

Comment 29

[Nisheeth Ranjan]

I found the bug in my changes.  I've run the precheckin tests and everything 
looks good.  I need a code reviewer for my change, please.  I'm attaching the 
patch...

Comment 30

[Nisheeth Ranjan]

Attachment: Patch to the Expat tokenizer

Comment 31

[tao]

I applied the patch to a fresh tree pulled this afternoon. It built on both 
Linux and NT fine. 

However, dropping the chrome.rdf to locale/ does not affect the chrome URL 
conversion any more. Mozilla always pick up uses the files in en-US directories.

Comment 32

[tao]

I installed a 2000-01-27-09-M14 Mozilla build on my NT. The problem described
in the summary field still persists.

With the patch, the bug did not appear in my debug tree; however, the chrome.rdf
does not cause Mozilla to pick up files from different directoy either.

What's missing now?

Comment 33

[Nisheeth Ranjan]

I just checked in the fix...

Comment 34

[David Hyatt]

All right.  Just in time for me and warren to rework the chrome registry yet 
again, making chrome.rdf obsolete. ;)

Comment 35

[Nisheeth Ranjan]

I'm markign this bug fixed.  Tao, please open a new one to track the problem you 
are having.  Thanks.

Comment 36

[tao]

Hi, Nisheeth:


I tried again after some email exchanges wth Hyatt. It does work, now. Sorry 
for the fuss!

Comment 37

[Paul MacQuiddy]

marking verified per tao's comments