If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

onchange function never gets called for GFX text control

VERIFIED FIXED in M9

Status

()

Core
Layout: Form Controls
P3
major
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: Kathleen Brade, Assigned: Eric Pollmann)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [19990909] requesting info from hangas regarding addressbook issues)

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
When changing any of the values for any of the html form controls, the onchange
function doesn't get called.  See attachment.
(Reporter)

Comment 1

19 years ago
Created attachment 337 [details]
example html with controls expected to detect "onchange"

Updated

19 years ago
QA Contact: cbegle → gerardok

Comment 2

19 years ago
Kathy: OnChange now works for the HTML <select> tag, but it doesn't work for
the input type="text" control. I'm not sure about others, but it would be
good to find out exactly which form controls don't work and file individual
bugs to appropriate people. (I don't think joki is the right target for
any of these.) Please specify which control in the Summary field
to assist searching for bugs.

Updated

19 years ago
Assignee: joki → pollmann

Comment 3

19 years ago
Sending this to pollmann.  He knows more about onchange than me these days.

Updated

19 years ago
Component: JavaScript → DOM Level 0

Comment 4

19 years ago
Moving to DOM Level 0 component.  Move to DOM Level 1 if that is more correct.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
QA Contact: gerardok → janc
(Reporter)

Updated

19 years ago
Target Milestone: M9
(Reporter)

Comment 5

19 years ago
We really need these to all work for M9.
Eric--can you fix this by then?
(Assignee)

Updated

19 years ago
OS: Mac System 8.5 → All
Hardware: Macintosh → All
(Assignee)

Comment 6

19 years ago
Hi Kathy!

The main issue I can think of here is the switch to GFX widgets as the default.
As such, enabling onChange for native widgets, I'm told, has a much lower
priority.  Do you need onChange enabled for native widgets or would enabling it
for GFX widgets be sufficient (or do you need both?)

From the example here, it seems, the controls in question are:

<SELECT>              Works only on GTK and Mac (GFX and Win not reported)
<INPUT TYPE=RADIO>    Not reported
<INPUT TYPE=CHECKBOX> Not reported
<INPUT TYPE=TEXT>     Not reported
<INPUT TYPE=PASSWORD> Not reported
<INPUT TYPE=FILE>     Not reported
<TEXTAREA>            Not reported

onChange does not work for any GFX rendered widgets, including the select widget
and the ender-based text widget.

Getting radios and checkboxes to report onChange events should be very doable by
M9, for either GFX or native or both.  Text inputs, passwords, text areas, and
file inputs are harder and may not be doable by M9.  Select widgets working on
GFX is probably doable, but Windows is very unlikely for M9 or even beyond. (See
bug 3322)

I guess what I need to know is, given all that, what are you highest priorities
to get working by M9?
(Assignee)

Updated

19 years ago
Component: DOM Level 0 → HTML Form Controls

Comment 7

19 years ago
IMHO, get the GFX widgets done and turned on as the default so we can
concentrate filing bugs and fixing what we are supposed to ship with!
If we are supposed to always use GFX, I don't care about native widgets.
Given that, supporting OnChange for the text widgets (both "input" and
"textarea") and Select are the most important.
(Assignee)

Comment 8

19 years ago
I'm cc'ing Kevin (GFX select guru) and Steve (GFX text guru) on this bug.  The
widgets themselves need to send out a NS_CONTROL_CHANGE event when there is a
change.  This can then be intercepted by the form frame code (already will be
for the select) and converted into a DOM onChange event.

Comment 9

19 years ago
I don't have the first clue about OnChange notifications, who is responsible for
firing them, what the mechanism is for a control to fire an event, etc.  Point
me in the right direction:  some documentation, a set of requirements, a working
example, etc, and I'll get it in right away for text fields, password fields,
and text areas.  What other notifications do I need to know about, and how
important are they?  Thanks.
(Assignee)

Comment 10

19 years ago
An example of working onChange events is the combo box on GTK:

The event is generated by the widget when the combo box is closed up:
nsComboBox::OnUnmapSignal() (widget/src/gtk/nsComboBox.cpp, line 344)

  // Generate a NS_CONTROL_CHANGE event and send it to the frame
  nsGUIEvent event;
  event.eventStructType = NS_GUI_EVENT;
  nsPoint point(0,0);
  InitEvent(event, NS_CONTROL_CHANGE, &point);
  DispatchWindowEvent(&event);

This NS_CONTROL_CHANGE event makes it's way to the
nsFormControlFrame::HandleEvent() (forms/src/nsFormControlFrame.cpp line 610)

      case NS_CONTROL_CHANGE:
        ControlChanged(&aPresContext);
        break;
    }

