Bug Tracker

Ticket #6686 (closed bug: invalid)

Opened 5 years ago

Last modified 3 years ago

IE8 Change Event issue with Jquery 1.4.2

Reported by: budigelli Owned by: budigelli
Priority: undecided Milestone: 1.4.2
Component: event Version: 1.4.2
Keywords: needsreview, IE8 textbox change Cc: budigelli@…
Blocking: Blocked by:

Description

This issue is specific to 1.4.2 and fine with 1.3.2.

I have textbox with some watermark applied and as I go in and out of it, with out changing any text, it is raising onchange on IE8.

You could simply produce this with jQuery watermark plugin  http://digitalbush.com/projects/watermark-input-plugin/

Here is whats happening.

  1. Load textbox with empty/blank value.
  2. Wireup an event handler for focus event that clears the value if its not the watermark value we provided
  3. Wireup an event handler for blur event that puts watermark value in to the textbox if the value is not empty.
  4. Wireup an event handler to do same as blur event
  5. Set some watermark value to this textbox using JS.

Here is whats happening:

  1. Page loads with textbox
  2. JS plug-in puts in watermark value in to the textbox (No on change fires)
  3. On focus, JS plug-in clears watermark value.
  4. On blur, JS plug-in puts the watermark value back.

IE fires change event at this time; Firefox does not. As IE fires Change event before blur. This same code worked in jQuery 1.3.2.

This is from Microsoft documentation...  http://msdn.microsoft.com/en-us/library/ms536912(VS.85).aspx

They quote "This event is fired when the contents are committed and not while the value is changing. For example, on a text box, this event is not fired while the user is typing, but rather when the user commits the change by leaving the text box that has focus. In addition, this event is executed before the code specified by onblur when the control is also losing the focus."

Change History

comment:1 Changed 5 years ago by dmethvin

  • Component changed from unfiled to event

Just for some more background, the W3C says this:

The change event occurs when a control loses the input focus and its value has been modified since gaining focus.  http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents

I'm not sure if the W3C specifies the order in which the blur/change events should fire, although Microsoft does as you pointed out.

Most likely, this behavior change was introduced when fixing the problem that IE's native change event doesn't bubble, although the W3C says it should. Original commit for that is here:  http://github.com/jquery/jquery/commit/5dc6b7ce3469eaadb37a151d449e8d36571d1894

As for the plugin, a better approach would be to layer an element over the empty input with the hint. Changing the actual content may confuse form fillers, since they will "see" your hints as input.

comment:2 follow-up: ↓ 3 Changed 5 years ago by dmethvin

comment:3 in reply to: ↑ 2 Changed 5 years ago by budigelli

Replying to dmethvin:

Hi Dmethvin, Thank you for your prompt response. I took a quick look at your alternative and It does not seem to work on fields that already have labels for them.

For most of the fields I am applying the watermark for already have labels.

Date : [TextBox1] and watermark is usually the format of accepted date.

So, "Date" is already a label for [TextBox1]. With your proposed technique, I would need to have two labels one with properly marked class. For long forms, we could end up with lot of extra mark up.

Thanks for pointing out that link though. Nice trick. I will keep it in mind going forward.

comment:4 Changed 4 years ago by rwaldron

  • Owner set to budigelli
  • Priority set to undecided
  • Status changed from new to pending

Please provide a reduced jsFiddle test case, thanks!

Additionally, test against the jQuery 0 GIT version to ensure the issue still exists.

comment:5 Changed 4 years ago by rwaldron

  • Keywords needsreview, added

comment:6 Changed 4 years ago by trac-o-bot

  • Status changed from pending to closed
  • Resolution set to invalid

Automatically closed due to 14 days of inactivity.

Note: See TracTickets for help on using tickets.