Closed Bug 21647 Opened 25 years ago Closed 25 years ago

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

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: tao, Assigned: nisheeth_mozilla)

References

Details

Attachments

(1 file)

Patch to the Expat tokenizer
19.17 KB, patch
Details | Diff | Splinter Review 
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.
Summary: Dropping chrome.rdf into locale/ causes funky new window on Windows and hang on Linux → [BETA] Dropping chrome.rdf into locale/ causes funky new window on Windows and hang on Linux
Adding beta to the summary
Assignee: rickg → hyatt
David -- I think this is an issue you can deal with better than I can.
Priority: P3 → P1
Summary: [BETA] Dropping chrome.rdf into locale/ causes funky new window on Windows and hang on Linux → [BETA] locale/chrome.rdf hangs or causes funky window
Target Milestone: M13
reproduced hang in today's build on Linux. targetting p1 for m13. rewrote
summary to fit field and emphasize the hang.
Adding myself to the CC list as im dependent on this bug
Blocks: 11652
Status: NEW → ASSIGNED
Target Milestone: M13 → M15
Add Laura to the CC list. This is a L10n blocker.
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.
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
Target Milestone: M15 → M14
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.


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?
Status: REOPENED → ASSIGNED
Darnit, I guess it's probably occurring in optimized builds only?

No, plain chroome.rdf with en-US as the locale provider.
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.
Whiteboard: Works on Win98 debug. Testing other platforms.
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.

Skin is fine.
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.
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.
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.
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.
Assignee: hyatt → nisheeth
Status: ASSIGNED → NEW
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.

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.  

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

 
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.
 
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?
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.
Status: NEW → ASSIGNED
Whiteboard: Works on Win98 debug. Testing other platforms.
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
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.
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...

    
    

    
  
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.



    
    

    
  
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?

    
    

    
  
I just checked in the fix...


    
    

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


    
    

    
  
I'm markign this bug fixed.  Tao, please open a new one to track the problem you 
are having.  Thanks.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED

    
    

    
  
Hi, Nisheeth:


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

    
    

    
  
marking verified per tao's comments
Status: RESOLVED → VERIFIED

    
  
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: paulmac → xptoolkit.widgets

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: