New Firefox bug

[evanplaice]

New Firefox bug

[evanplaice]

From [email protected] on October 16, 2012 16:05:26

This is also an issue with IE (tested in IE9 on win7), like the above adding quotes fixes the issue.

[evanplaice]

From [email protected] on October 16, 2012 20:52:06

Damn... I thought we had this bug nailed already. You can see the details in bug 5 .

Chrome marks empty values as undefined while FireFox and IE use an empty string instead. So, both need to be tested for.

I may have changed something along the way that broke it again. Let me see if I can back-track to see if the previous fix was implemented properly and passes all the tests.

Give me a little time to get another test collection up and running the full gamut of RFC 4801 rules.

[evanplaice]

From Thanpolas on October 24, 2012 05:27:59

+1 I have the same issue, glad you are on it Evan.

I'd fix it but i am not sure what exceptional cases you are handling by examining the first match (m1) on the replace callback function...

It looks like m2 is what we need in both cases, why not use that?

[evanplaice]

From [email protected] on October 24, 2012 09:30:28

@-Thanpolas According to the tests, m2 should be working fine in its current state. As a temporary stopgap, I'll try releasing a fix to handle it the same way as m1 was patched previouslyI get the feeling that it will still fail under some circumstances.

I have tried like hell but I'm seeing some very bizarre behavior that indicates a deeper issue with Firefox's RegEx implementation. Long story short, just simply evaluating a match (ie using an 'if statement') mutates it somehow. As soon as I can isolate it completely, I'll be filing a bug upstream for their devs.

It is literally not possible to get all test cases to bass in both Chrome and Firefox (believe me, I've tried). Not without adding browser detection kludge. For the sake of quality in the long term I'd rather not go that route.

To avoid future problems and provide a parser that is more stable and easier to fine-tune I sill be ditching the monolithic regex match and replacing it with a FSM much like the one used in the line splitter.

Either way, I'll let you know when I have some code available to test.

[evanplaice]

From [email protected] on October 24, 2012 19:22:37

OK, screw using a monolithic regex for parsing CSV entries. Amazingly, I was able to roll out a new ND-FSM (Non-Deterministic Finite State Machine) entry parser with a quickness.

No more browser inconsistency pain...

It doesn't provide support for custom delimiter/separator characters yet and custom escape char support is no longer an option (it was kinda pointless to begin with). As soon as I have them working again, I'll drop the 0.65 release.

In the mean time, if you aren't using non-default delimiter/separator chars, feel free to pull the latest from the repository.

Note: The online testing and examples run the source directly from the repository, so that's another good place you can try it out.

Status: Fixed

[evanplaice]

From [email protected] on October 26, 2012 22:40:22

Owner: [email protected]
Labels: -Priority-Medium Priority-Critical

[evanplaice]

From [email protected] on November 01, 2012 21:14:27

This issue was closed by revision df79574 .