nsSelectControlFrame::ControlChanged() (nsSelectControlFrame.cpp line 1034)
This then determines if the selection actually was changed.  If so, it fires off
a DOM NS_FORM_CHANGE event (line 1104):

    if (changed) {
      nsEventStatus status = nsEventStatus_eIgnore;
      nsEvent event;
      event.eventStructType = NS_EVENT;

      event.message = NS_FORM_CHANGE;
      if (nsnull != mContent) {
        mContent->HandleDOMEvent(*aPresContext, &event, nsnull, NS_EVENT_FLAG_I$
      }
    }

For your case, the GFX text widgets should also fire a DOM event after a text
change.  This event should occur when the text field looses focus (i.e., when
the user clicks outside of the text box.  There seem to be two ways of doing
this, depending on which would be easiest:

1) Fire a NS_CONTROL_CHANGE event and pass that on to the nsTextControlFrame.
2) Fire a DOM NS_FORM_CHANGE event directly.

Other events that textareas/inputs in particular may need to fire (if they are
not already) include onfocus, onblur, and onselect.  These are listed in the
HTML 4.0 spec: http://www.w3.org/TR/REC-html40/interact/forms.html#edef-TEXTAREA
(Assignee)

Comment 11

19 years ago
*** Bug 4080 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 12

19 years ago
Created attachment 893 [details]
Ed Burns test case from bug 4080
(Assignee)

Comment 13

19 years ago
Created attachment 894 [details]
David Flanagan / O'Reilly test case from bug 4080

Updated

19 years ago
Depends on: 7001

Comment 14

19 years ago
For input type="text" (and probably for textarea) widgets, the onchange
needs to be when the text is changed, not just when the control looses focus.
A major use of this handler is to detect when the control has content, so
we can enable/disable associated buttons. Another use is for filtering the
text typed to suppress certain characters.
(Assignee)

Comment 15

19 years ago
Unfortunately, this is contrary to the spec, and is also not the way that
Navigator and IE 5.0 behave.  If you want to trap each key event, you'll need to
register for the onkeydown, onkeyup, or onkeypress event.

Also, unfortunately, this event is not yet wired up.  :S

Comment 16

19 years ago
From the HTML 4
spec(http://www.w3.org/TR/REC-html40/interact/scripts.html#events)

onchange = script [CT]
The onchange event occurs when a control loses the input focus and its value has
been modified since gaining focus.
This attribute applies to the following elements: INPUT, SELECT, and TEXTAREA.
----------------------
Charlie, I think you want to sit on onkeypress events as Eric indicated.

Comment 17

19 years ago
*** Bug 10154 has been marked as a duplicate of this bug. ***

Comment 18

19 years ago
Added myself to cc list, was waiting on 10154 which has been marked as a

duplicate of this bug.  Need this fix for mailnews and addressbook, autocomplete,

entering address book data, dialogs that enable and disable buttons based on

html:input data entered in fields, etc.

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 19

19 years ago
fixed

Updated

19 years ago
Status: RESOLVED → REOPENED

Comment 20

19 years ago
I just tested with code pulled at 4pm 8-4-99, and the onchange="" does not get
fired for html:input widgets in my xul file.
(Reporter)

Comment 21

19 years ago
Paul--I'm pretty sure that buster's fix won't fix the problem with native platform widgets.  Is that how you are verifying?  If so, you should turn on the xp widget pref and try again.  Btw, for text widgets I'm leaning toward use of onkeypress or onkeydown so I can handle the change right away rather than after the user starts to leave the field.ã

Updated

19 years ago
Resolution: FIXED → ---

Comment 22

19 years ago
I am using apprunner on a Mac.  I originally filed bug 10154 which was marked as

a duplicate of this bug.  So for my part this bug is not fixed unless it works in

the New Card Dialog of the Address Book from Apprunner.

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
Summary: onchange function never gets called → onchange function never gets called for GFX text control

Comment 23

19 years ago
changed the summary to reflect that the fix is for GFX text control only.
Native text widgets are no longer being supported.  Text controls will be turned
on by default early in M10.  For now, you have to manually set the pref
"nglayout.widget.mode" to 2.
Paul, if you saw this problem with GFX text controls, please reopen again.

Updated

18 years ago
Whiteboard: [19990909] requesting info from hangas regarding addressbook issues

Comment 24

18 years ago
hangas, does buster's fix satisfy your issues with addressbook?

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 25

18 years ago
marking verified per hangas
(thanks Paul)
You need to log in before you can comment on or make changes to this bug.