I'm maintaining this website that accepts multi-line inputs from user and sends the data via JSON. line break \n are decoded and encoded properly but somehow the \r chars are not accepted on the server side and I have the feeling I would need to escape them prior to sending them over. Before making the fix, I want to try to reproduce the issue but I can't find a way to do it !!!!
Do you have any recommendations?
EDIT after more investigation, it turns out that the issue is in IE only ( as in the \r chars get added when copying/pasting to the text input). Hijacking the text area did not change anything in FF or chrome and doing a data.description.replace("\r","") did not solve the issue either. Still poking around.
if you just want to reproduce the error, just add some js to populate the textarea:
document.getElementById('textarea-id').value = 'test\r\ntest';
Chrome's Developer Tool's Javascript Console lets you send JSON to your server using friendly jQuery/MooTools/Protoype syntax
Related
I use browserless.js (headless Chrome) to fetch the html code of a website, and then use a regular expression to find certain image URLs.
One example is the following:
https://vignette.wikia.nocookie.net/moviepedia/images/8/88/Adrien_Brody.jpg/revision/latest/top-crop/width/360/height/450?cb\u003d20141113231800\u0026path-prefix\u003dde
There are unicode characters such as \u003d, which should be decoded (in this case to =). The reason is that I want to include these images in a site, and without decoding some of them cannot be displayed (like that one above, just paste the URL; it gives broken-image.webp).
I have tried lots of things, but nothing works.
JSON.parse(JSON.stringify(...))
String.prototype.normalize()
decodeURIComponent
Curiously, the regular expression for "\u003d" (i.e. "\\u003d" in js) does not match that string above, but "u003d" does.
This is all very weird, and my current guess is that browserless is responsible for some weird formatting behind the scenes. Namely, when I console log the URL and copy paste it somewhere else, every method mentioned above works for decoding.
I hope that someone can help me on this.
Just to mark this one as answered. Thomas replied:
JSON.parse(`"${url}"`)
Just doing some JavaScript stuff in google chrome (don't want to try in other browsers for now, in case this is really doing real damage) and I'm not sure why this seemed to break my console.
>var x = "http://www.foo.bar/q?name=%%this%%";
<undefined
>x
After x (and enter) the console stops working... I restarted chrome and now when I do a simple
console.clear();
It's giving me
Console was cleared
And not clearing the console. Now in my scripts console.log's do not register and I'm wondering what is going on. 99% sure it has to do with the double percent signs (%%).
Anyone know what I did wrong or better yet, how to fix the console?
A bug report for this issue has been filed here.
Edit: Feeling pretty dumb, but I had Preserve log checked... That's why the console wasn't clearing.
As discussed in the comments, there are actually many different ways of constructing a string that causes this issue, and it is not necessary for there to be two percent signs in most cases.
http://example.com/%
http://%%%
http://ab%
http://%ab
http://%zz
However, it's not just the presence of a percent sign that breaks the Chrome console, as when we enter the following well-formed URL, the console continues to work properly and produces a clickable link.
http://ab%20cd
Additionally, the strings http://%, and http://%% will also print properly, since Chrome will not auto-link a URL-link string unless the http:// is followed by at least 3 characters.
From here I hypothesized that the issue must be in the process of linking a URL string in the console, likely in the process of decoding a malformed URL. I remembered that the JavaScript function decodeURI will throw an exception if given a malformed URL, and since Chrome's developer tools are largely written in JavaScript, could this be the issue that is evidently crashing the developer console?
To test this theory, I ran Chrome by the command link, to see if any errors were being logged.
Indeed, the same error you would see if you ran decodeURI on a malformed URL (i.e. decodeURI('http://example.com/%')) was being printed to the console:
[4810:1287:0107/164725:ERROR:CONSOLE(683)] "Uncaught URIError: URI malformed", source: chrome-devtools://devtools/bundled/devtools.js (683)
So, I opened the URL chrome-devtools://devtools/bundled/devtools.js in Chrome, and on line 683, I found the following.
{var parsedURL=new WebInspector.ParsedURL(decodeURI(url));var origin;var folderPath;var name;if(parsedURL.isValid){origin=parsedURL.scheme+"://"+parsedURL.host;if(parsedURL.port)
As we can see, decodeURI(url) is being called on the URL without any error checking, thus throwing the exception and crashing the developer console.
A real fix for this issue will come from adding error handling to the Chrome console code, but in the meantime, one way to avoid the issue would be to wrap the string in a complex data type like an array to prevent parsing when logging.
var x = "http://example.com/%";
console.log([x]);
Thankfully, the broken console issue does not persist once the tab is closed, and will not affect other tabs.
Update:
Apparently, the issue can persist across tabs and restarts if Preserve Log is checked. Uncheck this if you are having this issue.
Update 2:
As of Chrome 40, this issue is fixed.
I have a web app, which allows searching. So when I go to somedomain.com/search/<QUERY> it searches for entities according to <QUERY>. The problem is, when I try to search for . or .. it doesn't work as expected (which is pretty obvious). What surprised me though, is that if I manually enter the url of somedomain.com/search/%2E, the browser (tested Chrome and IE11) converts it somedomain.com/search/ and issues a request without necessary payload.
So far I haven't found anything that would say it's not possible to make this work, so I came here. Right now I have only one option: replacing . and .. to something like __dotPlaceholder__, but this feels like a dirty hack to me.
Any solution (js or non-js) will be welcomed. Any information on why do browsers strip url-encoded dots is also a nice-to-have.
Unfortunately part of RFC3986 defines the URI dot segments to be normalised and stripped out in that case, ie http://example.com/a/./ to become http://example.com/a
see https://www.rfc-editor.org/rfc/rfc3986#page-33 for more information
I'm testing out a website that runs fine on Firefox (Win/Mac), Chrome (Win/Mac) and Safari. I'm having difficulty with Internet Explorer unfortunately. I get the following error message:
SCRIPT65535: Unexpected call to method or property access.
raphael-min.js, line 8 character 64961
I've taken a look at the debug output which looks like just takes me to a part of the Raphel library:
c=a.getScreenCTM()||a.createSVGMatrix()
I've searched for this error message online, but I don't understand what solution is relevant to this case as I've no idea what is causing the problem. I am also using the jQuery library. Are there any tests that I can do that can give me more information about the source of the problem?
I just found how to patch this, in order to keep the compressed version of Raphael.
Replace (don't forget the coma):
c=a.getScreenCTM()||a.createSVGMatrix(),
By that (dont't forget the end space):
c;try{c=a.getScreenCTM()||a.createSVGMatrix()}catch(e){c=a.createSVGMatrix()};var
Works fine ! :)
Means :
c; : declaration of variable c, and stop the first instruction.
try{c=a.getScreenCTM()||a.createSVGMatrix()}catch(e){c=a.createSVGMatrix()}; : our instruction, surrounded by a try/catch, to avoid IE error
var + a space : (don't forget the space!) allow us to continue to declare variable
I found out that it's an issue with compression (of the js file). I had the exact same issue and I had been searching for a solution. Guess what? I tried it with the uncompressed Raphael file and voila! No more issues. Compressed file needs a tweak, it seems.
Come across this once in awhile.
Unpacked a zip file sent to me by a coworker. Loaded it up on my tomcat server to find out that there's this weird question mark at the beginning of the included JS file, preventing the JS file from being included properly.
I resaved the HTML file and the JS as new files and made sure encoding was UTF-8 and the line breaks were UNIX style.
Now I see the "ILLEGAL Token" error in Chrome and FF. Any ideas why?
EDIT:
Adding JS that is causing the issue. Anything inherently wrong with this? Per a comment, I think the removal of BOM fixed the issue but still getting the "ILLEGAL Token" message.
if(typeof deconcept=="undefined"){var deconcept=new Object();}
Hard to say with much confidence, but weird characters at the start of text files are very often the Byte Order Mark (BOM). See http://en.wikipedia.org/wiki/Byte_Order_Mark. Some software handles them well, and you see nothing, other software doesn't handle them correctly and you see weird characters.