143963 - The Chatzilla nick dialog displays in the wrong location

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Thomas Deniau]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc2)
Gecko/20020510
BuildID:    2002051005 

(1.0 RC2)


The Chatzilla window that asks for a nick appears at the top left of the screen
(so the top of the window is masked). It should appear as a modal dialog in the
center of the screen or as a sheet in the Chatzilla or in the browser window. 

Reproducible: Always
Steps to Reproduce:
Click on any irc:// link

Comment 1

[Greg K.]

Thomas, can you still reproduce this problem using a more current build? If so,
can you reproduce this problem using another Mozilla user profile?

Comment 2

[Thomas Deniau]

Confirmed using 2002100403 and 1.1, in my current profile and in a new one.
It's even worse now : you can't even change your nick and you have to click 5/10
times on cancel/ok to get the popup to close. 
It's completely buggy. 

Comment 3

[Thomas Deniau]

Additional note : 
- when you type an irc:// url in the url bar, the dialog that asks for a nick is
not in the right place (should appear as a sheet or as a modal dialog). But you
can change the nick and click on OK.

- when you click on a irc:// link, there is the problem too but this time you
can't even change the nick or close the window properly.

I've never tried on Win.

Comment 4

[Greg K.]

Confirmed using FizzillaCFM/2002100308 on 10.1.5. Clicking an IRC link in the
browser displays the "Choose a Nick" dialog sheet, but the sheet descends from
the top left corner of the screen.

Comment 5

[James Ross]

Ok, I think this (if it still happens) is because the dialog is opened before
the window has finished onload, and thus before it's visible.

Comment 6

[James Ross]

This actually happens on Windows too. :)

Comment 7

[Samuel Sieb]

Could we just wait until the main window is opened?  Is it possible to know when that is?

Comment 8

[James Ross]

That's pretty much my fix in 0.9.68.6 (though it has more extensive changes to window events too). I simply made it call init() from a setTimeout in onload, so that the window appears *then* everything is loaded.

For this bug, only the processStartupURLs (and later code) really needs that delay, though.

Comment 9

[Samuel Sieb]

Attachment: move startupurls to after init

Comment 10

[Samuel Sieb]

Attachment: simpler patch

Comment 11

[James Ross]

Comment on attachment 201191 [details] [diff] [review]
simpler patch

r=silver

Comment 12

[Samuel Sieb]

checked in