Closed
Bug 36097
Opened 24 years ago
Closed 22 years ago
cancelling open dialog causes button to fail to trigger after css hiding and showing.
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: andreww, Assigned: joki)
Details
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.
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)
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.
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•24 years ago
|
||
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.
Assignee: saari → joki
Assignee | ||
Comment 6•24 years ago
|
||
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.
Target Milestone: --- → Future
Comment 7•22 years ago
|
||
There is no Instant Messenger in Mozilla anymore. For a long time. -> INVALID?
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Comment 8•22 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•