New Firefox bug

[GoogleCodeExporter]

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 reported on code.google.com by Chad.R.B...@gmail.com on 16 Oct 2012 at 10:23

[GoogleCodeExporter]

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

Original comment by micha...@cascadewebdev.net on 16 Oct 2012 at 11:05

[GoogleCodeExporter]

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.

Original comment by evanpla...@gmail.com on 17 Oct 2012 at 3:52

[GoogleCodeExporter]

+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?

Original comment by Thanpolas on 24 Oct 2012 at 12:27

[GoogleCodeExporter]

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

Original comment by evanpla...@gmail.com on 24 Oct 2012 at 4:30

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

Original comment by evanpla...@gmail.com on 25 Oct 2012 at 2:22

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by evanpla...@gmail.com on 27 Oct 2012 at 5:40

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

This issue was closed by revision df79574a5f6d.

Original comment by evanpla...@gmail.com on 2 Nov 2012 at 4:14