Opened 11 years ago

Closed 11 years ago

Last modified 9 years ago

#7609 closed defect (wontfix)

dojo.connect does not work with onchange DOM event in dijit.Widget in IE7

Reported by: mog Owned by: anonymous
Priority: high Milestone: tbd
Component: Dijit Version: 1.1.1
Keywords: Cc: corno@…
Blocked By: Blocking:

Description

Browser and OS details of where the bug manifests:

Internet explorer 7.0.5730.13 Windows XP Professional version 2002 SP3

Bug does not manifest in Firefox 2.0.0.16 on either Ubuntu 7.10 or Windows XP SP3 as above.

Bug manifests in 1.1.1 and in latest subversion checkout.

I will try in the next few days to create a test case but I've never worked with DOH before, so this may take a while.

Attachments (1)

test.html (1.1 KB) - added by mog 11 years ago.

Download all attachments as: .zip

Change History (16)

Changed 11 years ago by mog

Attachment: test.html added

comment:1 Changed 11 years ago by mog

Forgot to add a description of the test.html file - it contains source that replicates the bug.

Also, further investigation showed that replacing "onchange" with "onclick" or "onfocusout" results in dojo.connect working as expected. Only "onchange" with dojo.connect results in failure.

"Failure" means that the function connected to the node does not fire.

comment:2 Changed 11 years ago by James Burke

Resolution: invalid
Status: newclosed

I would not expect this to work since the input is being converted to a dijit.form.ValidationTextBox?, particularly in IE. IIRC, IE has a weird thing about names used as IDs in forms.

I believe the suggested path would be to give the input a specific id="" attribute and use dijit.byId() to grab the dijit instance and connect to method on the dijit. Maybe dijit.byId("theId").textbox's onchange method?

Although, hopefully if you are using a dijit.form.ValidationTextBox?, you do not need to know when it has changed if you are just doing validation logic. I am not that experienced with that dijit, so I cannot offer specific advice though. You have probably already seen this, but here is the book page for that dijit: http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit/form-validation-specialized-input/textbox-validating-currency-number

Marking this as invalid, since dijit methods should be used instead of trying to access the node directly.

comment:3 Changed 11 years ago by mog

Resolution: invalid
Status: closedreopened

My purpose is not validation.

I have three text boxes that interact with each other. When any of two values are entered, the third must change. There is a relationship between the three. I think this is a valid use case. For example, suppose someone wanted to use three text boxes to capture the equation for speed: speed = distance / time. You would enter any two and the third would recalculate.

I just want to trap the onchange event. I can probably do this by using dijit.byId instead of dojo.byId, however, if the dojo.connect API says that one can connect to all DOM events in all common browswers, this ought to be handled properly, or the cross-platform claim rescinded.

comment:4 Changed 11 years ago by James Burke

Hmm, I read through your forum posts, and so I tried the attached example using latest subversion on IE 7.0.5730.11 on Windows XP Version 2002 SP3, and it worked: I was able to enter text in the field and either tab or click out of the field and see an alert.

I checked Windows Update, but I do not have any newer versions of IE 7 or any updates that need to be installed.

Since the name of the input is passed down through the ValidationTextBox? I guess that allows the example to work. And maybe my memory on IE name vs. ID issues is faulty.

comment:5 Changed 11 years ago by James Burke

I should have refreshed the bug here, sorry I missed your previous comment. So it does look like the example works, at least for me, given the IE version above. Maybe you can give specific instructions on how the example fails? Like, I type this, then I do this action, but no alert?

comment:6 Changed 11 years ago by mog

Still no joy for me I am afraid, I tried it yet again and went through the HTML line by line to make sure that I hadn't submitted the wrong file. As before, onchange does not work, but if I change the event to onfocusout it does.

Is there an IE setting that I should be aware of?

comment:7 Changed 11 years ago by bill

You should really be doing

 dojo.connect(dijit.byId('price'), 'onChange', foo);

(note the capital C and the dijit.byId()).

Or easier yet:

<input name="price" type="text" dojoType="dijit.form.ValidationTextBox" id="price" onChange="foo">

comment:8 Changed 11 years ago by James Burke

I just put up two tests that use Dojo 1.1.1:

http://jburke.dojotoolkit.org/bugs/7609.html and http://jburke.dojotoolkit.org/bugs/7609-2.html

The first one should be your example as-is, except I converted paths to use Dojo 1.1.1 from the AOL CDN.

