910 bytes, text/xul
1.23 KB, text/xul
1.23 KB, application/vnd.mozilla.xul+xml
1.97 KB, patch
|Details | Diff | Splinter Review|
Input for <textfield> no longer works after dynamically setting/changing attributes. This 'feature' is 100% reproducable with build 2001030920 on NT. Steps to reproduce: ------------------- 1 - start attachment 2 [review] - use radiobuttons 3 - try to fill/change the <textfield> There's no text after using this: document.getElementById("OverrideUAgentSetting").setAttribute("value",userAgent); But this works: (used as work around) var myElement = document.getElementById("OverrideUAgentSetting"); myElement.value = userAgent; I will attach a testcase to display the problem.
What the heck is that? Please don't use the '2' or 'attachment' links they where inserted by Bugzilla.
HJ, did you forget the attachment?
Yes, thanks Boris, had to make one first and then forgot to attach it. It's 100% reproducable on NT, steps to reproduce: ------------------------------------------------- 1 - load attachment 2 [details] [diff] [review] - click on button 2 (sets readonly="true/false")) 3 - now try to enter text in the textfield (locked) 4 - reload attachment 5 [details] - click on button 3 (sets disabled="true/false") 6 - now try to enter text in the textfield (locked) If you hover your mouse over the textfield, after you used button 2/3, then you will notice that the mouse pointer quickly changes for a very short while, but input is out of the question.
Summary: XUL setAttribute on textfields disables input → XUL setting readonly/disabled on textfield disables input
I see this on Linux as well... over to XP Toolkit/Widgets:XUL
Assignee: beppe → trudelle
Status: UNCONFIRMED → NEW
Component: Editor → XP Toolkit/Widgets: XUL
Ever confirmed: true
OS: other → All
QA Contact: sujay → jrgm
Summary: XUL setting readonly/disabled on textfield disables input → setting then unsetting readonly/disabled on textfield disables input
Hmm. Nope, this is Editor (text editing and entry).
Assignee: trudelle → beppe
Component: XP Toolkit/Widgets: XUL → Editor
QA Contact: jrgm → sujay
off to kin
Assignee: beppe → kin
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1
XUL textfields wrap the gfx implementation of html textfields (layout/html/forms/src/nsGfxTextControlFrame2.cpp), which are used in html forms. In the html world, presence of the readonly and disabled attributes in the textfield's attribute list implies that those attributes are enabled, that is that the textfield will be readonly or disabled. The value of the readonly and disabled attributes are totally ignored since they are not defined by the HTML 4 spec. Note, that the 03/16/01 03:39 testcase will work if you do a removeAttribute("readonly") or removeAttribute("disabled") when the checked value is false. Cc'ing email@example.com to find out if XUL textfields are supposed to mimic the html widgets in this particular case. The textfield section of the XUL developer docs http://www.mozilla.org/xpfe/xulref/textfield.html#readonly seems a bit out of sync with the current implementation since it says to use "read-only" instead of "readonly".
It seems that you better use: http://www.xulplanet.com/tutorials/xultu/elemref/ref_textfield.html to see valid XUL attributes. This site is more up to date.
The recent XUL 1.0 syntax change forced me to change the tag <textfield> into <textbox> but the final result is still the same because that's only a name change i guess. > Note, that the 03/16/01 03:39 testcase will work if you do a > removeAttribute("readonly") or removeAttribute("disabled") when the checked > value is false. Thanks for the work around kin (sorry, don't know your name).
Summary: setting then unsetting readonly/disabled on textfield disables input → setting then unsetting readonly/disabled on textbox disables input
Hey, i can't use that testcase anymore in build 2001041020. Mozilla endlessly opens new windows. I guess this has to do with those recent syntax changes too!? I will make a new testcase to try to solve this problem.
Reassigning to firstname.lastname@example.org, and marking FUTURE (per hyatt). hyatt says this would be easy to fix by providing some XBL that did an unset, behind the scenes, when using false values.
Assignee: kin → hyatt
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla1.0.1
Hyatt, i really like to know how this can be done with a XBL binding because on IRC both Blake and DR told me that it can't be done in XBL. So what's the story here? It seems that the onset and onget for these properties are not 'used' if you use element.setAttribute or element.getAttribute. I'm more then willing to help if i can, but for now, out of options. Give me a hint ok.
Ok i'm using this patch some weeks without problems.
Keywords: patch, review
Is there something wrong with this patch? Or is it just forgotten?
The code in textbox.xml already includes this patch (just looking at the code).
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
HJ, can you verify this and mark verified-fixed ? thanks..
Confirming and marking verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.