similar to Mac bug #7124; possibly related to bug #7127 having to do with labels Given a disabled editfield (html:input type="text" or type="password"), the user can click on it to activate it. The user should not be able to activate an editfield by clicking on it. Also, the html:input type="file" controls and the html:select control aren't disabled at all.

possibly a XUL problem, reassigning to hyatt

(1) Please attach a test case. (2) Please verify that the problem is unique to XUL (try it in HTML and see if it works).

Does this occur in HTML? This is only my bug if it is a XUL problem. Otherwise it is a bug in the form elements themselves and should be assigned to karnaze.

I don't have an html example but I think this is probably karnaze's bug.

reassign to karnaze I'm not positive this can be reproduced on Windows in html but I'll test there to be sure.

Reassigning to Eric.

in an html file, <textarea> also does not disable/enable (user can click in it and then type)

Moving to M15. Being able to use a disabled control is bad but doesn't prevent the user from making use of the form.

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Moving out to M17.

Rescheduling

*** Bug 7124 has been marked as a duplicate of this bug. ***

I'll run through my DOM tests again sometime in the next few weeks to see if there is any low hanging fruit like this around still. Note: also check readonly! (see above dup)

These work for all inputs except readonly for the file input - still allows typing. The file input is less common than most, and this seems like a minor bug, moving to Future.

cc mstoltz in case he knows why...

removing myself from CC list.

<input readonly> is also not read-only when type="radio" or type="checkbox".

Bulk reassigning form bugs to Alex

-> over to owner

Ah, yes, the famous XUL 'file input' widget. Oh, wait, XUL doesn't have one. -> alexsavulov, HTML Form Controls according to pollmann's last comment, this is only about <input type='file' readonly>, which is not readonly in current trunk builds

-> over to owner (hope is not me :-)

The notes on this bug seem to indicate that it is currently only happening when input type="file" readonly is used, but this testcase shows it is also happening for input type="file" disabled. You are not able to select the input field or the browse button by mouse, but you can select browse by using the tab key and the enter key, and if you select a file through browse its path is placed in the input field. Using build 2002012803, seeing this on all os, pc and mac.

The disabled problem is bug 92858 (soon to be fixed). The readonly problem, the focus of this bug, is invalid since according to the spec readonly is only supported on input type="text" and input type="file". http://www.w3.org/TR/2001/WD-DOM-Level-2-HTML-20011210/html.html#ID-88461592

... is only supported on input type="text" and input type="file".... have to be: ... is only supported on input type="text" and input type="password"....

Please, could somebody reopen this bug? The HTML specification states that only text and password fields support the readonly attribute. That's OK. But the reason to not include file fields in this list is that the specification does not state how to implement this field type. If a browser implements it as a simple button, with no associated text field, there is no sense in a readonly attribute. A bit of common sense could be applied here. If file fields are implemented as "extended text fields", at least from a final user point of view, the readonly attribute should be supported.

It's not an enabled text field on trunk.