Closed Bug 52366 Opened 24 years ago Closed 22 years ago

radio buttons not bound with XUL cache disabled

Categories

(Core :: XBL, defect, P2)

Product:
Core
Component:
XBL
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: alecf, Assigned: hyatt)

References

Details

(Whiteboard: [dogfood-][nsbeta3-]) 

In the mail account wizard, the radio buttons do not appear if the XUL cache is
disabled. This makes it INCREDIBLY hard to do any kind of development on this
dialog. Ben says this is a known bug, but I can't find it...

I would imagine this has got to appear elsewhere in the UI as well. This is
really killing me. I figure it has to do with asynch reflow and late XBL
binding...
nominating for dogfood because this is seriously impacting my work - it's taking
probably 5 times longer to work on this dialog than it would if the radio
buttons were working.
Keywords: dogfood
Marking dogfood-plus.
Infrastructure has got to continue to work if the consumers of this 
functionality are to make progress.
Whiteboard: [dogfood+]
This is hardly a dogfood bug.  A clear workaround exists: turn on your XUL 
cache.  Dogfood bugs should be reserved for problems that have no workaround.  
This has a workaround.

Nominate this for nsbeta3+ if you want, but calling it dogfood is complete 
overkill.
Status: NEW → ASSIGNED
Keywords: dogfood
Whiteboard: [dogfood+]
I voted for dogfood because this is seriously impacting my productivity if I 
cannot use the XUL cache.

My dialog is brought up from the mail 3-pane, which means every time I want to 
reload the XUL for the dialog, I have to quit messenger, start mail again (which 
of course takes forever) then load up my dialog again. It used to be that I 
could just close and reopen the dialog.

I'm sorry to be so stubborn about this, but the workaround sucks! the workaround 
to something broken is to do something that takes 5 times longer...
Keywords: nsbeta3
Blocks: 45512
I'm happy to fix it, and if it's marked nsbeta3+, I will fix it... I'm just 
trying to ensure we label it correctly. 
adding back the dogfood keyword and plus that Hyatt removed.
Keywords: nsbeta3 → dogfood
Priority: P3 → P2
Whiteboard: [dogfood+]
Target Milestone: --- → M18
On a completely fresh build on Win32 with the XUL cache off, your buttons show 
up fine.  NOTE HOWEVER that with JAR packaging on, stylesheets are frequently 
failing to load.  I suspect that this might be the true cause of your bug.  If 
the stylesheet failed to load, the binding would not get applied.

Anyway, when the stylesheet loads, I see the radio buttons every time, even with 
the XUL cache off.

I haven't been using JAR packaging in my builds... dunno what exactly that 
means. I'll try tomorrow's builds and see what I run into
Any update?  I am unable to reproduce this bug.

I'm still seeing it.. you know, I'm using modern, maybe that's part of it?
trying classic now. this is on linux.. I originally reported this on windows but 
I don't have a current windows build handy.
(I assume alecf has already sorted out that JAR packaging is not enabled on 
Linux). 

In today's Linux verif. builds, in the modern skin, with the XUL cache 
disabled. I can reproduce this everytime (none of the radio elements appear 
in the dialog window). But with the classic skin, this works correctly 
everytime (all of the radio elements show up in the dialog window). 

(Interestingly, I get one minor bit of failure for this dialog under the modern 
skin on win2k --- the "unselected state" image for the radio is not loaded, but
in the classic skin, there are zero defects.)
sure enough, the classic skin will work.. it didn't used to, but maybe ben's 
wizard changes fixed it up in the classic skin (though not for modern, I don't 
know why)
I'm beginning to think this is a linux-only bug.  If so, I think the dogfood+ 
should be retracted.


we obviously have enough workarounds here to ease development pain.  removing 
the + and futuring.
Whiteboard: [dogfood+]
Target Milestone: M18 → Future
thanks for the effort though - working on the classic skin is fine for me
Sounds like this is no longer blocking folks... marking dogfood-minus
Whiteboard: [dogfood-]
*** Bug 53031 has been marked as a duplicate of this bug. ***
nomination nsbeta3
Keywords: mailtrack, nsbeta3
People get hit a lot recently by this bug!
I don't see why this would be plussed for beta3 if you have to manually edit
your prefs file to turn off the XUL cache.

nsbeta3-, doesn't affect any end-users, can't hold N6 for it.
Whiteboard: [dogfood-] → [dogfood-][nsbeta3-]
Keywords: mailtrack
Keywords: nsdogfood-
Keywords: nsdogfood
hmm, after 2 years and 3 months... not gonna fix this.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
so was the problem definitely related to jars failing?

alecf: i'm running w/ a semi hacked jar cache (basically don't hold onto jars),
live skin switching, and none of darin's necko rewrites (build from perhaps the
week before that landed).
I did the following:
* live skin switch from classic to modern ([navigator]view>apply theme>modern)
* run messenger ([navigator]window>mail & news groups)
* stretched the mail window (no gecko running in the terminal session where
mozilla is running will paint as often as it should, this happens w/ talkback
nightlies and even netscape releases in addition to my debug builds)
* file>new>account...
* next (I couldn't read the dialog but was fairly certain the only content was
'next' and 'cancel' which i could see when i tabbed -- again, this isn't a fault
of my build or skin switching or anything, it's some generic painting issue of
mozilla's)
* shrunk the dialog (it turns out it's the identity pane) until the internal
content needed a scrollbar (at which point it painted)
* filled in test/test@example.net
* clicked next
* saw imap and pop radio buttons (we're still in modern theme)
* they appear to work (it's a bit hard to tell, my terminal service uses 256
colors, and we all know how well modern works there).

mozilla console output includes various things, related to the account wizard

Reference to undefined property window.arguments - 2 times
initializing ISP data for mailaccount
Reference to undefined property pageData[tag] - 2 times
Reference to undefined property pageData[tag][slot] - 4 times
Reference to undefined property pageData[tag] - 2 times
Reference to undefined property pageData[tag][slot] - 2 times

I'm willing to research this problem if someone can tell me how to reproduce it.
Severity: normal → minor
no, this has nothing to do with jars, and has long gone away since we switched
to XBL XUl controls.
You need to log in before you can comment on or make changes to this bug.