[XBLFC] XBL forms horked, related to order of pref loading

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
17 years ago
10 years ago

People

(Reporter: trudelle, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nav1], URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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

17 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

17 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

17 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.
Status: NEW → ASSIGNED
Keywords: nsbeta1
Target Milestone: --- → mozilla1.0
(Reporter)

Comment 4

17 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.  
please attach the contents of the chrome directory in your profile directory
when you get into this state.  thanks.
(Reporter)

Comment 6

17 years ago
Created attachment 74907 [details]
Contents of my chrome dir while horked

This is a zipped copy of my the chrome directory in my profile, while horked.
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

17 years ago
nsbeta1+ per Nav triage team, nav1
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [nav1]
(Reporter)

Comment 9

17 years ago
After removing xul.mfl, the forms look fine on restart.

Comment 10

17 years ago
Removing XUL.mfl ... that's odd. We don't serialize anything related to the 
forms.jar into the fastload file, do we?
cc'ing brendan and ben for fastload weirdness.  Can you guys offer any insight here?
Currently, only individual script files are serialized and deserialized. I don't
personally know how that could cause a problem. Brendan? 

Comment 13

17 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

17 years ago
changing to nsbeta1-, per conversation with bryner
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.1alpha

Comment 15

17 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

17 years ago
QA Contact: madhur → tpreston

Comment 16

17 years ago
Created attachment 82940 [details]
Aaronl's XBL horkage (could be different from reporter's)

Reporter: does your horkage look anything like mine?

Comment 17

17 years ago
Created attachment 82947 [details]
Aaronl's XBL horkage (could be different from reporter's)
Attachment #82940 - Attachment is obsolete: true

Updated

17 years ago
Attachment #82940 - Attachment is patch: false
Attachment #82940 - Attachment mime type: text/plain → image/gif

Comment 18

17 years ago
Created attachment 82985 [details]
Five line prefs file that recreates the bug on my machine. Will create output as in attachment 82947 [details]

Comment 19

17 years ago
Um, please tell me that those "capability.principal.codebase..." prefs are not
part of this bug.

Comment 20

17 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

17 years ago
That's the same horkage I saw.

Comment 22

17 years ago
I see the same horkage, but I do NOT have any capability.principal prefs in my
prefs.js.

Comment 23

17 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

17 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

17 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

17 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

17 years ago
Created attachment 83148 [details]
This stack shows how xbl-forms.css is prevented from loading, even with the XBL forms pref turned on

Updated

17 years ago
Summary: Forms appear horked after switching to XBL Form Controls → XBL forms horked, related to order of pref loading

Comment 28

17 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

17 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

17 years ago
Sorry, it did only fix it temporarily after all. My horkage is back now.

Comment 31

17 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

17 years ago
<sigh> Really cc'ing alecf this time...

Comment 33

17 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

17 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
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

17 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

17 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

17 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".
Blocks: 133791
No longer blocks: 133791

Comment 39

16 years ago
*** Bug 153308 has been marked as a duplicate of this bug. ***

Comment 40

15 years ago
retargeting
Target Milestone: mozilla1.1alpha → Future

Comment 41

15 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
This bug needs an owner....
Assignee: bnesse → prefs
Component: Layout: Form Controls → Preferences: Backend
Target Milestone: Future → ---
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: tpreston → prefs

Comment 44

10 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

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.