36097 - cancelling open dialog causes button to fail to trigger after css hiding and showing.

Status: RESOLVED WORKSFORME

Description

[andreww]

This is somewhat involved but can be replicated 100% and is cross-platform:
From scopus bug 392023:

Clicking between Online and List Setup tabs fails to open dialogs
Must follow testcase to see problem.

Saw it on all platforms:
Mac 2000-04-12-10 M16
Win32 and Linux 2000-04-12-11 M16

1)Start seamonkey and login to IM via Tasks-->IM.
2)When the buddy list appears, click on the List Setup tab. Then click on Add 
Buddy. Cancel the dialog that appears for the Add Buddy icon.
3)Now Click on the Online tab.
4)Now click again on the List Setup tab. Click on Add Buddy icon to invoke the 
dialog again.

Actual results: The Add Buddy icon fails to launch the appropriate dialog at 
all. Nothing happens when you click the buttons. Same holds true if you tried 
this with "Add Group".
Notes: Problem seems to occur for any task bar item that is "Cancelled" in IM, 
as it also occurred for the "Find a Buddy" dialog when I cancelled that and went 
back and forth between the List Setup and Online tabs again afterwards, and 
tried to reinvoke that.

Comment 1

[andreww]

Noticed that the window doesnt have to be "cancelled", all that has to happen is 
the js associated with the button has to be called once. Then afterwards if that 
button is hidden and shown, the js no longer seems to be called onclick. (no 
error shows up in the console)

Comment 2

[andreww]

I think I found the core of this problem - in AIM we use display:none to toggle 
the view state of these buttons. When I change this to visibility:collapse - I 
dont get the loss of js functionality. So it looks like if you have a button, 
with js assocated with it. If you destroy and re-create it (going from 
display:none to display:block) the js originally associated with the button gets 
lost.

Comment 3

[Dan M]

Chris? Any interest in this one?

Comment 4

[andreww]

Note that you will need older builds (from the time of the bug reporting date) to 
replicate this - since I implemented a workaround for AIM - where instead of 
display:none we use visibility:collapse which doesnt destroy the frames and seems 
to work.

Comment 5

[saari (gone)]

Yup, joki and myself talked about this problem. He has a better grasp of this 
problem than I do, so I'm giving it to him.

Comment 6

[joki (gone)]

I'm marking this future, as much as anything because I don't have time to go 
back and try to recreate a test case if this isn't actually hitting us right 
now.  If someone can give me a test case I'll look at this further for this 
release.

Comment 7

[Andreas Kunz]

There is no Instant Messenger in Mozilla anymore.
For a long time.
-> INVALID?

Comment 8

[John Morrison]

Well, the point of the bug wasn't about AIM, but about a problem in XUL. 
However, I think this isn't a problem any more, so WFM.