Closed
Bug 12728
Opened 25 years ago
Closed 25 years ago
Cookie nag dialog comes up empty
Categories
(SeaMonkey :: UI Design, defect, P3)
Tracking
(Not tracked)
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
Reporter | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 2•25 years ago
|
||
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 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 3•25 years ago
|
||
Changing component to XP Apps. (HTML Dialogs is going away.)
Component: HTML Dialogs → XPApps
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•