setting then unsetting readonly/disabled on textbox disables input

VERIFIED FIXED in mozilla1.0.1

Status

()

Core
Editor
P3
major
VERIFIED FIXED
18 years ago
4 years ago

People

(Reporter: HJ, Assigned: David Hyatt)

Tracking

Trunk
mozilla1.0.1
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Updated

18 years ago
Blocks: 46029
(Reporter)

Comment 1

18 years ago
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?
(Reporter)

Comment 3

18 years ago
Created attachment 27876 [details]
Testcase
(Reporter)

Comment 4

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

Comment 6

18 years ago
Hmm. Nope, this is Editor (text editing and entry).
Assignee: trudelle → beppe
Component: XP Toolkit/Widgets: XUL → Editor
QA Contact: jrgm → sujay

Comment 7

18 years ago
off to kin
Assignee: beppe → kin
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 8

18 years ago
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 hyatt@netscape.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".
(Reporter)

Comment 9

18 years ago
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.
(Reporter)

Comment 10

17 years ago
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).
(Reporter)

Updated

17 years ago
Summary: setting then unsetting readonly/disabled on textfield disables input → setting then unsetting readonly/disabled on textbox disables input
(Reporter)

Comment 11

17 years ago
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. 
(Reporter)

Comment 12

17 years ago
Created attachment 30882 [details]
New testcase (uses the new XUL 1.0 syntax)
(Reporter)

Comment 13

17 years ago
Created attachment 30883 [details]
Try this one because of the mime type change

Comment 14

17 years ago
Reassigning to hyatt@netscape.com, 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
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla1.0.1
(Reporter)

Comment 15

17 years ago
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.
(Reporter)

Comment 16

17 years ago
Created attachment 36998 [details] [diff] [review]
cvs diff -u (patch)
(Reporter)

Comment 17

17 years ago
Ok i'm using this patch some weeks without problems.
Keywords: patch, review
(Reporter)

Comment 18

17 years ago
if this goes in then bug 80200 is also fixed
Blocks: 80200

Comment 20

17 years ago
Is there something wrong with this patch? Or is it just forgotten?
Keywords: mozilla0.9.8
The code in textbox.xml already includes this patch (just looking at the code).
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 22

16 years ago
HJ, can you verify this and mark verified-fixed ? thanks..
(Reporter)

Comment 23

16 years ago
Confirming and marking verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.