174492 - setAttribute("disabled", false) causes textbox to not function properly

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[Kok Hoor]

After a call to setAttribute("disabled", true),
subsequent call to setAttribute("disabled", false)
changes both txt and txt2 to become enabled in appearance, but the controls
can't be focused and typed on, unlike btn and menulist.

Normally, this doesn't pose too much of a problem, as there are workarounds,
such as using the disabled property instead of the attribute.

However, when a textbox observes a broadcaster, it is unable to regain ability 
to be
focused and be typed on when the disabled attribute of the broadcaster is set 
to false.

A workaround will be to removeAttribute("disabled") instead of setAttribute
("disabled"),
but this is problematic because:

    - when removeAttribute("disabled") is called consecutively without a call 
to setAttribute("disabled", true),
        an onbroadcast event will not be fired, unlike two consecutive calls to 
setAttribute with the same value,
        eg:
            broadcaster.setAttribute("disabled", true);
            broadcaster.setAttribute("disabled", true);

Comment 1

[Kok Hoor]

Attachment: Test case

Comment 2

[Boris Zbarsky [:bzbarsky]]

happens on Linux too.

Comment 3

[Jared Williams]

Also happens with checkboxes..

<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
	onload="with (document.getElementById('cb-never')) { setAttribute('disabled',
true); setAttribute('disabled', false); }">

	<checkbox id="cb-never" label="this checkbox never works" />
</window>

Comment 4

[Edward Duffy]

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

Comment 5

[Alex Vincent [:WeirdAl]]

http://lxr.mozilla.org/seamonkey/search?string=input%5Bdisabled

This bug may be a WONTFIX.  Note in particular 
http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/forms.css 
which I believe a lot of bindings in XUL depend on indirectly.

Think about it.  In HTML, the disabled attribute doesn't have to have an 
attribute value.  When XUL sees a disabled attribute, it propagates that 
attribute (no matter the value, and in XUL it must have a value) to the HTML 
form control in the anonymous content.  That HTML control probably relies on 
the forms.css file to tell it how to render.

The only way to fix this is to include an XHTML-specific stylesheet (which we 
should probably do anyway) that checks for a disabled="disabled" CSS selector 
instead.  Then we'd have to tinker with the XUL binding so that a 
disabled="true" attribute on the XUL element becomes a disabled="disabled" 
attribute on the XHTML element.

Comment 6

[Andrew Schultz]

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

Comment 7

[Daniel O'Connor]

Attachment: Alternate Testcase

Simpler testcase which demonstrates problem. Earlier testcase produces error
"XML Parsing Error: xml processing instruction not at start of external entity
Location: https://bugzilla.mozilla.org/attachment.cgi?id=102897
Line Number 1, Column 1"

Comment 8

[Daniel O'Connor]

Similar behaviour appears present with textbox and the readonly attribute.
Replace instances of "disabled" with "readonly" in the alternate testcase
(https://bugzilla.mozilla.org/attachment.cgi?id=175392) to view behaviour

Comment 9

[[e-mail]]

As per comment 5 there's not a lot we can do about this.

Comment 10

[Alex Vincent [:WeirdAl]]

I'd still like to see an XHTML-specific stylesheet, somehow, and implementation
of that.  If we ever get that, we can reopen this bug at a later date.

Comment 11

[Andrew Schultz]

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