128858 - for (c in Components.classes) regressed

Status: VERIFIED FIXED

(Core :: XPCOM, defect)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020223
BuildID:    2002030415

The component viewer does not work for me in recent builds. The interface and
component lists are empty, and I get a JS error in the JS console:

Error: undefined has no properties
Source File: chrome://cview/content/cview-outliners.js
Line: 51

Reproducible: Always
Steps to Reproduce:
1. Tasks|Tools|Component Viewer
2.
3.

Actual Results:  lists are empty

Expected Results:  shown the components and interfaces in the lists

Comment 1

[Samuel Sieb]

This is because you can't do keys(Components.classes) anymore for some reason.

Comment 2

[Samuel Sieb]

I don't understand what "qawanted" means in this case.

Comment 3

[Robert Ginda]

We can't enumerate classes anymore, this is bad.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

ssieb: sairuh added the keyword when changing the qa contact to nobody, probably
to indicate that somebody should become qa contact for this bug

Comment 5

[David Bradley]

I believe this is due to jband's recent changes. I'm looking into it to make
sure, but I'm having problems with my build right now, and I thought maybe John
might know off the top of his head.

Comment 6

[David Bradley]

Sorry, I meant to say the recent changes concerning the inteface manager for
supporting SOAP

Comment 7

[John Bandhauer]

No. This is a regression from dougt's change to nsComponentManager to add
nsIComponentRegistrar. He has an enumerator that does both
nsIBidirectionalEnumerator and nsISimpleEnumerator. His mistake (I reviewed) was
to use NS_REINTERPRET_CAST where he should have used NS_STATIC_CAST. So the
callers to the functions that expect the nsISimpleEnumerator interface get the
nsIBidirectionalEnumerator interface instead. And *that* means that their calls
on those object get routed to the *wrong* methods! We are 'luck' this does not
crash.

I'll attach a patch that fixes this.

Let's try to get this into 0.9.9 if it is not too late.

Comment 8

[John Bandhauer]

Attachment: proposed fix

Comment 9

[John Bandhauer]

Oops, the patch includes a changed line to avoid the annoying shutdown warnings.
That need not get checked in (but *I* wouldn't mind).

Comment 10

[Robert Ginda]

Comment on attachment 72505 [details] [diff] [review]
proposed fix

r=rginda on the whole enchilada.  I agree that this should make 0.9.9.

Comment 11

[David Bradley]

Thanks John. Then my build wasn't screwy. I wasn't sure if the fact different
methods were actually getting invoked was due to my build being busted or was
the actual problem, and was in the middle of doing a clobber to find out for
sure. Yes, very lucky this only prematurely terminates the enumeration.

Comment 12

[Robert Ginda]

dbradley, why not shoot for 0.9.9?

Comment 13

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 72505 [details] [diff] [review]
proposed fix

sr=shaver.  (I won't miss that shutdown spam, but then I wouldn't miss the
XPConnect flattening spam either. =) )

Comment 14

[John Bandhauer]

Looks like dougt is not around. I'll take this one.
shaver: you can turn off the xpconnect flattening spam anytime you want.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 72505 [details] [diff] [review]
proposed fix

a=dbaron for 0.9.9 branch and trunk

(although you shouldn't need any cast at all to cast to a base class)

Comment 16

[John Bandhauer]

Fix checked in to trunk and branch.

Comment 17

[Phil Schwartau]

Trying to verify this with Mozilla trunk builds from today, 2002-03-05.

My Linux build doesn't even launch; forget about that one. 
On WinNT and Mac, I went to http://www.hacksrus.com/~ginda/cview/
and installed Component Viewer. Is this the latest version?

When I brought up Component Viewer in yesterday's binary (before the
fix for this bug went in), Component Viewer came up blank of information,
and I saw the reported error in the JS Console.

With today's builds, there is no JS Console error, and the Component Viewer
shows correct-looking totals in the headers at the top:

     "All components (952/952)"       "All interfaces (1026/1026)"

However, the body of the window is blank. I assume this is due to some
error in my installation of Component Viewer. I seem to be missing the 
widget that's supposed to display individual items - (?)

I'm going to go ahead and provisionally mark this one Verified,
since with yesterday's builds, I had this at the top instead of
correct numbers:

            "Components..."          "Interfaces..."

plus the error in the JS Console -

Christian, could you double-check me on this? If you see anything
wrong with this in current builds, could you please re-open this bug?

If anyone else knows what I did wrong in installing Component Viewer,
please let me know; either here or via direct email; thank you - 

Comment 18

[Phil Schwartau]

Another approach to verification:

<SCRIPT>
  netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');

  var i = 0;
  for (var obj in Components.classes)
    i++; 

  alert(i);
</SCRIPT>


With yesterday's build, this gave me "0".
With today's build, it gives me "953".

Comment 19

[Robert Ginda]

cview from the tree works for me.  Possibly the xul in the version on
hacksrus.com is out of date.

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

ok. component viewer works fine for me now!
Thanks for fixing this so fast!