I am getting a JavaScript error in IE6 when trying to send form data with xhrGet. Here is the code:
var kw = {
url: "Save.action",
load: function(data){
},
error: function(data){
},
form: "editData"
};
dojo.xhrGet(kw);
It works fine in IE 8. I am using Dojo 1.3.2 and the error in the uncompressed dojo.js is at line 8713.
Any suggesttions (other than "don't support IE6")?
Thanks
Looks like it was a combination of two things: Dojo not liking IE6 and me not using the preferred call. When I switched from xhrGet() to xhrPost() it works fine.
To answer the question above, my error was "invalid argument". I still think this is a problem with Dojo but am happy to move on.
Related
I'm trying to write a Chrome/Firefox extension in inject MathJax 3.0.1 into arbitrary web pages, Green Pi. It's working well for Chrome, but I'm having trouble with Firefox.
The content_script.js is
MathJax = {
chtml: {
fontURL: chrome.runtime.getURL("fonts"),
},
};
require("mathjax-full/components/src/tex-chtml/tex-chtml.js");
// This paints pages green
// require("green.js");
// // cat green.js == document.body.style.backgroundColor = "green";
(It's getting a little more involved when the user opts in/out of certain pages, but this isn't relevant here.)
Now, as noted in the code, the above works fine in Chrome, but fails in Firefox with the MathJax error
MathJax(?): window.MathJax is undefined
I don't see any other warning or error. Any hint on what might be going wrong here?
This turned out to be a MathJax bug after all, cf. https://github.com/mathjax/MathJax/issues/2399.
Some extensions seem to want to modify the response of a request:
It changes the response from regular JSON:
{"fields":"A, B, C","success":true}
to this:
{"fields":"A, B, C","success":true}<script type="text/javascript">(function () {
return window.SIG_EXT = {};
})()</script>"
This specific one is by the HubSpot Sidekick extension - https://chrome.google.com/webstore/detail/sidekick-by-hubspot/oiiaigjnkhngdbnoookogelabohpglmd
Is there any way to prevent this, aside from uninstalling the extension?
I'm one of the engineers working on the Sidekick extension. I wanted to give you a heads up that I've looked into this problem and diagnosed it as a small error in our JS code that was causing certain sites which fetched JSON to end up with adulterated payloads. This error has been fixed in the latest version of Sidekick (v2.4.49) released this afternoon and should not appear again. My apologies for any inconvenience the problem may have caused in the meantime.
I've been using Google Translate API for a while now, without any problems.
I recently pushed my app to my new server and even if it has been working perfectly on my local server, the same source code always gives me the "Required parameter: q" as error message.
I'm using NodeJS + ExpressJS + Request to send this request. Here's my test case:
var request = require('request');
request.post({
url: "https://www.googleapis.com/language/translate/v2",
headers: {"X-HTTP-Method-Override": "GET"},
form: {
key: /* My Google API server key */,
target: "en",
q: ["Mon premier essai", "Mon second essai"]
}
}, function(error, response, data) {
if (!error && response.statusCode == 200) {
console.log("everything works fine");
} else {
console.log("something went wrong")
}
});
Running on my local machine gives me "everything works fine", and running it on my server gives me "something went wrong". Digging more into it, I get the error message mentioned above.
As you can see, I'm trying to translate in one request two sentences. It's just a test case, but I really need to use this through POST request instead of doing two GET request.
I have no idea what this is happening, and I double checked my Google settings and I can't find something wrong there.
Also, I'm having no problem using Google Places APi with this same api key on my server.
I'm stuck. Anyone has any idea what's wrong here?
Well I finally found what was wrong: the new version of RequestJS doesn't work as the old one and my server was running 2.16 when my local machine was running 2.14.
The difference is the way the array is sent. I debugged and the old version was sending
key=my_api_key&target=en&q=Mon%20premier%20essai&q=Mon%20second%20essai
When the new version is sending
key=my_api_key&target=en&q[0]=Mon%20premier%20essai&q[1]=Mon%20second%20essai
So I just added 2.14.x instead of 2.x in my package.json file for now, hopefully it will get fixed soon — or maybe it's not a bug? I don't know.
This answer is a little late but to help people out there with this problem. The problem comes from the way the querystring module converts array parameters:
https://github.com/visionmedia/node-querystring
Its function qs.stringify converts fieldnames (q in the given example) that have an array value to the format:
q[0]=..q[1]=...
This is not a bug but an intended functionality. To overcome this problem without reverting to an old version of the request module you need to manually create your post by using the body option instead of the form option. Also you will need to manually add the content-type header with this method:
var request = require('request');
request.request({
url: "https://www.googleapis.com/language/translate/v2",
headers: {
"X-HTTP-Method-Override": "GET",
'content-type':'application/x-www-form-urlencoded; charset=utf-8'
},
body:'key=xxxx&target=en&q=q=Mon%20premier%20essai&q=Mon%20second%20essai'
}, function(error, response, data) {
if (!error && response.statusCode == 200) {
console.log("everything works fine");
} else {
console.log("something went wrong")
}
});
Obviously this is not as clean but you can easily create a utility function that creates the body string from the object the way you want it to.
things that pop into my head:
jquery file version on server and local PC are not the same
file encoding issues (UTF8 on PC ascii on server?)
have you tried testing it with chrome with Developer Tools open, then check "Network Tab" and verify exactly what is being sent to Google.
For me at least, when it works on one machine and not the other, it is usually due to the first 2 options.
Good Luck!
On POSTing data to my expressjs app, this is what I am getting:
node(58287,0x7fff771ad960) malloc: *** error for object 0x7ff8a8600c58: incorrect
checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6
Any idea why?
Update:
Here is some code:
Client side:
$.ajax({
url: 'user/' + id,
type: 'POST',
dataType:'JSON',
data: JSON.stringify(data),
success: function(response){
console.log(response);
}
});
Server side:
app.post('/user/:id', function(req,res){
var id = req.params.id;
console.log(data);
});
When I use JSON.stringify on the client side, I am hitting this weird error:
node(58461,0x7fff771ad960) malloc: * error for object
0x7fa861d00e28: incorrect checksum for freed object - object was
probably modified after being freed.
* set a breakpoint in malloc_error_break to debug Abort trap: 6
When I don't use JSON.stringify on the client side, I get 'null' strings on the server side.
Any ideas on what I am doing wrong?
I experienced this same error recently. Here's the fix:
Node.js has had some bugs that cause it to install improperly from source under OS X (see e.g. issue 2061). The good news is that the packaged installer installs it correctly. So, simply uninstall Node, then head to http://nodejs.org/#download and run the Macintosh Installer.
I've reported this bug on the Node issue tracker here.
This is liable to be a bug in nodejs's internals. (Or, if expressjs has any native-code bindings, perhaps expressjs.)
There's no easy way for you to write this kind of bug yourself in JavaScript. If you can reproduce this at will, they'd probably like a bug report. Try to figure out the least amount of code that can reproduce the problem.
I just got this error today, and updating Node.js through MacPorts from 0.8.9_0 to 0.8.10_1 fixed the issue.
It doesn't seem this was specifically adressed though, as bug reports and the changelog don't indicate that (http://blog.nodejs.org/2012/09/25/node-v0-8-10-stable/).
I haven't looked into the cause of these issues (plural - there are clearly at least two bugs somewhere along the line - jquery, node, express), although a summary and workaround are as follows:
When your client side code looks like in your updated question the server obviously shouldn't crash with a malloc error (bug #1), although it is understandable that the query is mistreated, since you're telling jquery to send json and then you send a string.
bug #2 is simply null --> "null" along the pipe. This at least doesn't cause a server crash, because data types match headers (i.e. everyone think we're using json), however someone is converting nulls to strings. My baseless suspicion is that it's express/connect.
Finally, the workaround is simply to wrap your data in a way that manages to be transported, and then unwrap on the server side:
Client side:
$.post({
url: 'user/' + id,
data: {workaround: JSON.stringify(data)}, // no null strings this way
success: function(response){
console.log(response);
}
});
Server side:
app.post('/user/:id', function(req,res){
var id = req.params.id;
var data = JSON.parse(req.body.workaround); // unwrap
console.log(data);
});
If I find time, I'll investigate and try and post a bug report somewhere (it's a problem when you don't know whose fault this is...), please try do this as well.
You are are calling console.log server-side on 'data' which is not defined in the scope of your example.
I have a content editor web part. Whenever I edit the content and then click save, the following errors occurred:
"Cannot retrieve properties at this time."
"Cannot save your changes"
How do you fix this?
I tried googling it.. there are some similar cases but not exactly the same. I tried this link:
www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/MS-SharePoint/Q_21975446.html
and this one:
support.microsoft.com/kb/830342
and this one:
blogs.msdn.com/gyorgyh/archive/2009/03/04/troubleshooting-web-part-property-load-errors.aspx
I found the answer!! apparently using mozilla firefox it worked. Then I found out that there is a javascript error in IE, this javascript error doesnt happened in firefox. how ironic!
Are you doing anything to modify the URL in an HTTPModule? I ran into this problem on a publishing site where a module was hiding the "/pages" part of the URL. Modifying the CEWP via the page when accessed w/o the "/Pages" wasn't working, but with the "/Pages" it was.
Example:
Got error: http://www.tempura.org/webpartpage.aspx
Worked: http://www.tempuri.org/pages/webpartpage.aspx
I don't see how this is an answer -- "don't use IE".
In my case (and apparently many others) it has something to do with ISA + SharePoint + host headers. I will post the fix if I find one.
I have had problems with this before and have found recycling the Application Pool often corrects the problem.
Rodney
IE8 -->
Tools --> Compatiblity View Settings --> CHECK THIS : Display All Websites in ....
If you are editing a webpart page, make sure that it is checked out. Sometimes the document library the webpart pages are in will have a "force check out to edit" option and it will give you errors if the webpage itself isn't checked out.
I had this same error recently. In javascript, I had written some prototype overrides (see examples below) to add some custom functions to the string and array objects. Both of these overrides interferred with SharePoint's native JavaScript somehow in IE. I removed the references from the master page and this issue was FIXED. Currently trying to find a work-around so I can keep them because things like the string.format function is very nice to have...
//Trim
if (typeof String.prototype.trim !== 'function') {
String.prototype.trim = function(){
return this.replace(/^\s+|\s+$/g, '');
}
}
//Format
String.format = function() {
var s = arguments[0];
for (var i = 0; i < arguments.length - 1; i++) {
var reg = new RegExp("\\{" + i + "\\}", "gm");
s = s.replace(reg, arguments[i + 1]);
}
return s;
}
I also faced the same problem. Finally it worked for me using url /Pages/Contact-Us.aspx instead of clean URL. It worked only with IE browser. Don't know why this was happening but anyhow it worked with me.
Use IE browser
Use Pages in the URLinstead of clean URL.
to me,
compatibility mode in IE8, to work