Mutation Events not fired in disabled form controls

RESOLVED WONTFIX

Status

()

Core
DOM: Events
RESOLVED WONTFIX
12 years ago
4 years ago

People

(Reporter: Joao Eiras, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(10 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070109 Minefield/3.0a2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070109 Minefield/3.0a2pre

Mutation events aren't fired for disabled form controls like button, textarea, input and select.

Reproducible: Always
(Reporter)

Comment 1

12 years ago
Created attachment 251013 [details]
tc1 - DOMAttrModified in button
(Reporter)

Comment 2

12 years ago
Created attachment 251014 [details]
tc2 - DOMAttrModified in input
(Reporter)

Comment 3

12 years ago
Created attachment 251015 [details]
tc3 - DOMAttrModified in select
(Reporter)

Comment 4

12 years ago
Created attachment 251016 [details]
tc4 - DOMCharacterDataModified in button
(Reporter)

Comment 5

12 years ago
Created attachment 251017 [details]
tc5 - DOMCharacterDataModified in select
(Reporter)

Comment 6

12 years ago
Created attachment 251018 [details]
tc6 - DOMNodeInserted in button
(Reporter)

Comment 7

12 years ago
Created attachment 251019 [details]
tc7 - DOMNodeInserted in select
(Reporter)

Comment 8

12 years ago
Created attachment 251020 [details]
tc8 - DOMNodeRemoved in button
(Reporter)

Comment 9

12 years ago
Created attachment 251021 [details]
tc9 - DOMNodeRemoved in select
(Reporter)

Comment 10

12 years ago
Testcase 1 - DOMAttrModified in button works the first time it's loaded. If you refresh it it'll fail.
We should fix this for 1.9, imo.  We have XXX comments about this already, and I don't really know why we're blocking these events.  If it's a matter of preventing default actions for certain events (e.g. click), or even preventing propagation of said certain events, we should do that instead of nixing all events.

The affected classes are:  nsHTMLInputElement, nsHTMLButtonElement, nsHTMLTextAreaElement, nsHTMLSelectElement.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: in-testsuite?
Flags: blocking1.9?
Keywords: testcase
OS: Windows XP → All
Hardware: PC → All
(Reporter)

Comment 12

12 years ago
Created attachment 251028 [details]
tc 10 - capturing load listener in disabled button with child image
(Reporter)

Comment 13

12 years ago
A possible heuristic: the event won't be dispatch if the TARGET (and target only) is a disabled form control, AND the event ISN'T a Mutation event.

Other use cases should be determined.

About tc 10 - the disabled button wants to capture the image's load event. It should be allowed.
(Reporter)

Comment 14

12 years ago
My previous heuristic sucks :p

Just prevent any event caused by user input, like mouse events and key events.
Not a blocker, but we'd take a fix if we get one in time.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Assignee: events → nobody
QA Contact: ian → events
Given that we are deprecating mutation events, let's just WONTFIX this.

MutationObservers are the future.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX

Comment 18

4 years ago
MutationObservers are cool, but that's not the reason a disabled element should have ALL events broken. What about animationstart etc. ? 

btw.
https://bugzilla.mozilla.org/show_bug.cgi?id=952986
You need to log in before you can comment on or make changes to this bug.