Re: Bug detection (was: Re: @media and browsers conditional statments)

On Sat, Aug 9, 2008 at 3:46 PM, Brad Kemper <brkemper.comcast@gmail.com>wrote:

> The TinyMCE/Opera 9.5 compatibility problem is a textbook example of why
> browser sniffing should be avoided at all costs.
>
>
> To the contrary, the problem they describe is a textbook example of why
> browser sniffing is still useful. With just a couple of lines the author was
> able to add support for Opera, despite their small market-share, without
> having to spend a lot of time trying to track down why Opera behaved like
> that, or write complicated code trying to detect the root cause once they
> figured it out.
>

The fact that he knew *how* to work around Opera's behavior showed that he
knew enough to feature-detect.  It would have been just as easy to do a
quick detection of the problem and change behavior if necessary.  If he had
done so, there would have been no problem when Opera fixed their issue, and
if any other browser had a similar issue it would be fixed just as easily.
This required no knowledge of the root cause of the bug, just knowledge that
the bug *exists*, and roughly what it does.


> While it may seem like a quick and simple shortcut to work around a bug in
> the short term, browser sniffing creates a *maintenance nightmare* further
> down the road.
>
>
> What maintenance nightmare? Do people even consider what they are implying
> before they write things like this? The browser sniffing author in this case
> showed that they afford to pay a little attention Opera, by adding the
> workaround to an Opera-only bug. So it is no surprise that they were able to
> go back in and add another *36 characters* to let the newer bug-fixed
> version of Opera work in the same manner as all other UAs are expected to
> work. How is that a maintenance nightmare? The author learns that Opera
> fixed the bug in a way that broke his code, and he quickly issues an easy
> fix.
>
> Anyone else using his code either cares or does not care that the old code
> breaks on the new Opera; if they do care then they go download the newest
> version, or do their own troubleshooting. If a newer version of Opera broke
> my code, and I wanted to troubleshoot, the first thing I would do would be
> search my code for the string "opera", and find the places where I am
> working around bugs by browser sniffing for it.
>

*If* the author of the tool is still around and willing to work on the code,
it's easy to change the codebase to correct this issue.  In this case it
was.  Often it is not, since the author has long since disappeared, or
doesn't care, or whatever.

The more important issue is the multitude of *end-users* who have a tool
that is now broken in Opera.  Many of them won't ever know there was an
update to fix the issue, many who do know won't have access to the code
anymore, and many who do have access to the code won't take the effort to
update it everywhere they've used it.  This makes it rather difficult to
push out the patch to wide deployment.  Now, because the original tool
author took the easy way out and just browser-sniffed rather than
feature(/bug)-detected, you have a tool out in the wilds of the internet
which is freshly broken for Opera and will likely remain so for a long time,
due to Opera *fixing* its bug.


> The bug detection routine that the article proposes is much more complex,
> assumes the author would have the time and inclination to investigate the
> problem to the degree needed to write something like that, and also assumes
> that all UAs that might need this routine would flawlessly support other
> modern JavaScript methods like document.implementation.createDocument. Its
> impractical to test for possible flaws in every built-in method you might
> use, but a little browser sniffing for known problems in known rendering
> engines can provide work-arounds that help more than they hurt. Especially
> if the alternative is to just not spend any time at all on a problem that is
> only known to affect less than one percent of the site's audience (since
> those of us who write code for a living often have to justify the time we
> spend on something).
>

It really isn't all that complex.  The knowledge required to do so is just
above the knowledge required to recognize that there's a bug in the first
place and figure out how to hack around it.

It *is* impractical to test for flaws in every built-in method you use, but
no one's suggesting that authors do so.  It is being suggested that *in
exactly the sort of situation linked above*, one can feature-detect rather
than browser-sniff to achieve the exact same effect but in a more robust
manner.  You don't have to sniff for *every* possible inconsistency, just
the ones that you know about in the methods that are important to you; in
other words, the exact same set of situations in which you would
browser-sniff.


> Whenever you feel tempted to solve a problem with the inelegant browser
> sniffing hack, take a moment to ask yourself if there is a simple way to
> detect the bug instead.
>
>
> In the case of CSS, the answer is always "no". The only method
> currently available is by using parsing hacks (or IE's comment hacks, if you
> want to detect IE specifically). And those are going away mostly in newer
> and newer versions of modern (i.e., non-IE) User Agents. Proposals for
> feature detection have much worse problems than UA detection (the browser
> will say it supports something, even if it is buggy). We do have media
> queries, which would be a natural place to query for a particular rendering
> engine, UA, and/or version number. But implementors refuse to implement it.
>

Except that in the linked blog post above, the answer is "yes".  And it
doesn't rely on the browser being honest; it produces certain conditions and
sees if the bug asserts itself.


> I've enjoyed reading the logical arguments for UA detection here recently,
> but logic has been tried before on this topic, unsuccessfully. In the end,
> the answer back from implementors has been "we are not 100% happy with the
> results of UA detection in JavaScript, and so we're afraid to try anything
> even remotely resembling it in any way in CSS." Or more succinctly, "We
> don't wanna, we ain't gonna, and you can't make us."
>

The question you have to address is just *why* implementors are unhappy with
UA detection in javascript.  Hint: it's not something unique to javascript.
Browser sniffing is inherently flawed, and punishes implementors for fixing
bugs in their browsers.

~TJ