Skip to main content

Bug Tracker

Side navigation

#8368 closed bug (worksforme)

Opened February 24, 2011 01:15AM UTC

Closed February 24, 2011 08:43PM UTC

Regression: speed fix for $.trim results in incorrect behavior with non-breaking spaces IE

Reported by: znbailey@gmail.com Owned by:
Priority: undecided Milestone: 1.next
Component: unfiled Version: 1.5
Keywords: Cc:
Blocked by: Blocking:
Description

The fix for ticket 6868 (slow trim when trimming very large strings) looks like it undid the fix for ticket 4980, which solved the problem of IE not properly handling all whitespace characters correctly in its '\\w' character class (namely anything that isn't a plain space, e.g. unicode or non-breaking spaces).

Attachments (0)
Change History (2)

Changed February 24, 2011 01:51AM UTC by znbailey@gmail.com comment:1

I've been unable to come up with a minimally reproducible test case for this on JS Bin. I'm now fairly certain this may actually be caused by a custom String.trim method we added to the object prototype that was unaware of the IE bug.

Due to the new way the jquery trim code checks for a "native" version on the string object, it makes sense that is probably what's causing the problem.

Changed February 24, 2011 08:43PM UTC by dmethvin comment:2

resolution: → worksforme
status: newclosed

OK, then, sounds like it's not a jQuery bug.