We Keep Coding

Different behaviour of encodeURIComponent() in Firefox only

I encode a filename and send it as a part of URL like /rest/get?name=Filename.txt. In JS link construction is as simple as
url = '/rest/get?name=' + window.encodeURIComponent(file.name);
It works good for simple cases but for hardcore testing I use a file named
你好abcABCæøåÆØÅäöüïëêîâéíáóúýñ½§!#¤%&()=`#£$€{[]}+´¨^~'-_,;.txt
After URI encoding I expect to get a link
/rest/get?name=%E4%BD%A0%E5%A5%BDabcABC%C3%A6%C3%B8%C3%A5%C3%86%C3%98%C3%85%C3%A4%C3%B6%C3%BC%C3%AF%C3%AB%C3%AA%C3%AE%C3%A2%C3%A9%C3%AD%C3%A1%C3%B3%C3%BA%C3%BD%C3%B1%C2%BD%C2%A7%3F%3FabcABC%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD!%23%C2%A4%25%26()%3D%60%40%C2%A3%24%E2%82%AC%7B%5B%5D%7D%2B%C2%B4%C2%A8%5E~%27-_%2C%3B.txt
And I get it. The constructed link works ok in the latest versions of IE and Chrome but fails in Firefox. After some investigation I've found that in Firefox encodeURIcomponent works differently. Here's actual result in Firefox:
/rest/get?name=%3F%3FabcABC%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD!%23%EF%BF%BD%25%26%28%29%3D%60%40%EF%BF%BD%24%3F{[]}%2B%EF%BF%BD%EF%BF%BD^~%27-_%2C%3B.txt
Visual comparison (Chrome link is on the left and Firefox link is on the right):
I've also tried to copy and paste the valid link (constructed in Chrome) to Firefox and it works ok.
Why do I get different results?
I̶s̶ ̶i̶t̶ ̶a̶ ̶b̶u̶g̶ ̶w̶i̶t̶h̶ ̶̶e̶n̶c̶o̶d̶e̶U̶R̶I̶c̶o̶m̶p̶o̶n̶e̶n̶t̶(̶)̶̶ ̶i̶n̶ ̶F̶i̶r̶e̶f̶o̶x̶?̶
Does Firefox use a different encoding in encodeURIComponent()?
UPD. I've found similar questions (encodeURIComponent behaves differently in browsers for China as location [搜索] and
encodeURIComponent difference with browsers and ä-ö-å characters [äöå]), both without an answer.
UPD.2 Further investigation has shown that the following characters are encoded differently and causing 'File not found' exception on server:
你好
æøåÆØÅäöüïëêîâéíáóúýñ
½§¤
£€

I suppose your problem is not the encodeURIComponent() method. It's the encoding of whatever constructs file.name. Extend your question. How is file.name initialized? Where do the chars come from?

encodeURIComponent() is a native function so Firefox is obviously using some different implementation under the covers.
If you are stuck, then just deliver your own javascript implementation of encodeURIComponent(), then you'll get the same results across browsers. Here's a link how to get an open source copy of that:
encodeURIComponent algorithm source code

IE not loading page with Javascript and Raphael

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.

Type coercion bug in IE8 RegExp.exec()?

I don't know if this is a know problem in IE8, but I can't really find any info on it.
// The regex can vary but has to have a non-matching group defined:
var re = /^(\s)?[\d]+$/i;
// We call it with a string...
re.exec("2");
// We call it with a number...
re.exec(2);
Firefox and Chrome (can't try it in Opera right now) have no problem with either calls. But on IE8 the second call fails with an "Object does not support that property or method".
Is this a known bug or something?

I saw the same issues in an Ext JS 4 application. Lots of things were failing as Ext JS appears to pass numbers in the exec() method at times. The issue turned out to be a third party library SyntaxHighlighter. Removing this reverted the default IE8 behavior and re.exec(2); worked.
I'd suggest cutting down the external JS that you include in your app until you find the culprit.

Since exec takes a string I would make sure you are passing a string. By passing a number in I would say you are trying to count on grey areas of the way browsers implement javascript.

Javascript Methodname is replaced with !==

On the server lies a html file with javascript code included.
This javascript code includes a method called something like "CheckObject".
This file works for all users, except one specific (but important).
He gets a javascript error and in his browser sourcode appears something unbelievable:
The methodname "CheckObject" is replaced with "Check!==ect", means the "Obj" of the method name is replaced with !==.
Why could that be?
Hope anybody can help me!
Best regards

If he's using a browser that supports extensions (like Firefox, Chrome, and some others), it's probably worth disabling all of the extensions and seeing if the problem goes away.
If you haven't already, I'd completely clear his cache in case there was a bad page transfer once and the browser is reusing it.
I can't imagine how it would be happening reliably otherwise.

Partial Javascript Statements Logged To Server

I have some code that generates URLs to be used in various places across a site (image src, link hrefs, etc). I am seeing lines in the access logs which show some of the javascript code that generates the URLs masquerading as a file request.
For example, "/this.getIconSrc()" is one that I'm seeing quite a bit. I can't figure out how or why this is occurring and I can't manage to reproduce it without actually entering "http://whateverthesiteis.com/this.getIconSrc()" into the location bar. In most cases, these functions are chained together to generate a URL but the whole function chain does not appear in the server logs, just part of it.
I've probably invested around 30 hours trying to figure out why this is happening but cannot. It doesn't appear to be a browser issue as I've tried in IE 6/7, FF 2/3, Opera, Safari 3, and the problem does not occur. Has anyone else experienced something similar and, if so, what was the solution?

There's three possibilities really:
A bug in your HTML - malformed HTML causing onclick to leak into href, for example
A bug in your Javascript - myIcon.src = 'this.getIconSrc()'; - note the quotes that shouldn't be there
A poorly-written spider is hitting your site (like #Diodeus said: ___)
Edit:
Check the User Agent and Referrer in your logs - they may offer a clue.

Are you generating JavaScript calls like this? This may explain it.
___

#RoBorg... I'm thinking the most likely scenario is #3 since this particular function is actually only called in one place...
function whatever(){
var src = this.getIconSrc();
return src.replace( /((?:https?:\/\/)?(?:[^\/]+\/)*)[^\/]+/, '$1newimage.png' );
}