- launch mozilla - open the sidebar - pick the "add:customize" - add a panel - click ok expected results: - normal usage actual results: - the application no longer receives any events. Clicks in windows, titlebars, or the menubar are ignored. Typing does nothing. However, you can switch to other applications (sometimes). The only way to exit the app is to force quit it.
nominating for the usual... one note, I get a lot of "assertion failed me == CurrentThreadId() at jslock.c:714" asserts, and the panel is added successfully.
Keywords: dogfood, nsbeta2
Summary: Adding a new pane locks up user interaction when clicking OK → Adding a new pane locks up user interaction after clicking OK
Putting on [dogfood+] radar. Reassigning to rjc.
Assignee: slamm → rjc
Don, please assign this to someone who has a chance in h*ll of fixing it...
Assignee: rjc → don
Well, since pchen doesn't have a bugzilla account yet ... I'll hold on this for awhile.
Priority: P3 → P1
Target Milestone: --- → M16
Just tried to recreate bug on nightly builds 6/6/00 M16 and 6/8/00 M17 and cannot reproduce this bug.
I cannot add a panel at all in M17 builds.(bug 36657) andI cannot see the UI getting locked up on M16 build. Could you pls check this again, mike?
i can get it to lock up also by deleting the panel that is currently visible.
Paul sez that the lockup only happens if you delete the currently viewied panel, i.e. what's visible in the sidebar. Does anyone know when this problem first appeared?
At last, I could finally recreate this problem. (2000060908)
This is XP, I see it on a Win2K build from Wed. I think
Reassigning to waterson. if you look at customize.js there is a function called refresh_all_sidebars which asserts and then unasserts on idebarObj.datasource. This seems to cause a reload of sidebar once the customization dialog is closed, but it also seems to make JS very unhappy about what thread it is executing on. If we remove the assert and unassert calls, and replace them with var sidebarbox = window.opener.document.getElementById("sidebar-panels"); var ref = sidebarbox.getAttribute("ref"); sidebarbox.setAttribute("ref",ref); then we don't hit the JS assert, but sidebar does not update correctly. Closing and reopening the sidebar from the view menu causes the proper refresh. This is pretty much all I know :-). Thanks waterson!
Assignee: don → waterson
Status: NEW → ASSIGNED
Target Milestone: M16 → M17
An nsJSEventHandler is running with an mContext member that points to garbage. Whee.
dom gurus: looking for some r=, see proposed fix, attached above. The change is to hold on to the nsIScriptContext instead of raw JSContext: this ensures that it doesn't "go away" from beneath us. What I was seeing here is that an event handler gets installed from a JSContext that is being clobbered. There is a lot of IFRAME juggling going on here.
Whiteboard: [dogfood+][nsbeta2+] → [dogfood+][nsbeta2+] fix in hand
fix checked in, r=shaver
no really! it's fixed!
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verified fixed. (2000062108)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.