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

Flash v11.8.800.168 function call fails in Internet Explorer

Company recently upgraded to Flash v11.8.800.168 and a flash movie which is loaded using SWFObject (1.1) is not working correctly in Internet Explorer (Firefox works fine). The movie is loaded dynamically using a jquery document.ready method using the "new SWFObject(...); so.write("ID")" method (again SWFObject 1.1).\
The movie on load calls a JavaScript function (which is built dynamically using server scripting). The function is being called correctly as checked by a debugger. The JavaScript function calls a method in the flash movie passing it some XML (which is used to render some user and navigation items).
Something like this:
function calledFromFlash() {
document.getElementById("FlashMovie").renderUsingXml('<?xml version 1.0"?><lotsofxml></lotsofxml>');
}
Like I said, this all works still in Firefox with the new Flash version.
When I step through the function above, using step into with the IE Debugger, I get the following steps:
function anonymous() {
return eval(this.CallFunction("<invoke name=\"renderUsingXml\" returntype=\"javascript\">" + __flash__argumentsToXML(arguments, 0) + "</invoke>"));
}
At this point, I checked the arguments variable and it contains the XML as one would expect. After the next step into, I get this:
try { __flash__toXML(calledFromFlash(undefined)); } catch (e) { "<undefined/>"; }
At this point the debugger is already on the catch, yet one more step into take the code into the "<undefined/>" section and I can see that e is Object Expected
What I've tried:
Static implementation without SWFObject. This works. But then Firefox doesn't process the XML properly (and it seems to be the same issue as IE)
Upgrading to SWFObject 2.2. Using dynamic implementation it fails still. Using static implementation it works in IE but not Firefox
This is NOT my flash movie, the source is... well, I don't know. The guy that wrote it has left the company. That said, this seems like such a crazy issue.
My proposed fix is simply to use SWFObject for Firefox and use a static implementation for IE, but I really want to know what is wrong.

This was caused by a bug in Flash Player 11.8.800.168. It has been fixed in 11.8.800.175.
Bug fixes:
3630443 - [External][Windows][IE] ExternalInterface.call() method with non-ASCII text as a parameter corrupts the characters on the Javascript side

What does IE use //# in javascript for?

So, a bug in a piece of javascript revolved around code similar to :
<script>
(function() {
if (true) {
//#todo: do we need to set total or -- ?
alert('hello?');
}
})();
</script>
In the larger system IE complained "Expected ';' ". In the small scale example IE simply caused a warning about blocking ActiveX controls.
Obviously, "//#" has some context to activeX controls in IE. I was unable to find this as searching for the symbols was useless, and any search about special comments in IE result in the conditional html comments. I am just curious how the //# are supposed to be used in IE.

The IE JScript engine supports conditional comments which turn comments written in a particular way into code (partially). However, you are not using those.
In your case it seems to be a way to tell e.g. an IDE that there is a TODO item. The error you got is most likely unrelated.

Unless there's some quirk about IE that I don't know, the //#todo is just commenting fluff that some programmers use when they are too lazy/don't know how to implement something.

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.