22472 - [DOGFOOD] onchange= doesn't appear to work for html:input

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Syd Logan]

I'll work on a test case, but this feature seems to have regressed. I marked
this as dogfood since IM uses this in its implementation. I added a backstop fix
to get around it, but this is a critical bug and should be fixed for dogfood.
See scopus 381232.

Comment 1

[rickg]

Please return this bug to me once you have a test case ready.

Comment 2

[daver]

Syd, can you please add more description as to how this affects users?

Comment 3

[Jim Roskind]

Still waiting for more input to help the PDT make a +/- comment on this.

Thanks,

Jim

Comment 4

[Syd Logan]

The IM code uses onchange to update an attribute that contains the screenname to
which an IM is being addressed in the initial compose window. Our code is
written to depend on the onchange handler firing so this screenname attribute is
updated.

Comment 5

[Jim Roskind]

Although a bother, I think we reviewed a bug like this earlier and did not
consider it dogfood.  You can see the target of an IM discussion when starting
the dialog... and you can see the source/recipient name during a chat session...
so the only problem is knowing which window is which (while iconified).
If the problem has greater ramifications that I just indicated, then please
comment and ask for additional consideration.

I can believe this a beta stopper... but it probably won't stop developers from
using the product (a.k.a., PDT-).

Comment 6

[Syd Logan]

Don't know if I agree, onchange is, from what I understand, a basic feature. We
should at least document that we don't support it, I'm sure there are going to
be developers expecting it works, and web pages that will break because it
doesn't work.

Comment 7

[Alec Flett]

I'm going to have to agree with syd here, because I have been affected by this
outside of AIM (in IRC he corrected himself to say he meant it was <html:input
type="text"> which is VERY common on web sites with forms)

Our own bugzilla uses it when you reassign a bug, and this bit me yesterday: to
reassign a bug, you have to type in the new e-mail address, and select the
"Reassign bug to" radio button.
In 4.x the onchange= handler works, so the radio button gets selected
automatically.
Yesterday, I tried to reassign a couple of bugs but since I expected the radio
button to move automatically, I didn't actually reassign the bugs! I didn't
notice this until today, so the people I needed to look at the bugs didn't even
see them until today.

Comment 8

[Jim Roskind]

The examples given are excellent, especially the ones relating to bugzilla
handling.  The fact that much of bugzilla will not work as expected, and hence
it is very hard to do bug handling, is probably reason enough to make this a
dogfood (developer essential) bug.
Changing to PDT+
Thanks,
Jim (PDT helper) Roskind

Comment 9

[Syd Logan]

I'll try and come up with a simple test case on the plane up later this morning.

Comment 10

[Syd Logan]

Attachment: test case

Comment 11

[Syd Logan]

Added simple test case. To use:

mkdir bin/res/test
copy the attachment to bin/res/test/test.xul
run mozilla resource:/res/test/text.xul
You should see "Hello World!" printed to the console, xterm as characters are
typed in the input field that is displayed.

Comment 12

[rickg]

Nisheeth -- I seem to recall that you had another event bug on XML/XUL. I'm
reassigning this to you as our best hope of finding a quick answer.

Comment 13

[Nisheeth Ranjan]

The onchange event does not fire for input elements inside HTML documents
either.  I'm attaching a simple HTML test case.  I don't know enough about the
event system to fix this quickly.  Re-assigning to Tom Pixley.

While testing, I tried the onmouseover event and that fired fine.

Comment 14

[Nisheeth Ranjan]

Attachment: HTML test case

Comment 15

[Sean Richardson]

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

Comment 16

[joki (gone)]

It appears to have been inadvertently commented out.  I put it back in.

Comment 17

[Chris Petersen]

Fixed in the Jan 20th build.

Comment 18

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.

Comment 19

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/7025a5c06d8a
[fenix] Closes https://github.com/mozilla-mobile/fenix/issues/22472: Filter out redirects from History search groups