Closed Bug 294983 Opened 19 years ago Closed 19 years ago

CZ dialog frame remains empty

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: Peter6, Unassigned)

References

Details

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050519
Firefox/1.0+ ID:2005052013

Open FF
Open CZ
the users frame is populated
it can send
but there is no dialog visable
Confirmed on WinXP as well.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050520
Firefox/1.0+ ID:2005052013
Interesting, as I'm using the following, and it works fine:
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050520
Does anyone actually have the JS error(s) that are presumably occuring?
cz: Initializing ChatZilla {WARNING: String missing from string bundle, file
c:/work/mozilla/anonymous/firefox-test/mozilla/intl/str
res/src/nsStringBundle.cpp, line 281
  'cmd.about.params' missing from bundle
chrome://chatzilla/locale/chatzilla.properties
WARNING: String missing from string bundle, file
c:/work/mozilla/anonymous/firefox-test/mozilla/intl/strres/src/nsStringBundle.cpp,
line 281
  'cmd.about.key' missing from bundle chrome://chatzilla/locale/chatzilla.properties
WARNING: String missing from string bundle, file
c:/work/mozilla/anonymous/firefox-test/mozilla/intl/strres/src/nsStringBundle.cpp,
line 281
  'cmd.about.format' missing from bundle
chrome://chatzilla/locale/chatzilla.properties

etc etc.
Those are not the problem. They are because some fool added a warning for
missing string to the stringbundle code and didn't add a way to check if a
string exists first! (i.e. they are occuring because the strungbundle currently
sucks)
the only other items were:
WARNING: Using nsIGlobalHistory->nsIGlobalHistory2 adapter., file
c:/work/mozilla/anonymous/firefox-test/mozilla/docshell/base/nsGlobalHistory2Adapter.cpp,
line 137
WARNING: NS_ENSURE_TRUE(aContent) failed, file
c:/work/mozilla/anonymous/firefox-test/mozilla/layout/base/nsFrameManager.cpp,
line 342
++WEBSHELL == 5
++DOMWINDOW == 5
WARNING: NS_ENSURE_TRUE(aContent) failed, file
c:/work/mozilla/anonymous/firefox-test/mozilla/layout/base/nsFrameManager.cpp,
line 342
} 2.063 sec
WARNING: getting z level of unregistered window, file
c:/work/mozilla/anonymous/firefox-test/mozilla/xpfe/appshell/src/nsWindowMediator.cpp,
line 635
WARNING: getting z level of unregistered window, file
c:/work/mozilla/anonymous/firefox-test/mozilla/xpfe/appshell/src/nsWindowMediator.cpp,
line 635
cz: Shutting down ChatZilla.

None of which are unexpected (or fixable by CZ). How odd...

Now if only Firefox actually built from current CVS, I would test it...
silver, firefox builds for me from trunk on winxp
I'm waiting for it to try building currently, but the last attempt (2 hours ago)
failed with a problem in nsChromeRegistry.cpp. I have little faith that it's
been fixed since, but we'll see.
Warning: reference to undefined property Components.interfaces.nsICmdLineHandler
Source File: file://.../components/chatzilla-service.js Line: 93
Ok, so someone's screwed this up badly.

We get to:
  http://lxr.mozilla.org/mozilla/source/extensions/irc/xul/content/static.js#2616
and get the content window fine. But cwin.initOutputWindow (which is a function
defined in the output window) is undefined!

I'm guessing from the context this bug was filed, this is all bug 281988's fault.
(In reply to comment #11)
> I'm guessing from the context this bug was filed, this is all bug 281988's fault.
Yeah, the landing of the second part, on the 20th
OS: Windows 2000 → All
Hardware: PC → All
The last patch in bug 294960 seems to fix this for me.
Depends on: 294960
Will that also fix the case where ChatZilla has a file: HTML page loaded into
the frame instead of the default chrome: one?
(In reply to comment #13)
> The last patch in bug 294960 seems to fix this for me.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050521
Firefox/1.0+ ID:2005052104

Not for me, I tried 3 builds after 294960 landing to rule out a bad one.
No luck, doesn't work
Peter,

I think he is referring to a patch that has not been checked in yet.. still
awaiting review
(In reply to comment #16)
> Peter,
> 
> I think he is referring to a patch that has not been checked in yet.. still
> awaiting review
I should have read all of 294960 , my bad


Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050521
Firefox/1.0+ ID:2005052108

->WFM

thanks Boris
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050521
Firefox/1.0+ ID:2005052108

CZ's dialog frame is populated, but messages are missing:
I'm not seeing people enterering and leaving a channnel
last comment was unrelated
->RESOLVED/FIXED
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Did you, you know, *test* file: output windows like I asked about in comment 14?
(In reply to comment #21)
> Did you, you know, *test* file: output windows like I asked about in comment 14?

No, a link still opens in chrome i/o a new tab or window
But that bug has been there for ages.
This bug was just for the regression caused by bug 281988


*bzzzzt*

The page loaded into the browser in CZ can be customised. Some people use that
feature, which would mean there is a file: URL page loaded into it, instead of
chrome:
I am also seeing messages like: Couldn't convert chrome URL:
chrome://communicator/content/contentAreaUtils.js

This also effects venkman, mail, viewsource. See
<http://lxr.mozilla.org/mozilla/search?string=contentAreaUtils.js>. bsmedberg,
how should we be handling these issues?
Ok, it seems we can play with the content window reasonably well post-patch,
however frame.contentWindow.location is throwing a small fit when we try and
access it, which *is* a problem (although functionally things still work).

I guess that can be spin off into another (*sigh*) bug...
> I am also seeing messages like: Couldn't convert chrome URL:
> chrome://communicator/content/contentAreaUtils.js

The only contentAreaUtils.js in Firefox (at least that I can see) is
chrome://global/content/contentAreaUtils.js.

(In reply to comment #25)
> Ok, it seems we can play with the content window reasonably well post-patch,
> however frame.contentWindow.location is throwing a small fit when we try and
> access it, which *is* a problem (although functionally things still work).
> 
> I guess that can be spin off into another (*sigh*) bug...

Is this filed?  What are the symptoms of that "small fit"?

/be


Not yet, I'm busy organising a new PC... the small fit is just an exception,
which says something about security. 
IIRC frame.docShell.currentURI retrieves the location (as an nsIURI).
(In reply to comment #25)
>frame.contentWindow.location is throwing a small fit when we try and access it
Is that the same as bug 295040?
Not quite, it throws a 'security error' exception IIRC. And I found
frame.webProgress.currentURI works instead.
James filed bug 295122 on the location exception he's seeing.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.