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).
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.