227612 - [FIX]Cookie settings not shown in preferences

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Hermann Schwab]

regressed between working nightly BuildID 2003120208 ( directory 2003-12-02-09)
and failing tinderbox BuildID 2003120307 ( file time 11h24 )

with current nightly 03120508 I noticed my cookie settings were not shown.
I´ve seen only cookies enabled: ALL, could change it, but on reopening pref the
change wasn´t shown.
The lifetime settings weren´t shown at all, normally I´ve got cookies enabled
for session only, and so the box for lifetime in days is gray, but shows a number.
Using buggy builds, that box is plain white, no number seen.
I created a fresh profile, noc change, but crashed after some
opening/changing/reopening the prefs.
Going back to BuildID 2003120208 my own default settings were shown.
I checked some Builds inbetween BuildID 2003120208 and current nightly
2003120508 using the same profile, always installed ontop, reinstalling 03120208
went back to normal behaviour.

Some other checks in the profile:
Adding a language worked, removing also.
Disabling JS for Navigator didn´t gray out the JS-settings, this is still the
case in BuildID 2003120208.
Should I file another bug for this?

Setting priority blocker to get attention for 1.6b

Comment 1

[Boris Zbarsky [:bzbarsky]]

> Disabling JS for Navigator didn´t gray out the JS-settings

Please file a separate bug for that, cc me and
[e-mail].  That got broken by his patch to bug 181973
-- the Startup() function for that pref panel has a JS error.

Investigating the main issue reported here...

Comment 2

[Boris Zbarsky [:bzbarsky]]

OK, opening that prefs panel gives me:

Error: this.mRadioChildren has no properties
Source File: chrome://global/content/bindings/radio.xml
Line: 202

This is fallout from bug 226549 somehow...  Taking.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Actually, I filed bug 227623 on the issue in comment 1 

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Maybe something like this?

I don't like this much, but...

The problem here is some script calls _getRadioChildren before their frames
have been constructed, hence before bindings have been attached to them.  So
the bindings get attached in the middle of the _getRadioChildren() call.  But
their constructors blow away the mRadioChildren array.... This patch makes us
detect that condition, finish iterating over the <radio>s to make sure all
their bindings get created, then just call _getRadioChildren() again to get the
data it needs.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 136920 [details] [diff] [review]
Maybe something like this?

Neil?  Alec?  Could you review, please?

Comment 6

[[e-mail]]

OK, so what's happening here is that the cookies panel is trying to use xbl on a
hidden radio button, which I think is failing for the same reason as bug 90337
i.e. the hidden radio isn't constructed until JS references it. (Normally all
xbl is constructed before the load event.) Interestingly having the p3p choice
as the selected item masks this bug, I don't understand that bit yet.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Neil, that's exactly right (the bit about using XBL on display:none things). 
That's what blows away the array during the treewalk in this case, since that's
when the binding is instantiated...

Comment 8

[[e-mail]]

Attachment: I still prefer the "flatter" approach

This is based on my patch in bug 223897, but with less of the clean up, and
further simplified, and rearranged to resolve this bug.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 136953 [details] [diff] [review]
I still prefer the "flatter" approach

OK, agreed.  This is better.  r=bzbarsky

Comment 10

[Boris Zbarsky [:bzbarsky]]

To neil, since it's his patch.

Comment 11

[Alec Flett]

Comment on attachment 136953 [details] [diff] [review]
I still prefer the "flatter" approach

sr=alecf

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 136953 [details] [diff] [review]
I still prefer the "flatter" approach

This is a followup to bug 226549 that fixes more cases where the radiochildren
array could go awry...	This _should_ be pretty safe.

Comment 13

[Hermann Schwab]

*** Bug 227999 has been marked as a duplicate of this bug. ***

Comment 14

[Asa Dotzler [:asa]]

Comment on attachment 136953 [details] [diff] [review]
I still prefer the "flatter" approach

a=asa (on beahalf of drivers) for checkin to Mozilla 1.6.

Comment 15

[[e-mail]]

Fix checked in.

Comment 16

[Michiel van Leeuwen (email: mvl+moz@)]

*** Bug 228381 has been marked as a duplicate of this bug. ***

Comment 17

[Michiel van Leeuwen (email: mvl+moz@)]

*** Bug 228554 has been marked as a duplicate of this bug. ***

Comment 18

[benc]

(I'll verify this if nobody else does)

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 229406 has been marked as a duplicate of this bug. ***

Comment 20

[Jo Hermans]

*** Bug 229542 has been marked as a duplicate of this bug. ***

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 229570 has been marked as a duplicate of this bug. ***

Comment 22

[Jo Hermans]

*** Bug 229638 has been marked as a duplicate of this bug. ***

Comment 23

[Michiel van Leeuwen (email: mvl+moz@)]

*** Bug 229884 has been marked as a duplicate of this bug. ***

Comment 24

[Boris Zbarsky [:bzbarsky]]

*** Bug 231500 has been marked as a duplicate of this bug. ***

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This caused bug 285065.