That’s the problem with bug reports in general. Something’s missing — because what you’ll hear back from the developers of FireFox is that it’s not a bug, it’s a feature, and it works by deisgn.
More importantly, …they’re right.
Allow me to walk you through the problem: you’re editing using GMail, WordPress, or LiveJournal — when you go to select some text by doing a Shift-Click and drag, your mouse stutters or perhaps by accidental muscle memory habit you end up accidently Shift-Double-Clicking. To your surprise all the text in the input box becomes invisible.
The content is still there, hust invisible. You can move the cursor around. If you submit, it gets sent. What gives?
It’s not an accidental one-time software glitch, it’s repeatable. It doesn’t matter if you’re selecting text, or shift double clicking in one spot: it happens consistently.
So, before filing a bug report, you try it on different browsers.
IE, no problem. Opera, no problem. Safari, no problem.
And there’s a surprising confirmation that FireFox behaves this way both on XP and OS X, so we’re pretty sure it’s a FireFox issue at this point. We try it on the latest build right out of the development tree, and it happens there, too.
Time to report a bug.
If you follow the directions, and many people don’t, you learn that this bug has already been submitted to the FireFox development team many times.
XP – BUG 307612 and BUG 307613,  OS X – BUG 317687.
I personally don’t think people who take the time to research and submit a bug are stupid or lazy, stopping just short of duplicate checking. I think that the keywords used to search for duplciates aren’t expansive enough to do the job well. I search for “Disappear” and get a hit, someone else searches for “Invisible” and gets a miss (so they report a bug).
Another problem, assuming you read all the bug reports to the end: The developers closed it.
The last thing that you want to see on a bug you just verified are the words RESOLVED and/or INVALID, because you know it’s going take some arm twisting to convince the development team otherwise.
One of the fundamental problems being on a development team is that you do get an awful lot of things that aren’t bugs reported as bugs. There’s tons of duplication, and worse, tons of ambiguity. Despite writing detailed directions explaining what information is needed and in what format, most bug reporters don’t do that. It becomes too easy to throw the baby out with the bathwater.
I almost wish there were was a flag attached to one’s bug reporting account that said “I’m either a professional software developer or I have worked in a QA division” that would weight the submissions higher in the developer’s mind. It’s the same problem as when you’re the company IT expert and you call Dell for a support issue and their level one technician wants you to reboot and reinstall the operating system.
The problem is also reversed. And this is a problem that needs fixing: developer responses can also be ambiguous. We’ve all seen cases where a bug is marked as “not a bug” or “works as designed” with no explaination.
But not in this case, luckily. One of the developers has the insight to point out that this is an AdBlock feature, and it’s by design. By design?
This explains a lot, everything to why it only appears to happen to FireFox — since that’s the browser that uses the AdBlock extension. It explains why the FireFox team is wasting time chasing after these, it’s not their problem. It explains why their responses are terse, as, again, it isn’t their problem. Disabling AdBlock itself, not just it’s filters, but the whole extension, solves the problem. Problem is, I like AdBlock. I need AdBlock. I want AdBlock.
Now sometime software works as it was designed to work, but fundamentally the design is wrong.
Joel Spolsky describes it like this: A user interface is well-designed when the program behaves exactly how the user thought it would.
And there is nothing about a text area waiting for input that makes me expect that Shift-Double-Clicking while trying to select text should permanently turn the entire contents of the text box invisible while editing.
That’s about as annoying as the folks who put the “Quit Application With No Save or Confirmation” menu item right next to the “Save” menu item, where a mere slip of the mouse spells disaster.
Further investigation of AdBlock’s development area, shows there’s a nifty feature called Quickblock, which allows you to Shift-Double-Click an element on the screen and make it turn invisible. It’s a great way to zap ads or annoying content!
Problem is, the trigger mechanism is very close to an action commonly used by editing. And, Adblock doesn’t make a distinction whether it’s an input control or not — and why should it, as if it did, advertisers would put ads in controls.
This doesn’t solve our problem as a user, though. It’s a good feature with bad interface design. Luckily, one that can be easily solved.
Either the shift-double-click needs to be changed to something else, or we need the ability to turn it off or lessen it’s sensitivity.
In the thread, “Quickblock makes me sad“, we see that other users are plagued by this problem, and some users have started building their own versions with this feature disabled.
Clever, but this is not something the source code should have to fork over. Nor, is it something the layperson should be expected to have to do just to be able to safely edit text.
Quickblock should remain a feature, but it should be possible to disable it, disable it for a list of specified sites, or have a mode where it’s possible to have it not affect editing controls. In fact, I’d be quite happy if when I Shift-Double-Clicked on an edit control if it then asked me for confirmation, but not on other elements.
I’ve proposed the change as a new minor feature, assuming I haven’t missed how to do it already (which is possible). But I have my doubts anything will happen.
Why? I’m a developer. And my natural knee-jerk reaction to an end-user is “if you are doing something that causes a behavior you don’t like then don’t do it anymore.” Problem is, developers don’t use systems the way end users do, and that makes them predisposed to not share the user’s perspective. Afterall, programmers don’t spend their days on the web writing in little edit boxes, and if there’s a problem with one, there are a dozen work arounds, including opening an editor, composing, and pasting. We think other users work like we do and know how to use other tools like we do.
But that’s not how users think or work.
My hope is that if you are also having this problem, you’ll find this article before you bug the guys at FireFox with it, and instead go here and add your voice, in a kind way, so that the great developers of AdBlock know how to improve the product further and to show that you support their tireless efforts.