Skip to main content

Bug Tracker

Side navigation

#11297 closed bug (duplicate)

Opened February 07, 2012 03:51PM UTC

Closed February 07, 2012 03:57PM UTC

Last modified February 08, 2012 04:40PM UTC

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

Attachments (0)
Change History (18)

Changed February 07, 2012 03:53PM UTC by sindresorhus comment:1

owner: → 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.

Changed February 07, 2012 03:57PM UTC by dmethvin comment:2

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

Changed February 07, 2012 03:57PM UTC by dmethvin comment:3

Duplicate of #10174.

Changed February 07, 2012 04:28PM UTC by rwaldron comment:4

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

Changed February 08, 2012 12:06AM UTC by gibson042 comment:5

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, ... ).)

Changed February 08, 2012 04:20AM UTC by rwaldron comment:6

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.

Changed February 08, 2012 02:07PM UTC by gibson042 comment:7

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

Changed February 08, 2012 02:11PM UTC by dmethvin comment:8

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

Changed February 08, 2012 02:19PM UTC by gibson042 comment:9

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

Changed February 08, 2012 02:20PM UTC by dmethvin comment:10

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

Changed February 08, 2012 03:12PM UTC by jaubourg comment:11

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?

Changed February 08, 2012 03:38PM UTC by gibson042 comment:12

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

Changed February 08, 2012 03:56PM UTC by jaubourg comment:13

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.

Changed February 08, 2012 04:11PM UTC by dmethvin comment:14

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

Changed February 08, 2012 04:12PM UTC by gibson042 comment:15

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.

Changed February 08, 2012 04:24PM UTC by dmethvin comment:16

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

Changed February 08, 2012 04:35PM UTC by gibson042 comment:17

Replying to [comment:16 dmethvin]:

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

#11309.

Changed February 08, 2012 04:40PM UTC by jaubourg comment:18

Replying to [comment:14 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).