Closed
Bug 129642
Opened 22 years ago
Closed 16 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•22 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•22 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•22 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•22 years ago
|
Reporter | ||
Comment 4•22 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•22 years ago
|
||
please attach the contents of the chrome directory in your profile directory when you get into this state. thanks.
Reporter | ||
Comment 6•22 years ago
|
||
This is a zipped copy of my the chrome directory in my profile, while horked.
Comment 7•22 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•22 years ago
|
||
nsbeta1+ per Nav triage team, nav1
Reporter | ||
Comment 9•22 years ago
|
||
After removing xul.mfl, the forms look fine on restart.
Comment 10•22 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•22 years ago
|
||
cc'ing brendan and ben for fastload weirdness. Can you guys offer any insight here?
Comment 12•22 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•22 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•22 years ago
|
||
changing to nsbeta1-, per conversation with bryner
Updated•22 years ago
|
Target Milestone: mozilla1.0 → mozilla1.1alpha
Comment 15•22 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•22 years ago
|
QA Contact: madhur → tpreston
Comment 16•22 years ago
|
||
Reporter: does your horkage look anything like mine?
Comment 17•22 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•22 years ago
|
||
Comment 19•22 years ago
|
||
Um, please tell me that those "capability.principal.codebase..." prefs are not part of this bug.
Comment 20•22 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•22 years ago
|
||
That's the same horkage I saw.
Comment 22•22 years ago
|
||
I see the same horkage, but I do NOT have any capability.principal prefs in my prefs.js.
Comment 23•22 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•22 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•22 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•22 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•22 years ago
|
||
Updated•22 years ago
|
Summary: Forms appear horked after switching to XBL Form Controls → XBL forms horked, related to order of pref loading
Comment 28•22 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•22 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•22 years ago
|
||
Sorry, it did only fix it temporarily after all. My horkage is back now.
Comment 31•22 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•22 years ago
|
||
<sigh> Really cc'ing alecf this time...
Comment 33•22 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•22 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•22 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•22 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•22 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•22 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•22 years ago
|
||
*** Bug 153308 has been marked as a duplicate of this bug. ***
Comment 41•21 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•21 years ago
|
||
This bug needs an owner....
Assignee: bnesse → prefs
Component: Layout: Form Controls → Preferences: Backend
Target Milestone: Future → ---
Comment 43•16 years ago
|
||
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: tpreston → prefs
Comment 44•16 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•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•