Closed
Bug 331225
Opened 19 years ago
Closed 19 years ago
prefwindow/prefpane does not work in xulrunner.
Categories
(Toolkit Graveyard :: XULRunner, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: lekkizogloy03, Assigned: bent.mozilla)
Details
(Keywords: fixed1.8.1)
Attachments
(2 files, 1 obsolete file)
971 bytes,
patch
|
benjamin
:
first-review+
benjamin
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
14.52 KB,
patch
|
mconnor
:
first-review+
|
Details | Diff | Splinter Review |
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•19 years ago
|
||
Does anything interesting show up in the JS console?
http://developer.mozilla.org/en/docs/Debugging_a_XULRunner_Application
Reporter | ||
Comment 2•19 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
![]() |
||
Comment 3•19 years ago
|
||
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•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 4•19 years ago
|
||
(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.
Assignee | ||
Comment 5•19 years ago
|
||
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•19 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-
Assignee | ||
Comment 7•19 years ago
|
||
Doh. Try 2.
Attachment #218437 -
Attachment is obsolete: true
Attachment #218440 -
Flags: first-review?(benjamin)
Assignee | ||
Comment 8•19 years ago
|
||
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 | ||
Updated•19 years ago
|
Attachment #218447 -
Flags: first-review? → first-review?(mconnor)
Updated•19 years ago
|
Attachment #218440 -
Flags: first-review?(benjamin) → first-review+
Comment 9•19 years ago
|
||
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+
Comment 10•19 years ago
|
||
Won't renaming the prefs break people who currently have them set to non-default values? Do we not care about that?
Assignee | ||
Comment 11•19 years ago
|
||
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]
Assignee | ||
Comment 12•19 years ago
|
||
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•19 years ago
|
Attachment #218440 -
Flags: approval-branch-1.8.1?(benjamin) → approval-branch-1.8.1+
Assignee | ||
Comment 13•19 years ago
|
||
Fixed 1.8.1
Filed bug 335931 about moving/renaming prefs.
Updated•9 years ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•