Dialogs are never reasonable toplevel widgets for clipboard purposes. Since currently there's no way to tell in nsWindow::CreateNative whether we're creating a dialog or a real toplevel window (both have parent==0), we'd be better off not resetting the toplevel widget and keeping it pointing to the first window brought up (and hoping the user doesn't dismiss that one). I have a simple fix for this in my tree (in nsClipboard::SetTopLevelWidget, don't reset if we already have mWidget, and also do some sanity checking on the widget passed in to make sure it has a window) and would like to check it in for M5. The long-term fix is to have a permanent invisible widget; mcafee already has a bug to make this happen.

M5.

A fix has been checked in for M5, which should get us by until the permanent-invisible widget is up.

akkana, is there some way i can verify this, or should i just mark it verified?

Procedure for reproducing: Bring up browser or editor window. Select something, copy (control keys seem to be broken in the current build so you'll probably have to use the Edit menu), paste somewhere else to verify that copy/paste work. Now bring up a dialog and dismiss it. Try copy/paste after dismissing the dialog. If it still works, this bug is fixed; if not, the bug isn't fixed. Don't bring up/dismiss any top level windows during this test, and make sure you're using the first window brought up; these will still break the clipboard a lot of the time, until mcafee or pavlov implements the hidden toplevel window (filed as a separate bug).

*** This bug has been marked as a duplicate of 5336 ***

Verified Dup