Closed Bug 331225 Opened 19 years ago Closed 18 years ago

prefwindow/prefpane does not work in xulrunner.


(Toolkit Graveyard :: XULRunner, defect)

Windows XP
Not set


(Not tracked)



(Reporter: lekkizogloy03, Assigned: bent.mozilla)


(Keywords: fixed1.8.1)


(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060111 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060111 Firefox/

When using xulrunner, I cannot get the prefwindow/prefpane objects to work properly. I attempt to create a small preference window with textboxes, and I find that the GUI window is drawn and there is a cursor where a textbox should be, but nothing appears when I type even though the cursor moves as expected. I can tab to the next textbox (that is invisible). 

## Begin Code ##
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<?xml-stylesheet href="chrome://mozapps/content/preferences/preferences.css"?>

<!DOCTYPE prefwindow [
<!ENTITY % modzillaDTD SYSTEM "chrome://modzilla/locale/main.dtd">
<!ENTITY % brandDTD SYSTEM "chrome://global/locale/main.dtd">

<prefwindow id="prefs"
                                title="Preferences" type="prefwindow">
<prefpane id="user-pref" label="User information" >
    <preference id="user.firstname" name="user.firstname" type="string"/>
        <preference id="user.lastname" name="user.lastname" type="string"/>
            <label value="Firstname"/>
            <textbox preference="user.firstname"/>
            <label value="Lastname"/>
            <textbox preference="user.lastname"/>
<prefpane id="ser-pref" label="Serial line configuration">
    <preference id="ser.port" name="ser.port" type="string"/>
            <label value="Serial line port"/>
            <textbox preference="ser.port"/>

Reproducible: Always

Steps to Reproduce:
1. Run the specified code using xulrunner.

Actual Results:  
A window will appear with no textboxes, typing moves the cursor but no text appears.

Expected Results:  
Expect to have a nice preference window with two panes and a few text boxes.

I'm using xulrunner
Does anything interesting show up in the JS console?
Yea actually:

Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://global/content/bindings/preferences.xml :: get__shouldAnimate :: line 689"  data: no]

The pref check for browser.preferences.animateFadeIn should probably fail gracefully and fallback to a reasonable default value... doesn't seem like a good name for a toolkit pref either - Thunderbird uses it, etc.
Ever confirmed: true
(In reply to comment #3)
> doesn't seem like a good name for a toolkit pref either

We don't really have a toolkit pref branch but it would make sense here.

browser.preferences.instantApply should also change if we're going to change this one.

animateFadeIn is only used in preferences.xml, but instantApply is used in many places. I'd be up for changing these to toolkit.preferences or whatever if you guys agree.
Fixes this bug.

I'll attach a patch to rename the prefs to toolkit.preferences.* in a sec, but that will have to have additional review.
Attachment #218437 - Flags: first-review?(benjamin)
Comment on attachment 218437 [details] [diff] [review]
Return a suitable default value if browser.preferences.animateFadeIn doesn't exist

Set the default first (in the var decl or right after), then try getting the pref with an empty catch block.
Attachment #218437 - Flags: first-review?(benjamin) → first-review-
Doh. Try 2.
Attachment #218437 - Attachment is obsolete: true
Attachment #218440 - Flags: first-review?(benjamin)
This patch will rename the browser.preferences.* prefs to toolkit.preferences.*

Given that these prefs are used outside of browser I think this is a great idea.

mconnor, what do you think?
Assignee: nobody → bent.mozilla
Attachment #218447 - Flags: first-review?
Attachment #218447 - Flags: first-review? → first-review?(mconnor)
Attachment #218440 - Flags: first-review?(benjamin) → first-review+
Comment on attachment 218447 [details] [diff] [review]
Rename preferences

Yeah, I'll go for that.  Now, that said, we still need a location for default prefs for toolkit stuff like this and the EM prefs, and only define them in app defaults if we're changing that
Attachment #218447 - Flags: first-review?(mconnor) → first-review+
Won't renaming the prefs break people who currently have them set to non-default values? Do we not care about that?
Comment on attachment 218440 [details] [diff] [review]
With review comments [checked in]

Fixed on trunk.
Attachment #218440 - Attachment description: With review comments → With review comments [checked in]
Comment on attachment 218440 [details] [diff] [review]
With review comments [checked in]

oops, for the branch too?
Attachment #218440 - Flags: approval-branch-1.8.1?(benjamin)
Attachment #218440 - Flags: approval-branch-1.8.1?(benjamin) → approval-branch-1.8.1+
Fixed 1.8.1

Filed bug 335931 about moving/renaming prefs.
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.