Closed
Bug 129642
Opened 23 years ago
Closed 17 years ago
[XBLFC] XBL forms horked, related to order of pref loading
Categories
(Core :: Preferences: Backend, defect)
Core
Preferences: Backend
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: trudelle, Unassigned)
References
()
Details
(Whiteboard: [nav1])
Attachments
(4 files, 1 obsolete file)
3.03 KB,
application/octet-stream
|
Details | |
29.19 KB,
image/gif
|
Details | |
Five line prefs file that recreates the bug on my machine. Will create output as in attachment 82947
397 bytes,
text/plain
|
Details | |
This stack shows how xbl-forms.css is prevented from loading, even with the XBL forms pref turned on
6.63 KB,
text/plain
|
Details |
Using NS Build 2002030703 on Win2K:
Enable XBL form controls in Debug prefs.
Exit App.
Exit QuickLaunch (if active).
Relaunch.
go to a page with forms, such as http://bugzilla.mozilla.org/query.cgi
Expected results: See the all-too-familiar form.
Actual results: the form is unrecognizable and unusable, for instance the text
of all items in input controls is listed where the button to pop the list up
should be.
Workaround:
Switch to a new theme.
Switch theme back
Exit & relaunch again.
Comment 1•23 years ago
|
||
I can do this if I enable XBL form controls, and then visiting b.m.o/query.cgi
if I have _not_ exited the application. Otherwise, if I do exit (and the exe has
fully quit) then XBL form controls are fine when I go to that form page.
Is there any chance that your (trudelle's) application did not fully exit (i.e.,
left a partially hung app in the background instead of fully quitting).
Reporter | ||
Comment 2•23 years ago
|
||
I don't think so. I didn't check, but there was nothing unusual on shutting down
or starting up. Bryner says other people have seen this on *the first* restart
after switching to XBL Form Controls. After going through the workaround, they
look great. I'll certainly add comments if I see it on subsequent sessions.
Reporter | ||
Comment 3•23 years ago
|
||
It's baaack! My machine hung in standby, so I had to force a restart, and when
I did the XBL controls exploded again. Workaround still effective, though it
ends in a crash, and will be much more of a pain when we delay theme switching
until restart.
Updated•23 years ago
|
Reporter | ||
Comment 4•23 years ago
|
||
This is happening every time my OS crashes, which considering I'm running
Windows, will probably be at least 3 times a week.
Comment 5•23 years ago
|
||
please attach the contents of the chrome directory in your profile directory
when you get into this state. thanks.
Reporter | ||
Comment 6•23 years ago
|
||
This is a zipped copy of my the chrome directory in my profile, while horked.
Comment 7•23 years ago
|
||
Hm, this all looks fine, actually (skin and locale are both selected). Do
either of the following steps fix the problem?
- Remove XUL.mfl in your profile directory
- Rename localstore.rdf in your profile directory (this contains a lot of
persisted state, so you'll want to put it back once you've established whether
this fixes it)
Also, if you create a new profile, are the form controls ok for that profile?
Thanks.
Reporter | ||
Comment 8•23 years ago
|
||
nsbeta1+ per Nav triage team, nav1
Reporter | ||
Comment 9•23 years ago
|
||
After removing xul.mfl, the forms look fine on restart.
Comment 10•23 years ago
|
||
Removing XUL.mfl ... that's odd. We don't serialize anything related to the
forms.jar into the fastload file, do we?
Comment 11•23 years ago
|
||
cc'ing brendan and ben for fastload weirdness. Can you guys offer any insight here?
Comment 12•23 years ago
|
||
Currently, only individual script files are serialized and deserialized. I don't
personally know how that could cause a problem. Brendan?
Comment 13•23 years ago
|
||
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.) Thanks!
Comment 14•23 years ago
|
||
changing to nsbeta1-, per conversation with bryner
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla1.1alpha
Comment 15•23 years ago
|
||
still seeing this, however I don't seem to be able to switch themes. I recently
upgraded my profile (was still on a users50/ style profile). maybe there is
something there causing problems?
Updated•23 years ago
|
QA Contact: madhur → tpreston
Comment 16•23 years ago
|
||
Reporter: does your horkage look anything like mine?
Comment 17•23 years ago
|
||
Attachment #82940 -
Attachment is obsolete: true
Attachment #82940 -
Attachment is patch: false
Attachment #82940 -
Attachment mime type: text/plain → image/gif
Comment 18•23 years ago
|
||
Comment 19•23 years ago
|
||
Um, please tell me that those "capability.principal.codebase..." prefs are not
part of this bug.
Comment 20•23 years ago
|
||
My horkage doesn't occur without the capability.principal prefs in the prefs.js.
I don't know about anyone else's
Reporter | ||
Comment 21•23 years ago
|
||
That's the same horkage I saw.
Comment 22•23 years ago
|
||
I see the same horkage, but I do NOT have any capability.principal prefs in my
prefs.js.
Comment 23•23 years ago
|
||
Jonas, if you move your |user_pref("nglayout.debug.enable_xbl_forms", true);|
line to the top of prefs.js and then run does fix the problem temporarily?
It does on mine. The actual position of the XBL pref affects this. Once you exit
and relaunch, it's horked again though, since the prefs.js is alphabetized as
you exit.
Comment 24•23 years ago
|
||
For some reason it's not using the anonymous content. So, for example, <input
type="checkbox" /> still looks like an <input> instead of <xul:image>.
However, CSSFrameConstructor knows that it *should* be parsing an HTML checkbox
as XUL in ConstructXULFrame(), so it goes there and doesn't know what to do with
the HTML tag. Kind of caught in a no man's land where neither XBL or old form
controls are being used.
Comment 25•23 years ago
|
||
So far, I've narrowed this down to nsCSSFrameConstuctor::ConstructFrameInternal()
When things are working, display->mBinding =
"chrome://.../checkbox.xml#checkbox" so that it can load the bindings for checkbox.
When things aren't working, display->mBinding = ""
I'm trying to find where this URL gets resolved and stored, so I can see what's
going wrong.
Comment 26•23 years ago
|
||
I'm working on a bug where XBL form controls are horked because of the order of
prefs in prefs.js. I have a .gif of the horked controls and the prefs.js which
causes the bug on my system.
http://bugzilla.mozilla.org/show_bug.cgi?id=129642
The specific case I'm working on invovles capability.principal prefs, but some
users experiencing the bug don't have that pref set. In my test case, the
capability.principal prefs are set in my prefs.js file. This is important
because the pref is still supported. nsScriptSecurityManager::InitPrincipals
gets called from the pref callback as prefs.js loads.
The reason for the bug is the the the chrome registry is initialized as soon as
a string bundle is required. This can happen before the entire prefs has
finished loading, because of pref callbacks. I think there must be a number of
pref call backs that use string bundles.
The string bundle initialization initializes "chrome://" URL handling, which
ends up calling the nsChromeRegistry::nsChromeRegistry() constructor. This
constructor uses the "nglayout.debug.enable_xbl_forms" pref, which hasn't been
initialized yet. Therefor and xbl-forms.css is not loaded, so there is no
anonymous content for the XBL controls.
Later, as the HTML statup page loads, nsCSSFrameConstructor checks the same XBL
form control pref, which is now initialized. It skips past the normal frame
construction in favor of using the anonymous content, of which there is
currently none.
This problem seems deeper to me than a simple fix. We could fix it in many
different places, but aren't there a lot of potenital problems of the same
variety? If pref listeners are used for statup initialization they shouldn't
need any other prefs in their calling chain, because those prefs may not be set yet.
Comment 27•23 years ago
|
||
Updated•23 years ago
|
Summary: Forms appear horked after switching to XBL Form Controls → XBL forms horked, related to order of pref loading
Comment 28•23 years ago
|
||
Aything that listens to a pref to initialize itself, can cause a cascade of
other things to initialize, each of which may require another pref for proper
operation. Unless all of the prefs are loaded, the initialization of these
services will often see the incorrect setting for the pref. In our case, the
horkage is caused because one part of the code sees one setting, and another
part of the code sees a different setting.
This is precarious. If we fix this specific incident, I'm not convinced that
similar things won't happen in other places. Perhaps we should delay pref
callbacks until all of the prefs are loaded?
Comment 29•23 years ago
|
||
Re: Comment 23 --
> Jonas, if you move your |user_pref("nglayout.debug.enable_xbl_forms", true);|
> line to the top of prefs.js and then run does fix the problem temporarily?
It fixed it permanently. I am now unable to reproduce the horkage no matter
where the line is in my pref files.
Comment 30•23 years ago
|
||
Sorry, it did only fix it temporarily after all. My horkage is back now.
Comment 31•23 years ago
|
||
>Perhaps we should delay pref callbacks until all of the prefs are loaded?
At one time prefs used to work this way. No callbacks were fired during loading.
This was changed at some point, I'm not sure why... maybe alecf remembers why...
cc'ing him to see.
Comment 32•23 years ago
|
||
<sigh> Really cc'ing alecf this time...
Comment 33•23 years ago
|
||
Here was the problem that resulted in that decision: in some situations, the
layout engine was accessing prefs before a profile was selected - for instance,
when the profile window comes up - you need to display UI, but no per-profile
prefs can be loaded yet.
What was happening was Gecko was caching the pref (for performance reasons) but
if the pref value was different once the prefs were started, there was no way
for Gecko to know that it should start caching a new value. we decided that
given the few pref callbacks that are registered before a profile was selected,
it made sense to just tell then when the pref changes.
that said, I think it is still the right thing to do. I think if code is somehow
designed in a way where one pref value depends on another pref value, then that
whole system is screwed, and needs to be repaired.
I don't find this precarious - someone could say refcounting is precarious
because "what if someone forgets to Release()?!" - but we use it every day...
Comment 34•23 years ago
|
||
After talking with Aaron and Conrad about this I finally have a more clear
understanding of the underlying issue. Attempting to summarize...
When the Pref Service starts up, it reads in the default values. Once the
profile is selected, these values may change. Objects which were caching values
before the profile was loaded were not informed of the change because it was a
"load time" change rather than a "run time" change. So the Pref Service was
changed to send change notifications at "load time".
The problem here is that we are aggressively performing notifications while
reading the file, rather than caching the notifications until the file read
completes. This is opening us to a state where preferences not yet read from a
file can be accessed by those that have been read. To take this a step
farther... we could potentially have a cross file dependency as well, say
between all.js and mailnews.js (default loading) or prefs.js and user.js
(profile loading).
Alec and I have talked about this and it would seem that the most thorough fix
would be to attempt to cache callbacks across entire load groups (default and
user/profile)... I expect this just became my problem :(
Assignee: bryner → bnesse
Status: ASSIGNED → NEW
OS: Windows 2000 → All
Hardware: PC → All
Comment 35•23 years ago
|
||
I agree with what Brian says. Though, isn't the problem only with prefs.js whose
contents are alphabetized and rewritten dynamically? In terms of cross-file
dependencies (between all.js and mailnews.js) the contents of those are ordered
up front and this can be avoided by that ordering. So, I think eliminating
per-file ordering problems by caching the callbacks generated by that single
file load would be sufficient.
Comment 36•23 years ago
|
||
While it is true that an order can be imposed on the loading of default
preferences I believe that depending on this fact to insure that all necessary
preferences are in memory when needed is a bad idea.
I can easily imagine a case where, say, a preference in all.js triggers a
callback that is dependent on a preference defined in mailnews.js... which will
be processed later. I can envision similar scenarios where a preference in
prefs.js is dependent on a value declared in user.js.
Comment 37•23 years ago
|
||
yeah, to second what brian is saying - its quite possible that components that
have their own sets of prefs (i.e. mailnews.js) have callbacks to global prefs
stored in all.js
and as it turns out, at least from what brian described, it isn't really all
that much more work (or any more work?) to hold all the callbacks for the
reading of ALL the files than to do them one-by-one...so we might as well do
them for all the files at once.
Comment 38•23 years ago
|
||
Correct. Once you've gotten to the point of caching the callbacks, the
distinction between caching for a single file vs. caching for a collection of
files is only a matter of where you "throw the switch".
Comment 39•23 years ago
|
||
*** Bug 153308 has been marked as a duplicate of this bug. ***
Comment 41•22 years ago
|
||
Shouldn't chromeservice register a prefs callback for
"nglayout.debug.enable_xbl_forms" anyway, when it gets initialized? Shouldn't
anyone who's caching a pref register a callback? I don't understand why we're
fixing this at the prefs level instead of the "client" code.
Wouldn't this same issue affect profile-switching anyway, in a manner that can
only be solved by the client code?
--BDS
![]() |
||
Comment 42•22 years ago
|
||
This bug needs an owner....
Assignee: bnesse → prefs
Component: Layout: Form Controls → Preferences: Backend
Target Milestone: Future → ---
Comment 43•17 years ago
|
||
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: tpreston → prefs
Comment 44•17 years ago
|
||
Since bug 57209 is wontfix and this is a bug in that code per bsmedberg, marking wontfix.
Summary: XBL forms horked, related to order of pref loading → [XBLFC] XBL forms horked, related to order of pref loading
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•