Side navigation
#12637 closed feature (duplicate)
Opened October 02, 2012 05:12AM UTC
Closed October 04, 2012 01:47AM UTC
more exposedProps problems jq 1.8.2 line 514
Reported by: | AS4More | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | unfiled | Version: | 1.8.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
line 514 of jquery-1.8.2.js
return window.JSON.parse( data );
triggers error in firefox 15.0.1
Exposing chrome JS objects to content without __exposedProps__ is insecure and deprecated. See https://developer.mozilla.org/en/XPConnect_wrappers for more information. file:///pject_folder/js/jq/jquery-1.8.2.js Line 514
I was willing and able to simple delete jqm when it started causing such errors, but this I can't overlook.
I'll call it a 'feature' issue, because I'm sure the expected behavior is to be in violation at this time.
Typically none disclosures and extreme complexity (in real world application/usage), make it pretty difficult for me to simply provide proof publicly, but you should know this stupid exposed props thingy is really causing a lot of problems.
Anyway I'll keep looking into it from this end, but it's strange that the jQuery code does not handle my basically simple usage well.
during a hashchange event I'm extracting some object parms from an xml file that's already loaded...
<state name="center" type="css"> { "left": 0, "top": 0, "z-index": 100 } </state>
via...
return jQuery.parseJSON(objString);
which is called from textContent of the shown xml of course...
$.extend(changes, getObjectFromString(item.textContent));
I'll keep hacking at it I guess (no other choice) but maybe this is really more officially a bug, it really shouldn't barf out (down the road, early warning for now) in this situation I don't think?
Attachments (0)
Change History (8)
Changed October 02, 2012 05:30AM UTC by comment:1
Changed October 02, 2012 06:13AM UTC by comment:2
Well I tried putting in CDATA block of the textContent which seemed to work before better, and so now I end up where I recall jqm seemed to falter on...
jq 1.8.2 line 322
src = target[ name ];
from my in theory I believe somewhat powerful line
targ[fn](fx, ao, (tSpeed * 1000));
Where fn is show() fx is 'scale' with the argumentsObject and millsecond converted time.
Wow I'm still totally lost I'll have to keep digging it typically does things with empty objects? That trigger this exposedProps error...
ec.storage.position
ec.storage.position is nothing in my code? seems to be the [name=ec.storage.position] on an empty object for 'target' that violates (and obviously returns undefined to src).
Still I'm not clear on why this even tries to access that and that it's a violation.
I hope this helps you guys see the nightmare that is exposedProps in jQuery.
I'll probably have to revisit this but I typically decide at some point it's not officially halting to program here yet and is just a warning I'd love to solve, but am hopefully that with this attempted explaination of my difficulty isolating the error, (aka this bug report) that maybe someone there will magically make this problem disappear in 1.8.3 for me ;-)
Changed October 02, 2012 06:21AM UTC by comment:3
This actually is passing through the jQuery UI for scale so maybe that's in violation and I should custom rebuild that?! it's pushing mode=show args to my things and stuff/!... well it's seemingly clearer to me that the violation is out of my jurisdiction and likely needs to be rebuilt by me from scratch to figure out or at least put and end to what's violating the blasted exposedProps issue.
Changed October 02, 2012 06:24AM UTC by comment:4
Alright well I've done what I can again it's not legal (non-disclosures so enough has been said already I think) or practical (sher volume and complexity) for me to post this to you in jsFiddle?!... so I've done all that I can do to bring awareness to my jQuery experiences on your end.
Changed October 02, 2012 01:36PM UTC by comment:5
resolution: | → duplicate |
---|---|
status: | new → closed |
Duplicate of #12470.
Changed October 04, 2012 01:30AM UTC by comment:6
resolution: | duplicate → fixed |
---|
Fix #12637: restore 1.8.1 ajax crossDomain logic. Close gh-944.
Changeset: da3ff3afe4d8421ae4ad04d6653f04ed6d7768e3
Changed October 04, 2012 01:46AM UTC by comment:7
resolution: | fixed |
---|---|
status: | closed → reopened |
Actually a deeper look shows it's this arguments block...
well it's actually the second try catch that returns the correct result but barfs out the error (I think)...
Obviously I'm trying to avoid eval along the way but have a support utility to hopefully find the correct data depending on the possible variations entered by the semi-user (engine xml writer, if that makes sense).
So I guess I'm going to have to change this somehow on my end, not sure I grasp yet way this is bad and if there is a solution that doesn't violate.