Make WordPress Core

Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#11181 closed defect (bug) (fixed)

.form-invalid remains on .form-field in IE after onchange

Reported by: aldenta's profile aldenta Owned by: azaozz's profile azaozz
Milestone: 2.9 Priority: normal
Severity: normal Version: 2.9
Component: JavaScript Keywords: has-patch
Focuses: Cc:

Description

In IE 6, 7 & 8 javascript change events won't get fired on .form-field so they need to be on an <input>. If there is an invalid form the red error style remains on input fields in IE even when the error has been corrected.

How to reproduce for Categories that already exist

  1. Using IE Go to Admin->Posts->Categories
  2. Submit form with category name that already exists (error should appear)
  3. Change content in category name to something that doesn't exist and submit the form (error should go away but it doesn't)

How to reproduce for Categories with no name

  1. Using IE Go to Admin->Posts->Categories
  2. Submit form with no category name (error should appear)
  3. Enter content in category name and tab out of field (error should go away but it doesn't)

How to reproduce for Tags with no name

  1. Using IE Go to Admin->Posts->Post Tags
  2. Submit form with no tag name (error should appear)
  3. Enter content in tag name and tab out of field (error should go away but it doesn't)

I'm not even sure why I was using IE but I thought I'd try to fix this...

Attachments (3)

11181.diff (1.5 KB) - added by aldenta 14 years ago.
11181.screenshot.png (13.2 KB) - added by aldenta 14 years ago.
11181-parents-vs-closest.html (1.2 KB) - added by aldenta 14 years ago.
Firebug profiler test for specific parents() vs closest() case

Download all attachments as: .zip

Change History (8)

@aldenta
14 years ago

#1 @aldenta
14 years ago

  • Keywords has-patch added

#2 follow-up: @azaozz
14 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [12215]) Fix removal of .form-invalid in IE, props aldenta, fixes #11181

#3 in reply to: ↑ 2 ; follow-up: @aldenta
14 years ago

Replying to azaozz:

I noticed that you changed .parents() to .closest(). I actually tried closest when I was working on the patch and ran some test code with the firebug profiler. Turns out that parents() is faster in that particular case and runs less queries. I've attached the test code in case you're interested.

@aldenta
14 years ago

Firebug profiler test for specific parents() vs closest() case

#4 in reply to: ↑ 3 @azaozz
14 years ago

Yes, .parents(selector) is a bit faster but .closest() includes the current element which may be needed in some cases.

#5 @Denis-de-Bernardy
14 years ago

  • Milestone changed from Unassigned to 2.9
Note: See TracTickets for help on using tickets.