I’ve refined the KFM file browser. The submit button of any form is not needed until the form is valid, so I set the Upload button for teh file-upload form to display:none. The button is displayed once the file selection input actually contains something.
That helps with the amount of space used by the file browser.
Also, instead of showing alerts for errors and announcements, I’ve introduced a small logger. Errors are shown with high contrast colours, and normal messages are muted slightly (they don’t need to be too visible – they’re just log messages).
I had a bit of fun today. I finished off the list of outstanding bugs in KFM’s bug-tracker, and added the ability to move files around the directories by dragging them.
To select multiple files, you click one file, then click others with the CTRL key pressed down.
demo (click the Image icon on the second row, then click Browse Server)
Once I had the drag’n’drop coded, I realised that there was no real indication to the user of what had just happened (files just vanished, with no real explanation of why), so I added a visible indication – what I call “boxdrop tracers”; when you do the drag and release, pseudo icons appear where the selected files where, and move to the drop location (the directory you’re dropping the files into), helping the user to visualise that files have “moved” into the directories, instead of just vanishing.
If I click on an element, triggering an onclick event, which sets off a setTimeout which calls a function, is there a way for that function to know that I have the CTRL key pressed down? After all, the way everyone seems to do it is to check e.ctrlKey, where e is the event which triggered the function call – but in this case, the function is called by a setTimeout, not a trigger. Any way to check?
Another question which can possibly be answered: When a mouse is in “drag” mode (ie; the mouse button is clicked while the mouse is moving), no onmouseover or onmouseout events seem to be triggered on any elements – is this a bug in Firefox?
You’ve all seen those scams where an email claims that your ebay or paypal account is violated, and gives a link directly to the login, which you can easily see is fake because a hover over the link shows an IP address in the status bar of your email client.
I just received an email which had me puzzled for a few minutes. It was obviously a phishing attempt, but a quick glance through the page didn’t show anything fake-looking. Hovering over the provided links showed a proper paypal address (https://www.paypal.com/cgi-bin/webscr?cmd=_login-run). Even right-click->copy on the links provided the right address in a browser. Puzzling.
Then I looked in the source, and found that the links were actually surrounding a submit input which was made to look like a plain link. Clicking that input would submit a form going to a nastier place.
The fact that a submit button can look so much like a link and not give any warning, is a security bug in my eyes. Here is the suspicious code:
<font size="2" face="Arial, Verdana">
<INPUT style="BORDER-RIGHT: 0pt;
BORDER-TOP: 0pt; FONT-SIZE: 10pt; BORDER-LEFT: 0pt; CURSOR:
blue; BORDER-BOTTOM: 0pt; BACKGROUND-COLOR: transparent;
TEXT-DECORATION: underline" type=submit
value="click here and process your login." tabindex="1"></font></a>
What I think is vexing about this is that it took a look at the source to find this out. In my opinion, hovering over an input button should definitely not show a surrounding link’s url on the status-bar.
I’m submitting a bug to Thunderbird at the moment (although it’s probably more apt to submit to Firefox – it’ll all end up right, anyway) asking that a hover over a Submit input show the form target’s url in the status bar.
To give one of our clients a moderate amount of security, I was asked to add a watermark facility to an ajax shoppingcart. For full security, it makes sense to edit the actual image, but for less pressing security, I had to come up with something clientside.
The trick I built is based on a small hack which gives basic security for images – overlay the image with a transparent image:
The above is part of a HTML generation thing, which is then passed through a html2dom parser before being added to the document.
The code is basically told “draw an image img1, using image img2 as a watermark”. It must then work out all the widths and sizes itself.
You cannot simply leave out the width and height, as the image will end up being the size of the watermark, with only the top left of the actual image displaying. Therefore, we must work out what width and height to resize the image to.
To do that, we tell the browser to load the actual image, and set an “onload” on it to retroactively resize the watermarked version to the correct dimensions. You’ll note that I’ve told it to forget about the watermark in Safari’s case. That’s because Safari does not have an onload event for images.
A much simpler example of the above code (if I was allowed to tell IE to go screw itself 😉 ) would have been this:
It was interesting developing these – a major difference between Internet programming and desktop applications, is the extreme slowness of the Internet at times.
As an example, I’ll walk through an experience of loading up the Test directory in the demo (click the image icon, then Browse Server), while my computer is under a heavy network load (I have discovered the treasure of public domain films).
Initial file directory, with icons depending on the extension of the file:
The browser then requests the addresses of different icons for those files that might be images (again, based on the extension):
The browser finally finishes replacing the icons.
On a slow network, the major bottleneck was step 2 above. The reason for this was that when a browser is asked to replace the background image of an element, it does it immediately, whether that image is in its memory yet or not. Notice that there are two empty spaces there – those oare icons where the original default icon has been cleared, but the new replacements have not yet loaded.
So, the solution was to first load the image, then replace the element’s background.
Obviously in the above, el is the icon element, and image_data is some data retrieved from the server about the image.
Now, that’s all nice and dandy, and solves the huge “blank space” issue, but it still takes a little bit of time to load. What if you need to go back to that directory at some future time?
Obviously, a bit of caching is needed. If you need to view that directory again, load up the file list as normal, then see if there is a cached copy of that file’s data. In the kfm, I store this data in kfm_filesCache. For example, the line directly after the above block is this:
There is a subtle problem here, though, which can trip up even the most experienced web developers every now and then – what if the image changes? Obviously, if you change an image (rotate, etc), then you want the icon to also change. This can be tricky if you only refer to the image as “blah.png”.
Solution to this is to change the src of the image to “blah.png?5897451” (a random number) or similar, and cache /that/ address, then when the image changes, simply remove the cached copy (set it equal to null), then rebuild the data. The new icon will have a different random number, so will reload.
For example, the line directly preceding the block above is this one:
I’m on holiday at the moment, so I thought I’d put a bit of work into something which, though it will eventually be of use in my regular work, is actually just a personal obsession at the moment. To help keep track of it, I’ve installed a bug tracker. We use Mantis in work, and, while it’s a bit of overkill sometimes, it’s still very very useful. Apparently, it will be skinnable soon, which will help quite a bit with its usability.