Wedge

rev 2185 -- outing!
(3 files, 2kb)

! A faulty equation sign change broke the flood management code in late January, and thus people would be forever locked out of Wedge after failing to log in 5 times. How awkward. Thanks to Farjo for being the one to tell me first, and to myself for reproducing, and finally fixing some code I only touched once, long ago. I hate that. (Subs-Login.php)

! Fixed a couple of minor DOM logic issues with the infinite scroll code, although I have yet to determine whether I'm keeping it this way, or rewriting it from scratch, or not caring at all. (topic.js)

* Spacinazi. Long time uh..? (Login2.php)

What about the last bit of code? Which one is right, smf's or ours?

As mentioned in the thoughts (private ones[1]), someone has been having trouble logging into the forum.
I looked into it, reset their password, and it still didn't work... They got a brute force warning.

Now, here's the thing. I remembered that Pete had committed some SMF fixes for Wedge, regarding brute force issues, and I'm thinking, that's where the problem lies -- in this fix.
So, is it an SMF bug, or a Wedge bug..?

The SMF 2.1 rewrite:


The Wedge rewrite:


From what I understand: first one means, "if recorded flood timestamp is older than 20 seconds ago, reset it to 2, otherwise don't touch it.
Second one means the exact opposite... Meaning, once the flood record is older than 20 seconds, the user is forever locked out of the forum.
It took me an hour to finally find the culprit, and I'd like to know what exactly went into this rewrite..?

Also, the Elk version is cleaner, and much shorter...


Finally, a note about the code that tests the timestamp and resets it if it's too recent.. (?)

In SMF 2.1:


(Means "if time stamp is older than 10 seconds...")

in Wedge:


(Means "if time stamp is more recent than 10 seconds ago...")

I'm inclined to believe the Wedge version is the correct one here, but honestly, I have no fucking idea. I'm just not comfortable enough with the whole validatePasswordFlood function, to be clear. I understand what it does, but not the magic of it.
So, err... Need your opinion, guys..?

Hopefully Pete sees this topic through the magic of 3G, or something... :^^;:

Additional note...

Looks like I can login with my hardcoded flood value, but it doesn't get reset to nothing, so I'm still with the same flood value after that... (?!)

1.	I thought that using a public topic for this was okay, because I'm not going into specifics with the source code, and it's close enough to the SMF version anyway, which is freely available on github, so...

