WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#11181 closed defect (bug) (fixed)

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

Reported by: aldenta Owned by: 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 4 years ago.
11181.screenshot.png (13.2 KB) - added by aldenta 4 years ago.
11181-parents-vs-closest.html (1.2 KB) - added by aldenta 4 years ago.
Firebug profiler test for specific parents() vs closest() case

Download all attachments as: .zip

Change History (8)

aldenta4 years ago

aldenta4 years ago

comment:1 aldenta4 years ago

  • Keywords has-patch added

comment:2 follow-up: azaozz4 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

comment:3 in reply to: ↑ 2 ; follow-up: aldenta4 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.

aldenta4 years ago

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

comment:4 in reply to: ↑ 3 azaozz4 years ago

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

comment:5 Denis-de-Bernardy4 years ago

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