So, I don't know why, but today I decided to tackle JSE quirks...
If you'll remember (or not), six months ago I mentioned in rev 1767 that I was looking for a volunteer to go through the codebase with on[a-z]+="[^"]*JavaScriptEscape and ensure these calls are properly escaped.
Well, six months ago I didn't know about grepWin, which is a great tool (I would gladly replace my other search'n'replace tool if it supported both a history of previous searches, and a quick preview of matches 'in context'), and most importantly, supports multi-line regex searches.
So there are about 75 matches across Wedge + plugins (without counting some special cases like 'onclick' => 'return something' which I didn't test for), that's a lot but it's doable.
Now I'd like to discuss the JSE function itself, and the situations in which it can cause problems.
As $txt protections inside .js files
Nothing to say... It works well. JS files use single quotes everywhere, so it's well optimized, too. One has to remember, though, not to use a $txt inside a double-quoted string. No reason to do that, though..?
Inside an inline event
Ah, this...
echo 'onclick="return', JavaScriptEscape('I say "Hello!" and you say "Get lost!"...'), ';"'; isn't gonna work, because you can't escape a double-quote properly inside an inline event... So, that's why I added an extra bool param to JSE to tell the engine that we're within a HTML param, and that we need to turn any double quotes to "...
That's good.
Especially since I (somehow foolishly, but I stand by my decision) turned all quot entities to double-quotes in language files, to make them more readable. (I think the upside is better than the downside here.)
Now, the thing that REALLY matters, is that Wedge doesn't leave inline events as they are... You know that. It loads jQuery at the end of the page, so it moves inline events to the end, too. I was thinking, it's pretty silly to bother with that...?!
I can very, very easily allow for escaped double-quotes (\") in inline events. They'll just get moved out of the HTML anyway... But, does that mean I should escape all double-quotes inside JSE without distinction..? I don't think so. Outside of an inline event, the double-quotes will remain escaped, and I don't like the idea.
And yes, I need to escape double quotes, there's no other realistic option.
So, do I need to use the bool in every use of JSE inside an inline event..?
Inside footer JS
I think that's the last possibility..?!
This is where I've been looking today. Fact is, in a Wedge HTML page, all tag params are surrounded by double quotes. There are tons of double-quotes in every page. There are very little single quotes. So I did a quick test, and instead of JSE returning 'string', it returned "string', and guess what? I saved about 10 gzipped bytes just by doing that on the home page. It's not MUCH, and certainly not enough to warrant this topic, but... It's my hobby, after all.
Where is JSE used the most, then..?
Here's a solution I was thinking of... It's crazy, at least as much as I can be.
In JSE, return the string surrounded by chr(15) (or whatever unused character in the invisible ASCII range), and escape double-quotes in the string with chr(16) or whatever.
Then, at ob_sessrewrite time, once the event delaying process is completed, turn back chr(15) to double-quotes, and turn chr(16) to double-quotes only if they're not inside a string, otherwise turn them to " entities. I'm thinking of this as I'm typing, so it probably doesn't make a lot of sense... But I'd love being able to solve the need for the 'escape double quotes' boolean param. I think I'll do that *at least* for chr(16)...
Also, I think we could use double-quotes by default in JSE, and only use single-quotes when called within $txt protection code in JS files.
Okay, that's it... The proverbial headache is coming up. I can feel it.
If you'll remember (or not), six months ago I mentioned in rev 1767 that I was looking for a volunteer to go through the codebase with on[a-z]+="[^"]*JavaScriptEscape and ensure these calls are properly escaped.
Well, six months ago I didn't know about grepWin, which is a great tool (I would gladly replace my other search'n'replace tool if it supported both a history of previous searches, and a quick preview of matches 'in context'), and most importantly, supports multi-line regex searches.
So there are about 75 matches across Wedge + plugins (without counting some special cases like 'onclick' => 'return something' which I didn't test for), that's a lot but it's doable.
Now I'd like to discuss the JSE function itself, and the situations in which it can cause problems.
As $txt protections inside .js files
Nothing to say... It works well. JS files use single quotes everywhere, so it's well optimized, too. One has to remember, though, not to use a $txt inside a double-quoted string. No reason to do that, though..?
Inside an inline event
Ah, this...
echo 'onclick="return', JavaScriptEscape('I say "Hello!" and you say "Get lost!"...'), ';"'; isn't gonna work, because you can't escape a double-quote properly inside an inline event... So, that's why I added an extra bool param to JSE to tell the engine that we're within a HTML param, and that we need to turn any double quotes to "...
That's good.
Especially since I (somehow foolishly, but I stand by my decision) turned all quot entities to double-quotes in language files, to make them more readable. (I think the upside is better than the downside here.)
Now, the thing that REALLY matters, is that Wedge doesn't leave inline events as they are... You know that. It loads jQuery at the end of the page, so it moves inline events to the end, too. I was thinking, it's pretty silly to bother with that...?!
I can very, very easily allow for escaped double-quotes (\") in inline events. They'll just get moved out of the HTML anyway... But, does that mean I should escape all double-quotes inside JSE without distinction..? I don't think so. Outside of an inline event, the double-quotes will remain escaped, and I don't like the idea.
And yes, I need to escape double quotes, there's no other realistic option.
So, do I need to use the bool in every use of JSE inside an inline event..?
Inside footer JS
I think that's the last possibility..?!
This is where I've been looking today. Fact is, in a Wedge HTML page, all tag params are surrounded by double quotes. There are tons of double-quotes in every page. There are very little single quotes. So I did a quick test, and instead of JSE returning 'string', it returned "string', and guess what? I saved about 10 gzipped bytes just by doing that on the home page. It's not MUCH, and certainly not enough to warrant this topic, but... It's my hobby, after all.
Where is JSE used the most, then..?
Here's a solution I was thinking of... It's crazy, at least as much as I can be.
In JSE, return the string surrounded by chr(15) (or whatever unused character in the invisible ASCII range), and escape double-quotes in the string with chr(16) or whatever.
Then, at ob_sessrewrite time, once the event delaying process is completed, turn back chr(15) to double-quotes, and turn chr(16) to double-quotes only if they're not inside a string, otherwise turn them to " entities. I'm thinking of this as I'm typing, so it probably doesn't make a lot of sense... But I'd love being able to solve the need for the 'escape double quotes' boolean param. I think I'll do that *at least* for chr(16)...
Also, I think we could use double-quotes by default in JSE, and only use single-quotes when called within $txt protection code in JS files.
Okay, that's it... The proverbial headache is coming up. I can feel it.