Your non-wifi connection seems decent enough, with Louis posting daily video updates on the road.. ;)
(I must say, it's interesting that I was finally able to see you 'live' after 3 years working together and only knowing you from a single picture, and yet you're 20 times further away from me than you usually are... :^^;:)Okay, my setup is (still) as such (I feel I need to make it clear that I can't test everywhere):
- Windows 7, main dev browser has been Chrome Canary for 6+ months, usual test browsers are Opera 15, IE10, and sometimes Firefox Aurora. These days, also Opera 12.16 (cf. comments in the thoughts.)
- S3 smartphone with Android 4.1.2, rooted, using the regular Chrome, with Firefox Beta as my occasional test browser, and very rarely, the stock browser (which I think sucks.)
- iPod 4 with iOS 5.1.x (probably just 5.1), rooted, using the regular Chrome. The only reason I've re-charged it these days, is to play Ron Gilbert's Scurvy Scallywags (very nice game, albeit a bit hard, so reliant on (bad) luck that it can get troublesome...), and Safari used to crash on me, but apparently, these days it doesn't, so I just tried on it...

It looks like the current Safari + iPod version gives me a different result... Instead of having the fixed button on the top right, it shows it on the top left (?!), and only a very small portion of the button, uh... Yeah, sure, great devs at Apple...Hmm, I think it should have shown it...
You definitely should try remote debugging Wedge from your Mac. You have a Mac, I believe..? Since I don't, and don't plan to ever buy one, I can't debug their stupid Safari, and thus, can't see which media queries are triggered, etc...

The media queries are as such, IIRC ($response = max-width: 1000px):
- "$responsive" hides the sidebar, and shows the sidebar button in the top_bar, where it sits next to the Upshrink icon and Search form.
- "$responsive and min-resolution: 1.5dppx" additionally makes the sidebar button a fixed button, and moves it to the top right corner.
And, that's all there is to it...
The first query should run everywhere (including iPads), if the windows is shrunk. The second query specifically targets smartphones, by ensuring we're both in a low res, AND we have a Retina screen or better. Of course, I could simply test against the OS, or the 'mobile' variable, or both, as it would thus take bad screens into account... But, well. I'm not sure about this.
Normally, an iPad 2 shouldn't trigger the second query, but an iPad 3 and iPhone/iPod 4+ should. As I said, my iPod 4 doesn't show the button entirely, but that's probably down to a change I made yesterday, which I'm bound to cancel at some point, i.e. I changed the button width to use vw units (percentile of viewport width), which is great, but messes up the button in desktop mode, ah ah... (I even had to add an @if mobile test, to ensure it wouldn't screw up.)It shouldn't... So, Apple is giving you the complete opposite of what normal browsers would give you. Try Chrome for iPad, will you..? I'm sure it'll magically start working, then...Hmm yes.Then, it's another Safari bug.
iOS didn't support position: fixed at all, years ago, but now it's supposed to... In fact, it does support it on my iPod+Safari, if you don't take the button size into account.It shouldn't happen.Is iOS 7 out, already..? I'm sure they'll do something for Safari, won't they..?It should work much better than before really; reason being, the new implementation is a different philosophy. Instead of doing plenty of changes, it simply hides the sidebar, and then it relies on JavaScript to show the sidebar again, and do the nice animation, when clicking the sidebar button... :-/
So, I'm definitely not going to give up on this, but I'm guessing I'll have to rely on someone with a Mac to do the debugging for me, because I'm not buying a friggin' Apple computer just for the sake of ensuring they didn't screw up with my code, eh...

Yes, I fixed some additional issues with the sidebar. Opera < 15 still doesn't do great, mostly because it has the same problem as Firefox (middle-click -> can't cancel the default behavior for it, but it'll still toggle the sidebar.)
I don't really care about Opera < 15 to be honest, because it's outdated now, and eventually Presto will be used by a tiny, tiny fraction of web users. Opera Blink is still very far from Opera Presto's coolness, and it'll be a long time before I use it by default on my computer, but at least it works when it comes to the sidebar, so... No need to bother too much, just like I decided not to bother with IE6/7 and not give them a responsive sidebar. (Makes things much easier, ah ah...)

As for the extra click -- it's irrelevant. Most implementations of a toggable sidebar do the same, i.e. if you click OUTSIDE of the sidebar, the software assumes you want to get away from it, and thus it hides it. Showing it again, is just a click away.
If you click INSIDE the sidebar, of course it's not going to go away. Actually, I even added some code to ensure that clicking outside the sidebar, but inside a scrollbar, will not close it either.

(Edited.)

rev 2183 -- responsive sidebar, reloaded!
(5 files, 5kb)

! Here's hoping I fixed all of the responsive sidebar issues for good... I ended up doing many steps back, and settling on a table layout even in responsive mode. You'll see-- it works fine. (script.js, sections.css)

+ When opening the sidebar in responsive mode, Wedge will attempt to position its content in the most convenient way for you. It's a kind of magic. (script.js)

+ Added left-to-right scrolling for responsive sidebar, when the sidebar is originally shown on the left. Hard-scroll is disabled in these cases, but it shouldn't be much of an issue. (script.js)

@ All of the feature changes above add 500 bytes of JS, but save about 200 bytes of CSS, so it's a fair compromise.

* Increased sidebar width by 20px, because I can. (common.css)

* A few tweaks to Weaving paddings, I'll apply them to other skins later. (index.css)

! Moved Warm's top_bar to its regular place, in an empty version. This should help force the menu button to be visible in Warm, which was not really a given in the first place. (Warm/skeleton.xml)

Or you can just revert the responsive sidebar to the dull one, if you're so insistent that you don't like my new ones...
(Even then, the menu being moved to the sidebar is due to a usability concern of mine -- menus are close to unusable in mobile devices, while the new one IS, and I'm happy with that. Of course we'll need to move the Admin and PM numbers outside of it at some point, but it's not a priority for me. I'm still fighting to get the sidebar to behave everywhere...)

Rest of the post = TL;DR for now.

Re: footnotes, I thought they already behave like that for any block type or something..?