Bug Tracker

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#11297 closed bug (duplicate)

jQuery.data returning wrong data

Reported by: anonymous Owned by: anonymous
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.1
Keywords: Cc:
Blocked by: Blocking:

Description

Latest Chrome (Stable) and Safari (Mac OS 10.7)

HTML:

<p data-foo="7213e2">7213e2</p>

JavaScript:

console.log($('p').data('foo')) => 721300

Expected:

$('p').data('foo') => 7213e2

Change History (18)

comment:1 Changed 5 years ago by sindresorhus

Owner: set to anonymous
Status: newpending

Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket.

Additionally, be sure to test against the jQuery Edge version to ensure the issue still exists. To get you started, use this boilerplate: http://jsfiddle.net/FrKyN/ Open the link and click to "Fork" (in the top menu) to get started.

comment:2 Changed 5 years ago by dmethvin

Resolution: duplicate
Status: pendingclosed

If you want a string with no conversion, use .attr() instead.

http://www.learningjquery.com/2011/09/using-jquerys-data-apis

comment:3 Changed 5 years ago by dmethvin

Duplicate of #10174.

comment:4 Changed 5 years ago by Rick Waldron

Also, you may not be aware, but you're using "e notation"

comment:5 Changed 5 years ago by gibson042

What if we stop parsing exponent strings as numbers? I doubt anyone intentionally uses them for this purpose, and the change is byte-neutral after https://github.com/jquery/jquery/pull/668 (or +25 bytes before).

(I also looked into fixing #10174. That one's more expensive: an additional 30+ bytes gzipped if we do it like "" + parseFloat( data ) == data.replace( rnormalizeNum, ... ).)

comment:6 Changed 5 years ago by Rick Waldron

No way, e-notation is a number, is a number, is a number. typeof 1e6 === "number" I'm not going to special case something just because an edge case doesn't understand JavaScript. I'm half tempted to flat out delete this ticket.

comment:7 Changed 5 years ago by gibson042

typeof 0x42 === "number" too, but look at this: http://jsfiddle.net/EwTqJ/

comment:8 Changed 5 years ago by dmethvin

Well that's just wrong, but not a test case for this particular ticket.

comment:9 Changed 5 years ago by gibson042

I bring it up in this ticket because whether data-wtf="0x42" should become 66 or "0x42" hinges in part upon it.

comment:10 Changed 5 years ago by dmethvin

IMO we should be consistently annoying and return 66 since it's a valid JS number.

comment:11 Changed 5 years ago by jaubourg

Yeah, consistency is a bitch, thanks for poiting this out gibson042... now what to do? I suppose all those are valid *json* numbers not just javascript?

comment:12 Changed 5 years ago by gibson042

JSON syntax excludes hexadecimal notation, but includes exponential.

Also of note is its requirement (not shared by dataAttr) of at least one digit preceding the decimal point (e.g., ".4" is not a JSON number).

comment:13 Changed 5 years ago by jaubourg

So we're good if we do just what we do now (supporting exponent, not hexa)? Since we're supposed to parse JSON data, not Javascript formatted values.

comment:14 Changed 5 years ago by dmethvin

Every attempt is made to convert the string to a JavaScript value (this includes booleans, numbers, objects, arrays, and null) otherwise it is left as a string. -- http://api.jquery.com/data/

It doesn't say anything there about the value following JSON rules; parseInt("0x42"), +"0x42, and Number("0x42") all return the number 66. I wouldn't call the current result "every attempt" or even a "half-ass attempt" for that matter. :)

JSON rules don't affect the outcome since JSON.stringify({value: 0x42}) is {value: 66} with a native number and it never has to convert a string value (just parse the JSON).

comment:15 Changed 5 years ago by gibson042

We're definitely wrong in parsing hexadecimal strings as 0. If we want to strictly adhere to JSON, we're also wrong in parsing strings like "06" (extraneous leading 0) and ".3" (no digit before decimal point) as numbers.

comment:16 Changed 5 years ago by dmethvin

@gibson042 can you create a new ticket for this bug? Or I suppose we could hijack this one...

comment:17 in reply to:  16 Changed 5 years ago by gibson042

Replying to dmethvin:

@gibson042 can you create a new ticket for this bug? Or I suppose we could hijack this one...

#11309.

comment:18 in reply to:  14 Changed 5 years ago by jaubourg

Replying to dmethvin:

Every attempt is made to convert the string to a JavaScript value (this includes booleans, numbers, objects, arrays, and null) otherwise it is left as a string. -- http://api.jquery.com/data/

It doesn't say anything there about the value following JSON rules; parseInt("0x42"), +"0x42, and Number("0x42") all return the number 66. I wouldn't call the current result "every attempt" or even a "half-ass attempt" for that matter. :)

Yeah, but regarding objects and arrays, it states "it must follow valid JSON syntax including quoted property names". Consistency much? ;)

JSON rules don't affect the outcome since JSON.stringify({value: 0x42}) is {value: 66} with a native number and it never has to convert a string value (just parse the JSON).

Note: See TracTickets for help on using tickets.