Opened 10 years ago
Closed 10 years ago
#8368 closed bug (worksforme)
Regression: speed fix for $.trim results in incorrect behavior with non-breaking spaces IE
| Reported by: | 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).
Change History (2)
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
OK, then, sounds like it's not a jQuery bug.
Note: See
TracTickets for help on using
tickets.
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.