Sometime in the last week or so, Flash stopped working me on many sites. It seemed to stop working around the time of the last Microsoft Vista updates, but I can't be sure. The strange thing is, it worked on some sites (like Adobe) but wasn't working on a lot of the sites I was visiting. I tried reinstalling Flash, but that didn't fix it. Since it wasn't a high priority for me, I haven't had time to look into it until today.
Today I was doing some QA on our site and noticed one of the Flash components was no longer working. Since Flash seemed to break for me around the time of the last Windows Update, I thought I should probably look into things to see if this is a wide spread issue.
I quickly fired up a couple of different versions of Firefox (and on different PCs) and they were all working fine. This seemed to indicate the problem might be local to my installation.
Next, I decided to actually examine the source code in Firebug—which is when I noticed something odd. The <object /> tag was grayed out like it was hidden or being ignored. So, I fired up the same page in another Firefox install and the <object /> tag was being shown as expected.
NOTE:At this point I also checked some of the sites I remembered where Flash was working and sure enough they were using the <embed > tag instead of the <object /> tag.
Since I thought this was extremely odd, I decided to fire up a brand new Profile to see if things would work in an empty Profile. Dropping to a command prompt, I used firefox -P to create a brand new profile called "test". Next I used firefox -P test -no-remote to open up the new profile (the -no-remote argument allows you to open a separate instance of Firefox using a different profile.)
When using the new Profile, Flash was worked as I expected. This told me something was wrong with my normal Profile, but what?
In order to track things down, I first tried disabling add-ons that looked like primary suspects (Firebug, Web Developer, AdBlock Plus, etc.) Nothing changed. I next tried uninstalling these add-ons. Flash still not working. I finally just uninstalled all the add-ons. And what do you know? Flash started working again.
In order to try to determine which add-on was causing my Flash problems, I tried installing each add-on individually. Unfortunately (at least from a troubleshooting standpoint) after re-installing all the add-ons Flash is still working correctly.
So I obviously had a problem with my profile that was caused by one of the add-ons I had installed. Unfortunately, I do not know which add-on was the culprit. I do know that after removing all my add-ons and reinstalling them Flash is now working properly again.
UPDATE:Here are a list of the add-ons I had installed, all of which have been reinstalled:
Adblock Plus 1.1.1
Clear Cache Button 0.9b
ColorZilla 2.0.2
Download Statusbar 0.9.6.5
Firebug 1.4.3
Firesizer 0.92
Free Download Manager 1.3.4
Html Validator 0.8.5.8
IE View 1.4.4
Microsoft .NET Framework Assistant 1.1
Organize Status Bar 0.6.3
Page Speed 1.3
Print Context Menu 1.2
QuickFrame 0.5.1
QuickProxy 2009.07.19
Web Developer 1.1.8
XMarks 3.3.2 (NOTE: I didn't actually uninstall this add-on, it was the one exception of an add-on that I did not uninstall.)
Occasionally I've run into a situation where I've wanted to add some whitespace between two options in a <select /> element. The most common solution I've seen people use is to include an empty <option></option> tag pair. While this works, it adds a blank entry that the user can actually select—which means you have to add some code to handle the selection of what is designed to just be used for whitespace.
A better solution is to use an empty <optgroup /> that is disabled:
<select> <option>Value 1</option> <!---// add a non-selectable space between options, the margin-top is for FF spacing //---> <optgroup disabled="disabled" style="margin-top: 1em;"></optgroup> <option>Value 2</option> </select>
This will add a non-selectable blank line between "Value 1" and "Value 2". Here's an example:
I use this technique often before normal <optgroup /> tags as it helps make the menu look a little cleaner by adding some separation between the options and works with all modern browsers. Best of all, you don't have to worry about handling those empty <option /> tags!
While working on some code today, I faced a problem I've run into a few times in the past where I needed to find the first usable input element within a specific context. What I mean by "usable" is an element which is visible to the user and not disabled.
Finding the first usable input element can be handy when you're using tabbed form, as when the user changes tabs, you can place the focus in the first visible input element. In my use case, I was implement a "reset" on a form where the fields being displayed could vary. I wanted to automatically place the focus in the first visible field after the user triggered a "reset" of the form.
If you're using jQuery v1.3 (or higher) this custom selector is very simple, just add the following to your page:
// finds elements that are usable (i.e. visible on the screen and are not disabled) $.expr[":"].usable = function (node, index, prop, nodes){ var $n = $(node); // return if the element is viewable or not return ($n.attr("disabled") !== true) && $n.is(":visible"); };
If you're using jQuery v1.2 (or lower) the code is slightly more complex because the ":visible" selector doesn't check with the parent elements to make sure they are all visible. So, in order to make our code work with jQuery v1.2 we'll need to first create a custom selector for which will find elements that are truly visible:
// finds elements that are viewable $.expr[":"].viewable = function (node, index, prop, nodes){ var r = false; function viewable(n){ var $n = $(n); return (($n.css("display") !== "none") && ($n.css("visibility") !== "hidden")); } // if not usable, stop processing if( !viewable(node) ) return false; $(node).parents().each(function (){ r = viewable(this); // if not viewable, stop processing chain return r; }); // return if the element is usable or not return r; };
The new ":viewable" selector should pretty much behave the same way that the ":visible" selector does in jQuery v1.3.
The only difference in this version of the ":usable" selector is that we're going to use our custom ":viewable" selector instead of the ":visible" selector:
// finds elements that are usable (i.e. visible on the screen and are not disabled) $.expr[":"].usable = function (node, index, prop, nodes){ var $n = $(node); // return if the element is viewable or not return ($n.attr("disabled") !== true) && $n.is(":viewable"); };
The ":usable" selector can be used in several ways:
// find all usable form elements $(":input:usable") // find the first usable form element $(":input:usable:first")
While the most common usage of the selector will probably be :input:usable:first, I can see where occasionally you might want to get all the input elements visible to the user.
Hope this helps someone!
Today I submitted the ColdFusion Enhancement Request #80336 to add better tools for preventing XSS attacks. More and more it's becoming common for developers to need to implement some type of WYSIWYG editor, but with that comes the increased risk of XSS attacks.
We've all heard about attacks on MySpace and other major sites and this is because it's actually a pretty difficult problem to solve correctly (since there are so many attack vectors.)
My suggestion would be for Adobe to integrate the OWASP AntiSamy project into ColdFusion. This is an excellent tool for cleaning up input to prevent XSS attacks and is highly configurable via XML.
If you're interested in solving this problem now, see my Using AntiSamy to protect your CFM pages from XSS hacks blog entry for details on implementing AntiSamy right now.