Closed Bug 57231 Opened 24 years ago Closed 23 years ago

Cookie warning dialog is modal, but does not block reloading

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 60150
Milestone:
mozilla1.0

People

(Reporter: jrgmorrison, Assigned: danm.moz)

References

(
URL
)

Details

(Keywords: crash, topembed) 

Overview Description: 

  The cookie confirmation/warning dialog is modal, but does not 
  block the main execution thread while the modal dialog is up.

  This means that a page (e.g. home.netscape.com) that does a timed
  reload will be allowed to do that reload while the dialog is
  up. This results in a second modal dialog concurrently presented to
  the user (when cookie warning is turned on), and eventually another
  reload, another dialog, another reload, another ...

  I encountered this by accident, when I turned on the cookie warning 
  pref to check an unrelated skins bug, and then left my Mac pointed
  to home.netscape.com.

  When you cancel out of the dialogs, eventually you will crash.

Steps to Reproduce: 
0) enable the pref for cookie warning.
1) I have a testpage to shorten the time to reproduce (source below)
     http://jrgm.mcom.com/adhoc/cookie-set-and-reload.html
   Point the browser at that web page, and let 6 or 7 dialogs come up
   (takes 10sec per dialog). Then try to cancel out.


Actual Results:   crash, mac/linux/win32
Expected Results: block reloading while a modal dialog is up

Reproducibility: 100% mac/linux/win32

Build Date & Platform Bug Found: 
   20001019nn linux branch MN6
   20001019nn mac branch MN6
   20001019nn win32 branch MN6

Additional Information: 
 Since surfing the web approaches impossible with this warning dialog 
 enabled, I would have to rate this as an unlikely scenario (but I 
 did hit this crash in my normal test usage of the browser; I didn't 
 go looking for this crash). 

 [Gee, I remember the days when cookies were new, and it was both an
 end-user privacy benefit, and kind of interesting to let it remind 
 you on the occasional time that a Cookie was set. Now, some sites
 will set more than 20 cookies on a single page. Oh, well.]


 Test case:

<html>
<head>
<META HTTP-EQUIV=REFRESH CONTENT="10; 
URL=http://jrgm.mcom.com/adhoc/cookie-set-and-reload.html">
<script type="text/javascript" language="javascript">
<!--
var expires = new Date();
expires.setTime (expires.getTime() +  24*60*60*1000);
var ckname = "ck" + expires.getTime();
function mmmCookie() {
   window.status = "clearing window.status";
   //dump("ckname = " + ckname + "\n");
   document.cookie = ckname + "= foobar" + "; expires=" + 
expires.toGMTString();
   window.status = "Past the document.cookie call";
}
// -->
</script>
</head>
<body onload="mmmCookie();">
  <p>This page sets a cookie each time it is loaded. It will reload itself in 
10 seconds. </p>
  <p>Set your prefs to warn for cookies, and leave the browser up for a 
while.</p>
</body>
</html>
Keeping the warning dialog on at all time might not be that unusual in 6.0, now 
that we have cookie management (ability to accept/reject all cookies from a 
single site in one fell swoop).  In fact, it's the warning dialog that makes 
cookie management possible.  So this bug might not be as unlikely as you made it 
out to be.

I'd love to get it fixed for 6.0, but I know that it's too late to even consider 
that for this bug.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
Target Milestone: M19 → M20
Summary: Cookie warning dialog is modal, but does not block reloading → [x]Cookie warning dialog is modal, but does not block reloading
Target Milestone: M20 → ---
Dan, sounds like another example of bug 60280/60150
Assignee: morse → danm
Status: ASSIGNED → NEW
Component: Cookies → Event Handling
Target Milestone: --- → mozilla1.0
Summary: [x]Cookie warning dialog is modal, but does not block reloading → Cookie warning dialog is modal, but does not block reloading
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → ---
Depends on: 60150
Target Milestone: --- → Future
Should this really be "future"?  Since it leads to a crash I would think it 
should be addressed before 1.0.
My carefully culled <= 1.0 bug list is already getting laughable, but I'll put
it in with 60150 for now.
Target Milestone: Future → mozilla0.9.9
Keywords: topembed
Keywords: nsbeta1
Target Milestone: mozilla0.9.9 → mozilla1.0
shouldn't this just be a dupe of 60150 or the other way around? they seem the
same to me.
yes, this does sound like a dupe of bug 60150. Resolving as a dupe.

*** This bug has been marked as a duplicate of 60150 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: crash
Resolution: --- → DUPLICATE
verified dupe
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.