New Firefox bug

[evanplaice]

From Chad.R.B...@gmail.com on October 16, 2012 15:23:20

What steps will reproduce the problem? 1. Use my data in Firefox
2. use toObjects

My new data looks like this.

resNum,DataCol,ColorCol
16S:(1-8),4,purple
16S:(9-25);16S:(913-920),1,red

I use toObjects. This runs perfectly fine on my website and on the test website in Chrome. It fails in Firefox. Firefox produces an all empty array. I need all these punctuation marks.

Actually, I tried something simpler

w,r,t
2,4,purple
4,1,red

This isn't working in Firefox either. It's failing in 0.64 and it fails on the Basic Usage Demo.

OK, I did some more testing for you. Firefox is requiring all data to be in quotes.

toy,test,kelp
1,2,3
4,5,6

will not work, but

"toy","test","kelp"
"1","2","3"
"4","5","6"

will work

Quotes should be optional. I only put quotes around my data if the data contains a comma.

Original issue: http://code.google.com/p/jquery-csv/issues/detail?id=14

[evanplaice]

From micha...@cascadewebdev.net 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 evanpla...@gmail.com 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 evanpla...@gmail.com 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 evanpla...@gmail.com 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 evanpla...@gmail.com on October 26, 2012 22:40:22

Owner: evanpla...@gmail.com
Labels: -Priority-Medium Priority-Critical

[evanplaice]

From evanpla...@gmail.com on November 01, 2012 21:14:27

This issue was closed by revision df79574 .