Wedge

I'm only getting started... ;)

I don't understand your story about the behavio(u)r..?
Is there a problem with the chr() I've implemented to get rid of any problems for JSE? (It needs to be turned back manually whenever ob_sessrewrite isn't called, e.g. $txt handling in JS files.)

I'm not thrilled with the idea of a separate file for JS strings.
I would, however, be opened with a convention such as putting the js_ prefix to any string that should be in JS code, but even that is not needed with my trick... ^^

'kay, back from the outer world, immediately jumped onto this...
I was hoping changing .height() to .innerHeight would help, but it didn't.
After multiple tests, I managed to reduce the delay to under 200ms. Another stroke of genius, or maybe not: I simply increased the width of the span... If it's 5px instead of 1px, you need 5 times less additions to get the width, obviously... And a 5px difference doesn't matter much in the final result. It's not rocket science...

I'll still try to find other solutions. Apparently, just changing the display:inline of that span to display:inline-block seems to increase the speed, but I'm not sure if it's related to that... :^^;:

Doing Wysiwyg is a nightmare... :-/

@Dragooon> I actually used an external jQuery plugin for that, but it needed to be rewritten a bit because it's old and incompatible. Basically, IE provides a x/y position in its select range object, so that's perfect, but other browsers don't, so the plugin creates a hidden textarea with no scrollbars, fills it with the text up to the caret position, and gets the caret position from that. Well, it's easy to get the vertical position, but as for the horizontal position, I'm not too sure, haven't delved too deeply into its code... All I know, is that it works ;)

@Arantor> Yup I did notice that, and I'm planning to fix it, but right now I'm lost in a larger rewrite of the notification code and that error gets in my way :lol: Also, I edited your link out -- it's a public page, and I don't want Google following a link that generates errors for guests..!

Note to self: grepWin supports search history. Just needed to double-click the search box... :)
Still doesn't have a preview pane, though. Only offers one line of preview if choosing 'contents' in the bottom of the window. Better than nothing, I suppose...

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.

I've made a few changes to the notification stuff, and uploaded them here, but not committed, so you can easily compare with your local install...
More importantly -- I've (temporarily..?) disabled auto-markread when clicking the notification, so that I can actually have time to style the popup at all... :whistle:

I think it would be best if we went for an approach more similar to Facebook's. Not that all they do is great, but in particular, their notification system is pretty good, and pretty much the only thing I use on their site...Hopefully today I'll have included that in script.js, but first I'll commit a changed version of notifications.js so that it's easier for you guys to track all the changes I made, then I'll make another commit where I merge both files together.

File size of original notifications.js when gzipped: 744 bytes
Current file size: 578 bytes

Ideally, getting it under 500 bytes before the merging would be satisfying for me. This will require rethinking some of the code, though, and I'll put the priority on getting it to look nice.Alrighty.
We should also make sure that all unread notifs are sent by e-mail before they're pruned... Is it accounted for?

Also, a strange error in the log...
A *guest* accessed a ;area=getunread page. I don't know how the hell they found the link to that..?! I tried logging off, but nothing showed up. Hmm, maybe it's in the footer JS...? I'll have a look again.