Adding a new pane locks up user interaction after clicking OK

VERIFIED FIXED in M17

Status

SeaMonkey
Sidebar
P1
critical
VERIFIED FIXED
18 years ago
14 years ago

People

(Reporter: Mike Pinkerton (not reading bugmail), Assigned: Chris Waterson)

Tracking

Trunk
PowerPC
Mac System 9.x

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dogfood+][nsbeta2+] fix in hand)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
- 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.
(Reporter)

Comment 1

18 years ago
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

Comment 2

18 years ago
Putting on [dogfood+] radar.  Reassigning to rjc.
Assignee: slamm → rjc
Whiteboard: [dogfood+][nsbeta-]

Updated

18 years ago
Whiteboard: [dogfood+][nsbeta-] → [dogfood+][nsbeta2+]

Comment 3

18 years ago
Don, please assign this to someone who has a chance in h*ll of fixing it...
Assignee: rjc → don

Comment 4

18 years ago
Well, since pchen doesn't have a bugzilla account yet ... I'll hold on this for
awhile.
Priority: P3 → P1
Target Milestone: --- → M16

Comment 5

18 years ago
Just tried to recreate bug on nightly builds 6/6/00 M16 and 6/8/00 M17 and
cannot reproduce this bug.

Comment 6

18 years ago
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?
(Reporter)

Comment 7

18 years ago
i can get it to lock up also by deleting the panel that is currently visible.

Comment 8

18 years ago
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?

Comment 9

18 years ago
At last, I could finally recreate this problem. (2000060908)

Comment 10

18 years ago
This is XP, I see it on a Win2K build from Wed. I think

Comment 11

18 years ago
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
(Assignee)

Comment 12

18 years ago
taking
Status: NEW → ASSIGNED
Target Milestone: M16 → M17
(Assignee)

Comment 13

18 years ago
An nsJSEventHandler is running with an mContext member that points to garbage. 
Whee.
(Assignee)

Comment 14

18 years ago
Created attachment 10227 [details] [diff] [review]
proposed fix
(Assignee)

Comment 15

18 years ago
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.
(Assignee)

Updated

18 years ago
Whiteboard: [dogfood+][nsbeta2+] → [dogfood+][nsbeta2+] fix in hand
(Assignee)

Comment 16

18 years ago
fix checked in, r=shaver
(Assignee)

Comment 17

18 years ago
no really! it's fixed!
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 18

18 years ago
verified fixed. (2000062108)
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

Updated

14 years ago
OS: Mac System 9.x
You need to log in before you can comment on or make changes to this bug.