Closed
Bug 36097
Opened 25 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•25 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•25 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
•