prefwindow/prefpane does not work in xulrunner.

RESOLVED FIXED

Status

Toolkit Graveyard
XULRunner
RESOLVED FIXED
12 years ago
2 years ago

People

(Reporter: Luke Ekkizogloy, Assigned: Ben Turner (not reading bugmail, use the needinfo flag!))

Tracking

({fixed1.8.1})

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

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">
%modzillaDTD;
<!ENTITY % brandDTD SYSTEM "chrome://global/locale/main.dtd">
%brandDTD;
]>

<prefwindow id="prefs"
                                xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
                                title="Preferences" type="prefwindow">
<prefpane id="user-pref" label="User information" >
  <preferences>
    <preference id="user.firstname" name="user.firstname" type="string"/>
        <preference id="user.lastname" name="user.lastname" type="string"/>
  </preferences>
            <label value="Firstname"/>
            <textbox preference="user.firstname"/>
            <label value="Lastname"/>
            <textbox preference="user.lastname"/>
</prefpane>
<prefpane id="ser-pref" label="Serial line configuration">
  <preferences>
    <preference id="ser.port" name="ser.port" type="string"/>
  </preferences>
            <label value="Serial line port"/>
            <textbox preference="ser.port"/>
</prefpane>
</prefwindow>  




Reproducible: Always

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

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 1.8.0.1.

Comment 1

12 years ago
Does anything interesting show up in the JS console?

http://developer.mozilla.org/en/docs/Debugging_a_XULRunner_Application
(Reporter)

Comment 2

12 years ago
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]

-Thanks
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.

Updated

12 years ago
Status: UNCONFIRMED → NEW
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.
Created attachment 218437 [details] [diff] [review]
Return a suitable default value if browser.preferences.animateFadeIn doesn't exist

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 6

12 years ago
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-
Created attachment 218440 [details] [diff] [review]
With review comments [checked in]

Doh. Try 2.
Attachment #218437 - Attachment is obsolete: true
Attachment #218440 - Flags: first-review?(benjamin)
Created attachment 218447 [details] [diff] [review]
Rename preferences

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
Status: NEW → ASSIGNED
Attachment #218447 - Flags: first-review?
Attachment #218447 - Flags: first-review? → first-review?(mconnor)

Updated

12 years ago
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)

Updated

12 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 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.