Closed Bug 12728 Opened 25 years ago Closed 25 years ago

Cookie nag dialog comes up empty

Categories

(SeaMonkey :: UI Design, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 13032

People

(Reporter: morse, Assigned: danm.moz)

References

()

Details

Set prefs to "warn before accepting cookies".  This is difficult to do right now
because that pref suddenly disappeared from the preference panel (bug 12724) but
you can still set it manually with

   user_pref("network.cookie.warnAboutCookies", true);

Then go visit a site that sets cookies.  The home.netscape.com site is as good
as any.  A dialog appears but it is transparent -- there is nothing in it and
you still see the screen that was below it.  Furthermore, dismissing this dialog
causes the crash shown below.

This used to be subsumed by bug 12137 and so was never filed as a separate bug
report.  But 12137 is now fixed, yet this bug still occurs.  That is why this
new report is now being filed.


NTDLL! 77f76274()
nsWindow::Create(nsWindow * const 0x030b75c4, nsIWidget * 0x00000000, const
nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x025a3a9d HandleEvent(nsGUIEvent
*), nsIDeviceContext * 0x02cea4b0, nsIAppShell * 0x00000000, nsIToolkit *
0x00000000, nsWidgetInitData * 0x00000000) line 655
nsView::CreateWidget(nsView * const 0x030b7760, const nsID & {...},
nsWidgetInitData * 0x00000000, void * 0x00000000, int 1) line 1241
DocumentViewerImpl::MakeWindow(void * 0x00000000, const nsRect & {...},
nsScrollPreference nsScrollPreference_kAuto) line 887 + 34 bytes
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x030b65a0, void *
0x00000000, nsIDeviceContext * 0x02cea4b0, nsIPref * 0x00a88aa0, const nsRect &
{...}, nsScrollPreference nsScrollPreference_kAuto) line 394
nsWebShell::Embed(nsWebShell * const 0x02d2f1a0, nsIContentViewer * 0x030b65a0,
const char * 0x030774b0, nsISupports * 0x00000000) line 968 + 69 bytes
nsDocumentBindInfo::OnStartRequest(nsDocumentBindInfo * const 0x03077820,
nsIChannel * 0x030889e0, nsISupports * 0x00000000) line 2094 + 36 bytes
nsChannelListener::OnStartRequest(nsChannelListener * const 0x03088fe0,
nsIChannel * 0x030889e0, nsISupports * 0x00000000) line 2386 + 34 bytes
nsFileChannel::OnStartRequest(nsFileChannel * const 0x030889ec, nsIChannel *
0x030889e0, nsISupports * 0x00000000) line 798
nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x03088110)
line 207
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03088114) line 144 + 12 bytes
PL_HandleEvent(PLEvent * 0x03088114) line 509 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00b1dce0) line 470 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x04100376, unsigned int 49404, unsigned int 0,
long 11656416) line 938 + 9 bytes
USER32! 77e71268()
00b
*** Bug 12857 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Bug 13032 is actually a duplicate of this one.  But I'm marking this one as the
dup for two reasons -- (1) the discussion in 13032 actually describes the reason
for the failure and presents a work-around, and (2) 13032 is assigned to davidm
who is the right person to actually fix this.

*** This bug has been marked as a duplicate of 13032 ***
Status: RESOLVED → VERIFIED
Changing component to XP Apps. (HTML Dialogs is going away.)
Component: HTML Dialogs → XPApps
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.