128697 - have to restart to get "cookie" prefs in Scripts and Windows working

Status: VERIFIED FIXED

(Core :: Security: CAPS, defect)

Description

[Henrik Gemal]

you have to restart mozilla to get the "cookies" prefs in Edit -> Pref ->
Advanced -> Scripts and Windows working.

try having this local file and turn off "read cookie" without restarting.
<script>
document.writeln("before");
var dc = document.cookie;
document.writeln("after");
</script>

now try to restart and load the file again....

20020302

Comment 1

[Henrik Gemal]

think this is prefs...

Comment 2

[Boris Zbarsky [:bzbarsky]]

No, this is CAPS.

Mitch, remember my question about dynamic changes to security policies?  Was
that ever addressed?  Is there an API that this pref panel should be calling to
resync security policies?

Comment 3

[Mitchell Stoltz (not reading bugmail)]

Hmm, that's odd. There is an API that this pref panel should be calling to
refresh caps settings, and I could have sworn I checked it in, but it's not
showing up in Bonsai so I guess it got left out somehow. I'll check it in.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Critical Moz1.0 fixes

Comment 5

[Mitchell Stoltz (not reading bugmail)]

Attachment: The forgotten part of the patch

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 74011 [details] [diff] [review]
The forgotten part of the patch

r=bzbarsky

Comment 7

[Johnny Stenback (:jst)]

Why can't this be done with pref observers? Seems like this is done the wrong
way around, or am I missing something?

Comment 8

[Mitchell Stoltz (not reading bugmail)]

Hmm, good point. There's a performance issue - the way I've written the new
policy tables, they can't be built up incrementally, they must be initialized
all at once. If we re-initialized after each pref change instead of once after
all pref changes, we'd be doing a lot of unnecessary work by repeatedly building
up and destroying the policy tables. I suppose we could get fancy, like this:

on pref change {
  dirty_bit = true;
}

on security check {
  if (dirty_bit)
    re-initialize tables
}

Do you think it's worth the effort and complexity to do it this way? Or should
we stick with the current patch? I don't anticipate these prefs being changed by
any callers other than this pref panel, although I suppose it's always possible.
  

Comment 9

[Johnny Stenback (:jst)]

We don't control the pref UI in all applications, so I would say that it's worth
the trouble to do what you suggested above.

Comment 10

[Mitchell Stoltz (not reading bugmail)]

Oh, OK. It means adding an additional if() clause to each security check, but I
suppose the performance impact will be minimal. 

Comment 11

[Mitchell Stoltz (not reading bugmail)]

Fixed.

Comment 12

[Henrik Gemal]

v 20020326