So I notice with that example, I get the alert if I tab out of the box, but not if I click out of the box. I did not have the style sheet paths fixed when I first tested, so maybe the dijit/dojo css files are doing something? Seems hard to believe though.

So I made the second test page that removes the dijits from the form and input box, and then it works correctly, even if I tab or click away after modifying the value in the field.

So I believe dojo.connect works fine, but either dijit.form.Form or dijit.form.ValidationTextBox?? could be interfering with the event in some way.

Can you verify that the second example works for you? If so, then I will likely convert this bug's name to mention an issue with something in dijit.form, but only for click actions.

BTW, I also put up a version that uses Dojo 1.2 beta 1 build, and I still have the problem with clicking out of the input, but tabbing away works fine: http://jburke.dojotoolkit.org/bugs/7609-3.html

comment:9 Changed 11 years ago by mog

Fantastic- the difference is indeed in click out vs tab out.

My example does work in IE if I tab out, but not if I click out. I just hadn't tried tabbing out. I also observe this with http://jburke.dojotoolkit.org/bugs/7609.html

With http://jburke.dojotoolkit.org/bugs/7609-2.html I also observe that tabbing and clicking both give the alert, with IE7. So, yes, I can verify that the second example works for me in IE.

Many thanks for your help.

comment:10 Changed 11 years ago by James Burke

Bill, did you want to comment on the tabbing working but the clicking does not? Or is the advice just to use the dijit onChange connection? If so, then we can close this bug as a wontfix.

comment:11 Changed 11 years ago by mog

Out of curiosity, why would the advice be to use dijit.onChange connection instead of dojo.onchange? That seems inconsistent to me.

I've already got a solution that works (I can use onfocusout), but it does seem like a large hole if some events are supported fully and some are not. I appreciate the difficulties of cross-browser development though.

comment:12 Changed 11 years ago by mog

I realise that I have been negligent in not once saying why I want to use dojo.connect and not dijit.connect.

I noticed that when I use dijit.connect, the event I get back is just a string containing the value of the form field. When I use dojo.connect I get the full Event object, which I can then use to stop propagation. If I don't have access to this, what happens is that the user fills in two fields, which changes the third, which then triggers onChange and propagates in an infinite loop.

That's why I couldn't just use onChange="foo" in my HTML in the first place. I could figure out a way to keep track of state, but the event objects seemed to already provide this.

comment:13 in reply to:  10 Changed 11 years ago by bill

Replying to jburke:

Bill, did you want to comment on the tabbing working but the clicking does not? Or is the advice just to use the dijit onChange connection? If so, then we can close this bug as a wontfix.

I'm not sure why that happens. I remember an issue in focus.js with onblur not getting called when you clicked a blank area of the screen (although in a simple test case it does); maybe it's related to that.

Replying to mog:

Out of curiosity, why would the advice be to use dijit.onChange connection instead of dojo.onchange? That seems inconsistent to me.

The advice is to connect to the widget's public onChange event rather than trying to directly access the <input> node inside of the widget. Because accessing the <input> node directly is like trying to access a private member in a class. You are going outside the API... and also off the beaten path (which can lead to problems with any software)

Replying to mog:

I noticed that when I use dijit.connect, the event I get back is just a string containing the value of the form field. When I use dojo.connect I get the full Event object, which I can then use to stop propagation. If I don't have access to this, what happens is that the user fills in two fields, which changes the third, which then triggers onChange and propagates in an infinite loop.

Hmm, OK, I don't understand that completely as your example doesn't have anything to do with propagation; maybe you have a handler on the <form> or <body> to catch onchange events?

Anyway, it seems like there's some bug here but given that you've found a workaround and given the unusual nature I'm also tempted to just close this as wontfix.

comment:14 Changed 11 years ago by mog

I didn't upload the full example because I thought I'd distil it to just the problem at hand, which was that I couldn't wire up the ValidationTextBox? using dojo.connect to "onchange". I can if you would find it interesting, but that's up to you.

Thanks for your help!

comment:15 Changed 11 years ago by bill

Component: GeneralDijit
Resolution: wontfix
Status: reopenedclosed
Summary: dojo.connect does not work with onchange DOM event in IE7dojo.connect does not work with onchange DOM event in dijit.Widget in IE7

That's OK, I'll take your word for it :-). I'm going to close this as wontfix for now as per above comments. Let us know if you see other issues. As for test cases, any file is fine, doesn't need to be DOH, although I suppose that would be ideal.

Note: See TracTickets for help on using tickets.