Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
3766
The Pub / Re: Remove flash dependency from AeMe?
« on January 30th, 2013, 03:20 PM »
Flash isn't a burden...
Class B = if we hide the feature instead of refusing its use, it's okay.
Class B = if we hide the feature instead of refusing its use, it's okay.
3767
Features: Theming / Re: CSS and JavaScript minification
« on January 30th, 2013, 12:59 PM »
(Oh, a topic with a post from [Unknown]... :P)
Nice little time waster on my side: yesterday I discovered that Google released (years ago!) an online tool for compressing JS through Closure on their website.
Because Closure's results are pretty much better than UglifyJS's (UglifyJS is only better on jQuery, for some reason... they even acknowledge it on their official website :^^;:), albeit much slower to compile, I'd always wanted to compare with Packer.
And here I go... I implemented a 'closure' minification method for Wedge.
It works, but it's definitely not going to be default!
- It's SLOW AS HELL. script.js takes about 5 seconds to compile, for instance! It takes like half a second with my local Packer. And I'm not even checking... It may be less.
- Google has set a limit on the number of times you can compile a script per hour or something. While I guess it's perfectly acceptable in a situation where you would simply upload modified versions of your scripts from time to time, you definitely can't debug anything with that. (Not that you'd want to -- see compilation time.) I need to do the debugging on THAT particular platform though, and believe me I'm enraged that they're not providing me with a way to bypass their limitation WHILE I'm implementing support for THEIR product... -_- Overall, it seems like they can 'take' a dozen compiles at most, and then... Poof. I haven't been able to compress anything this morning, for instance.
- I implemented a fallback -- if Google fails, then Wedge will just re-do the job with good ol' Packer, and skip Closure for all subsequent minification calls in the same page load.
- It's more efficient than Packer, saving a lot more bytes in uncompressed form, but once gzipped, it's pretty similar. On average, I'd say that a Closure version is about 100 bytes shorter for each gzipped file. I'm thrilled with the extra bytes, you know how I am, but I'm definitely not thrilled enough in a realistic configuration.
So, it'll be an option I think, but probably no more than a non-default, warning-filled option...
Nice little time waster on my side: yesterday I discovered that Google released (years ago!) an online tool for compressing JS through Closure on their website.
Because Closure's results are pretty much better than UglifyJS's (UglifyJS is only better on jQuery, for some reason... they even acknowledge it on their official website :^^;:), albeit much slower to compile, I'd always wanted to compare with Packer.
And here I go... I implemented a 'closure' minification method for Wedge.
It works, but it's definitely not going to be default!
- It's SLOW AS HELL. script.js takes about 5 seconds to compile, for instance! It takes like half a second with my local Packer. And I'm not even checking... It may be less.
- Google has set a limit on the number of times you can compile a script per hour or something. While I guess it's perfectly acceptable in a situation where you would simply upload modified versions of your scripts from time to time, you definitely can't debug anything with that. (Not that you'd want to -- see compilation time.) I need to do the debugging on THAT particular platform though, and believe me I'm enraged that they're not providing me with a way to bypass their limitation WHILE I'm implementing support for THEIR product... -_- Overall, it seems like they can 'take' a dozen compiles at most, and then... Poof. I haven't been able to compress anything this morning, for instance.
- I implemented a fallback -- if Google fails, then Wedge will just re-do the job with good ol' Packer, and skip Closure for all subsequent minification calls in the same page load.
- It's more efficient than Packer, saving a lot more bytes in uncompressed form, but once gzipped, it's pretty similar. On average, I'd say that a Closure version is about 100 bytes shorter for each gzipped file. I'm thrilled with the extra bytes, you know how I am, but I'm definitely not thrilled enough in a realistic configuration.
So, it'll be an option I think, but probably no more than a non-default, warning-filled option...
3768
Features / Re: New revs - Public comments
« on January 29th, 2013, 11:31 PM »Essentially this is about cases where users attempt to log in, fail, and we don't let them log in too many times.
The complexity of the testcase is the key thing here. If it's just about setting a session on validation then logging in, that's about as easy as it gets. Anything more than that really depends on how hardened it has to be against brute forcing.
I don't even get what she needs exactly. Apparently it's some complicated tech and they need to have a cookie in their browser that already contains the ID and password info, and transmit it to the remote server to get access without having to actually do the logging in... Except that AFAIK, it's not possible to locally create a cookie that's "visible" to a remote server without actually being on it first... (?) Maybe it could be done via the stuff we discussed the other day about a remote server for serving downloads... But I don't even know if that's what her team wants.
I'm telling you, it's complicated...
Probably. Or more likely I'll find it, think WTF, remember that we discussed it, then swear at the search facility for a moment until I find this conversation.
Or do you want me to copy-paste it directly from my noisen code? No problem really... I just tend to forget it ;)
Display.php, lines 86-92...?
Only problem, once I committed... I forgot to remove said partial commit from the file :P
So it has a paragraph now, that should be gone... And I think I'll also remove it locally. I wanted to add an e-mail icon in the mini-menu, but it isn't worth the effort -- it can be found in the profile area, and for guests the mini-menu doesn't show up anyway and it's replaced by said e-mail icon... Anyway! I removed the paragraph locally, it'll be in my next commit.
robots.txt isn't an Apache tech, no. But not all prefetchers respect it, which brings me back to things in the headers (i.e. like FF used to do, hence the test for the X-Moz header) which can't be sifted out in robots.txt, but can in htaccess - if you're using Apache.
At worst, we should actually do that test right at the beginning, e.g. in index.php, instead of while in the action array.
3769
Features / Re: New revs
« on January 29th, 2013, 11:19 PM »
rev 1881 -- because I can :P
(7 files, 8kb)
* Moved all response_prefix cache getter/setter code to the Subs file, just like preventPrefetch(). This also fixes a minor issue where cache_get_data didn't indicate a TTL. Hopefully we'll remove all of this at some point and replace it with a better hack. Like, the robots.txt stuff maybe...? Dunno. (Display.php, JSModify.php, Merge.php, MoveTopic.php, PersonalMessage.php, Post.php, Subs.php)
* Renamed all $scripturl to <URL> in PersonalMessage.php. Left one in -- wasn't too sure whether it'd be properly converted, and I'm too tired to look into it. (PersonalMessage.php)
+ Added a, hopefully temporary, hidden $settings['allow_prefetching'] that should allow you to easily, errr... Do what its name says. Site-wide. If you like breaking your own sites... (Subs.php)
! Forgot to commit one of the preventPrefetch() calls... You were right, Pete. (Display.php)
(7 files, 8kb)
* Moved all response_prefix cache getter/setter code to the Subs file, just like preventPrefetch(). This also fixes a minor issue where cache_get_data didn't indicate a TTL. Hopefully we'll remove all of this at some point and replace it with a better hack. Like, the robots.txt stuff maybe...? Dunno. (Display.php, JSModify.php, Merge.php, MoveTopic.php, PersonalMessage.php, Post.php, Subs.php)
* Renamed all $scripturl to <URL> in PersonalMessage.php. Left one in -- wasn't too sure whether it'd be properly converted, and I'm too tired to look into it. (PersonalMessage.php)
+ Added a, hopefully temporary, hidden $settings['allow_prefetching'] that should allow you to easily, errr... Do what its name says. Site-wide. If you like breaking your own sites... (Subs.php)
! Forgot to commit one of the preventPrefetch() calls... You were right, Pete. (Display.php)
3770
Features / Re: New revs - Public comments
« on January 29th, 2013, 06:08 PM »Don't worry, it took me a few goes to make sense of it.
Guess what is the latest thing my girlfriend asked me..? She wants me to build her a small testcase where I'll supply a form for her to log into a site, and generate a session cookie. I'm okay with the form, but... Oh my, I know the basics of cookies and session communication, but it suddenly seems like I can't do anything about this! Argh.
It always seemed to me to be clearer to indicate what you're doing and the one-liner, while efficient and compact, is not exactly conducive to its meaning. I'm cool with it, until I forget what it does and have to mentally shift to make sense of it ;)
I don't remember that in the anti-prefetch code. I thought it just caused things to die if it was trying to process a prefetch.
I'm not sure I follow how we get from messageindex to attachment :/ But I've only just got up.
But MI still has a preventPrefetch() call. And Display doesn't, to answer your question.
The thing about prefetchers is that most of the time it's done purely with headers which can't always be sifted out so easily. Remember, not everyone uses Apache and not everyone has htaccess files even if using Apache.
Also, robots.txt isn't an Apache tech, so it should work on every server. (Provided the file is uploaded at the root of the domain name, if available.......)
3771
Features / Re: New revs
« on January 29th, 2013, 05:58 PM »
rev 1880 -- anti-prefetching stuff.
(10 files, 3kb)
* Harmonized calls to ob_end_clean() to ensure they get rid of all output buffers. (Dlattach.php, Errors.php, Security.php)
* Moved all anti-prefetch code to a single function. Adding an ugly parameter to allow for Wedge to bypass the test and simply force a 403 error. (Load.php, MessageIndex.php, Search2.php, Security.php, Subs.php, Unread.php, UnreadReplies.php)
! Wess was doing a useless foreach() that never got used. (Subs-Cache.php)
(10 files, 3kb)
* Harmonized calls to ob_end_clean() to ensure they get rid of all output buffers. (Dlattach.php, Errors.php, Security.php)
* Moved all anti-prefetch code to a single function. Adding an ugly parameter to allow for Wedge to bypass the test and simply force a 403 error. (Load.php, MessageIndex.php, Search2.php, Security.php, Subs.php, Unread.php, UnreadReplies.php)
! Wess was doing a useless foreach() that never got used. (Subs-Cache.php)
3772
Archived fixes / Re: Input boxes not working in Chrome
« on January 29th, 2013, 04:52 PM »
Meh, that would require enabling them to reproduce the bug... And I'm pretty sure it's a bitch to reproduce. Unless I re-enable the bug here -- at the cost of my convenience!
3773
The Pub / Re: Remove flash dependency from AeMe?
« on January 29th, 2013, 04:51 PM »
The only reasons I kept JW Player thus far are (1) laziness (2) it's hard to say goodbye to the spectrum analyzer I implemented into it (for Foxy!)... Heck, it's the one and only time I ever dabbled into ActiveScript.
One of the reasons why I'm trying to stick to Chrome these days (which is made possible by the very nice Sidewise extension -- it's so sad that Chrome doesn't allow it to be part of the window...!), is that it supports the Web Audio API which is the only alternative to Flash for a spectrum analyzer. Thus, using Chrome would make me feel like I'm still with a universal S.A.... It's silly, I know! (Especially since AFAIK, Chrome requires a flag to be set for Web Audio to be supported...)
The plan was always to switch JW Player to use MediaElements.js, though! It still uses Flash, but only as a fallback, like the latest versions of JW Player.
As for mass uploading, I think that at this point, it's not safe yet to switch to a HTML5-only solution. Opera, Chrome and Firefox all support it indeed, but IE is way too late for the party. And this is a situation where I'm not sure I want to provide a Flash fallback... It's pretty much all or nothing.
Anyway -- Aeva stuff is what I'm playing with these days, due to my recent bug fixing. But I keep reverting my changes because, well, I don't know where to go exactly... Flash being one of the 'I'm scared!' ones. But it'll come soon.
It's interesting that this topic was created today because I started doing spectrum analyzer tests last night... :P (And it resulted in a nice little crash.)
One of the reasons why I'm trying to stick to Chrome these days (which is made possible by the very nice Sidewise extension -- it's so sad that Chrome doesn't allow it to be part of the window...!), is that it supports the Web Audio API which is the only alternative to Flash for a spectrum analyzer. Thus, using Chrome would make me feel like I'm still with a universal S.A.... It's silly, I know! (Especially since AFAIK, Chrome requires a flag to be set for Web Audio to be supported...)
The plan was always to switch JW Player to use MediaElements.js, though! It still uses Flash, but only as a fallback, like the latest versions of JW Player.
As for mass uploading, I think that at this point, it's not safe yet to switch to a HTML5-only solution. Opera, Chrome and Firefox all support it indeed, but IE is way too late for the party. And this is a situation where I'm not sure I want to provide a Flash fallback... It's pretty much all or nothing.
Anyway -- Aeva stuff is what I'm playing with these days, due to my recent bug fixing. But I keep reverting my changes because, well, I don't know where to go exactly... Flash being one of the 'I'm scared!' ones. But it'll come soon.
It's interesting that this topic was created today because I started doing spectrum analyzer tests last night... :P (And it resulted in a nice little crash.)
3774
Archived fixes / Re: Input boxes not working in Chrome
« on January 29th, 2013, 02:24 PM »
6 weeks being the delay before a new version is out? ;)
3775
Archived fixes / Re: Input boxes not working in Chrome
« on January 29th, 2013, 10:50 AM »
What should we do next for this?
I committed the fix yesterday, but I don't know if it's worth keeping it in forever.
1/ Chrome might fix the bug at some point... (I don't want to have Wedge keep fixes forever, just look at the state of the SMF codebase, full of IE4 fixes and all! Especially their JS scripts!)
2/ It doesn't happen all the time, and if I can't reproduce consistently, I can hardly quickly know when this is fixed... :(
I committed the fix yesterday, but I don't know if it's worth keeping it in forever.
1/ Chrome might fix the bug at some point... (I don't want to have Wedge keep fixes forever, just look at the state of the SMF codebase, full of IE4 fixes and all! Especially their JS scripts!)
2/ It doesn't happen all the time, and if I can't reproduce consistently, I can hardly quickly know when this is fixed... :(
3776
Features / Re: New revs - Public comments
« on January 29th, 2013, 10:42 AM »
So, I'm looking at the latest commit, plenty of good stuff, and a couple of things that required my attention:
- error.lock (cool thing BTW) is never created. Why doesn't it go through the same logic as the other lock file..? :geek:
- It's amusing that I never understood the logic in that Subs-Login block, and with your rewrite it's even fuzzier in my mind... :lol:
- The ob_end_clean() function is often called in SMF/Wedge, but never the same way. Sometimes it's just it, other times it's done with a while() on ob_get_level(), and finally my method: a single-line while (@ob_end_clean()); that will delete all buffers and stop at the last (because when none are left, PHP returns false.)
I modified all of the calls that seemed to require deleting all buffers, to do that single-line while() instead. Hopefully everything'll be okay.
- ob_end_clean() is called multiple times in the anti-prefetch code. I'm bothered with that one. First of all, having the same code repeated all over Wedge is a bit ugly, so I moved it to Subs.php in a preventPrefetch() function.
I need opinions on two things here:
- I added a $always parameter to it specifically for the call in MessageIndex, because it also sends a 403 when trying to load a board while the action is attempting to load an attachment. So this becomes basically preventPrefetch($and_also_if_loading_attachment), where $always will bypass the prefetcher test. That seems ugly to me... Isn't it?
- If MessageIndex prevents loading topics to ensure they're not 'read', why not do the same on topic pages..? Prefetching the next page means that if you're on a topic with 10 unread pages, next time you click on the topic from the MessageIndex list, you'll have skipped an entire page because it was marked as read... Instead of preventing prefetching, we could also just check whether the prefetcher is loading the current page, and if yes, skip updating the topic read/page read tables... But that means when we get to reading the actual page, it's loaded from the cache, and thus the tables aren't updated either. It would make more sense if prefetchers also sent an asynchronous extra request to that page to tell it that it's actually been read... But it's unrealistic to expect them to do it.
- At this point, do we want prefetchers at all on Wedge?! If not, then... robots.txt... Disallow Fasterfox. There may be other prefetchers to prevent, too. Or just add a rule to the htaccess file, I dunno.
Woohoo, Opera has just changed my textarea's font to a serif font... WHILE TYPING.?
Good job! And then it crashed on me. At least that serif problem was a good warning. Then I launched Chrome, and it crashed on me before I had time to send this.
It's interesting that back in my Windows XP + 2GB RAM days, I was able to run Opera with up to 900 tabs, albeit very slowly...
Now with Windows 7 + 8GB RAM, I've never been able to get above 200 tabs in Opera without it making my life hell, and Chrome is actually behaving better but after 400 tabs it's also much harder to work with...
Anyway!
- error.lock (cool thing BTW) is never created. Why doesn't it go through the same logic as the other lock file..? :geek:
- It's amusing that I never understood the logic in that Subs-Login block, and with your rewrite it's even fuzzier in my mind... :lol:
- The ob_end_clean() function is often called in SMF/Wedge, but never the same way. Sometimes it's just it, other times it's done with a while() on ob_get_level(), and finally my method: a single-line while (@ob_end_clean()); that will delete all buffers and stop at the last (because when none are left, PHP returns false.)
I modified all of the calls that seemed to require deleting all buffers, to do that single-line while() instead. Hopefully everything'll be okay.
- ob_end_clean() is called multiple times in the anti-prefetch code. I'm bothered with that one. First of all, having the same code repeated all over Wedge is a bit ugly, so I moved it to Subs.php in a preventPrefetch() function.
I need opinions on two things here:
- I added a $always parameter to it specifically for the call in MessageIndex, because it also sends a 403 when trying to load a board while the action is attempting to load an attachment. So this becomes basically preventPrefetch($and_also_if_loading_attachment), where $always will bypass the prefetcher test. That seems ugly to me... Isn't it?
- If MessageIndex prevents loading topics to ensure they're not 'read', why not do the same on topic pages..? Prefetching the next page means that if you're on a topic with 10 unread pages, next time you click on the topic from the MessageIndex list, you'll have skipped an entire page because it was marked as read... Instead of preventing prefetching, we could also just check whether the prefetcher is loading the current page, and if yes, skip updating the topic read/page read tables... But that means when we get to reading the actual page, it's loaded from the cache, and thus the tables aren't updated either. It would make more sense if prefetchers also sent an asynchronous extra request to that page to tell it that it's actually been read... But it's unrealistic to expect them to do it.
- At this point, do we want prefetchers at all on Wedge?! If not, then... robots.txt... Disallow Fasterfox. There may be other prefetchers to prevent, too. Or just add a rule to the htaccess file, I dunno.
Woohoo, Opera has just changed my textarea's font to a serif font... WHILE TYPING.?
Good job! And then it crashed on me. At least that serif problem was a good warning. Then I launched Chrome, and it crashed on me before I had time to send this.
It's interesting that back in my Windows XP + 2GB RAM days, I was able to run Opera with up to 900 tabs, albeit very slowly...
Now with Windows 7 + 8GB RAM, I've never been able to get above 200 tabs in Opera without it making my life hell, and Chrome is actually behaving better but after 400 tabs it's also much harder to work with...
Anyway!
3777
Archived fixes / Re: Plugin execution
« on January 28th, 2013, 10:48 PM »I'm not entirely sure when it was added in SMF - in some fashion or another anyway.
I don't mind leaving it there in the post, though it also wouldn't exactly gnaw at my soul if it were removed either.
Keeping them visually is relatively important for me. Not storing them makes a lot of sense though.
I thought Noisen didn't store them, but it does, I just checked. It only decides to hide them if the title is "Re: Name of Current Topic". If the title is different, or doesn't start with "Re:", it shows it at the top of the post body (which makes sense.)
That wasn't quite what I had in mind. Most places where we're getting stuff like that, we're getting topic data, and frequently joining to the first message anyway, so it's not a difficult matter for us to determine in those places whether or not it's the last message in a topic.
I'm thinking we could have an icon to indicate reply vs new topic. Or even if we wanted to be fussy, use whatever $txt['response_prefix'] in the *current* language is. None of this farting about collecting whatever language response prefix or shoving it in to the subject data, just store it without, and display it with it.
Just a thought. It seems like an awful lot of effort for 4 characters.
Suggestion: replace all Re: internally with <r> or something else that's unlikely to be used in a HTML page. Then do a global replace from <r> to the response prefix.. Only drawback I can think of: it brings problems if we're showing the title without going through ob_sessrewrite. I think that PM notifications might be a concern here...? Or do they go through the output buffer?
Ah, early time for bed for me tonight... See you!
3778
Archived fixes / Re: Plugin execution
« on January 28th, 2013, 09:40 PM »Because, like SMF, it is supposed to be a hidden setting.Quote Also... Why don't we have a UI for $settings['disable_language_fallback']...?
Maybe it was done during my tenure at SMF, though... That might explain why I thought it was Wedge-only.
Anyway!
Do we really actually need the Re: part everywhere?
The main drawback is that when you're on mobile (or even on Chrome Desktop!), there's no other way to know the topic title than going to the beginning of the page. Only Firefox Mobile shows the title in the URL bar, but I'm not a big fan of that either (especially since Wedge shows the topic title in the URL in the first place...)
So that's something I was always a bit upset with.
It would also allow us to safely rewrite queries to use the first post's subject rather than the last post's and then replies could all leave the subject empty - saving space.
It's not like we can't rejig the template to use 'Reply #x' as the link to the post either.
3779
Archived fixes / Re: Plugin execution
« on January 28th, 2013, 07:23 PM »
Looks like it never happens on my local install... I always get the rev number. :-/
Also, the index language is only ever loaded twice at the most (if French is selected), unlike here. Could this be another plugin problem...? Or... Configuration? Hmm...
I guess I'll have to do my tests here.
Also... Why don't we have a UI for $settings['disable_language_fallback']...? I went looking for it in Languages > Settings, to no avail... :(
Woohoo!
Here it is!
Code: [Select]
That's the code that gets 'index' to be loaded another time.
It's really strange, because the code seems to indicate that it won't be called more than once every 600 seconds...?!
At this point, I don't know if loadTheme() is actually called twice somewhere (outside of this...), because I couldn't reproduce that behavior. But by putting my backtrace inside loadLanguage(), this is what I got.
And, fixed!
Instead of reloading the index language a last time, I just saved $txt before that, and restored $txt immediately after... It should also be much faster, eh!
Also, the index language is only ever loaded twice at the most (if French is selected), unlike here. Could this be another plugin problem...? Or... Configuration? Hmm...
I guess I'll have to do my tests here.
Posted: January 28th, 2013, 07:06 PM
Also... Why don't we have a UI for $settings['disable_language_fallback']...? I went looking for it in Languages > Settings, to no avail... :(
Posted: January 28th, 2013, 07:07 PM
Woohoo!
Here it is!
// For quick reply we need a response prefix in the default forum language.
if (!isset($context['response_prefix']) && !($context['response_prefix'] = cache_get_data('response_prefix', 600)))
{
if ($language === we::$user['language'])
$context['response_prefix'] = $txt['response_prefix'];
else
{
loadLanguage('index', $language, false);
$context['response_prefix'] = $txt['response_prefix'];
loadLanguage('index');
}
cache_put_data('response_prefix', $context['response_prefix'], 600);
}That's the code that gets 'index' to be loaded another time.
It's really strange, because the code seems to indicate that it won't be called more than once every 600 seconds...?!
At this point, I don't know if loadTheme() is actually called twice somewhere (outside of this...), because I couldn't reproduce that behavior. But by putting my backtrace inside loadLanguage(), this is what I got.
Posted: January 28th, 2013, 07:18 PM
And, fixed!
Instead of reloading the index language a last time, I just saved $txt before that, and restored $txt immediately after... It should also be much faster, eh!
3780
Archived fixes / Re: Plugin execution
« on January 28th, 2013, 07:01 PM »O RLY
OK, so yeah, I suggested there might be issues with language juggling ;)
I know we fixed it to load English first all the time, but I don't know why it's loading them twice.
I've even got this halfway through my to-do list (line 612!):
*** loadTheme() is called twice'***' meaning a high priority item...
What I'd be inclined to do is try and dump the backtrace upon hitting loadLanguage where it's called to load 'index' to see why it's loading them twice.
I'll try to see if it happens locally, first.
* Arantor is still fighting with security issues right now.