RE: Navigator standard change proposal

You mixed the two examples, I'm afraid.

You are addressing the hypothetical FF 47.3 bug example while referring to the actual Chrome+plugin example where the problem was with the one specific plugin, while my abc's are about the hypothetical FF 47.3 browser bug.

But, to answer your question, neither b) nor c) address the issue immediately and thus run the risk of loosing the FF 47.3 users, while a) is bothering everyone which is not user friendly.
Also, even though you are correct that users have no ideal which browser they are using, but this is not an issue because the correct way is to first inform the user "you are using FF 47.3" and then state the issue and suggest solutions...

"Not at all. Code around the issue. When possible." - As before, I completely agree.
The question is what to do when it is not possible. And these cases do exist.

You misunderstood, I am saying that d) is the best and only <strong>immediate</strong> approach, not the only approach all together.
Not filing a bug against the browser when there is one is a big mistake. Not caring about possible long term solutions is also a big mistake.
Having a quick solution to put users at ease and to let them know that the issue is being handled does not mean the issue should be kicked under the rug.

"UA detection shouldn't be done in a vacuum given its current state and historical track record." - I disagree. UAs should identify themselves clearly and cleanly. How this information is used or mis-used cannot be their responsibility. Look, if a developer uses if(version > 9) instead of if(version == 9) it is both his fault and his loss because his competition is going to support version>9 and his will loose users to the competition.

"All the other workarounds still need to happen." - I agree and would never suggest otherwise. The difference is that you guys thing that this is somehow the responsibility of the standard to prevent bad programmers from being bad programmers and I strongly disagree with that view.
"Adding UA detection as a solution builds in the need for ongoing maintenance without removing the need to still perform the other workarounds." - I strongly disagree that this is the case for good programmers who know what they are doing.
"By leaning on UA detection your are just adding work, not reducing it." - I strongly disagree given the examples I provided.

It seems to me that this entire discussion is one big unfortunate "appeal to consequences" fallacy.

I strongly disagree that it is in any way a browser developers fault when we, the web developers, do something wrong with a useful feature or with useful information.
I simply can not agree with that assesment or view.



-----Original Message-----
From: Adrian Roselli [mailto:Roselli@algonquinstudios.com] 
Sent: 13. februar 2014 16:52
To: Predrag Stojadinovic; public-html@w3.org
Subject: RE: Navigator standard change proposal

I don't mean to drag this thread out. Chaals has already responded to the bulk of this in far better detail than I could, but I am going to address where you mention me directly and also what I think is a flaw in your example scenario...

> From: Predrag Stojadinovic [mailto:predrags@nvidia.com]
> Sent: Thursday, February 13, 2014 6:09 AM
[...]
> Here is an actual case that really did happen to me:
> Several weeks ago my web-app was crashing in Chrome but only if the 
> iMacros plugin was installed. Without it the web-app worked as expected.
> Nothing was in the console log, other than an error from the iMacros 
> plugin. And this didn't crash other websites we tested.
> In Firefox with iMacros plugin, the web-app worked as expected.
> In IE with iMacros plugin, the web-app worked as expected.
> 
> So, how does feature detection solve this problem?
> It doesn't. But browser detection did.
[...]
> What options are there for the developer of a high traffic website at 
> that moment?
> 
> a) To bother ALL users with a message saying "If you are using FF
> 47.3 then…" ?

Having worked with users for years, they typically don't know what their browser version is, let alone what browser they are using. You may have had this experience as well. Sure, it's anecdotal, but I'd bet we can dig up some numbers that support it.

> b) To just file a FF bug and HOPE that his FF users will not leave
> and go to his competition until FF fixes the bug ?

There is no reason this cannot be done as well. It should be done anyway.

> c) To rewrite his entire code in order to handle this one FF bug all
> over the place ? (IFF this is even possible to do) (and also do so 
> whenever any bug in any browser occurs)

Yes. This should be considered and, if it makes sense, done in conjunction with (b).

> d) OR to just add one simple line of code very quickly and handle it:
> a. if(navigator.browserName==="Firefox" &&
> navigator.browserVersion==="47.3") { xyz.inform("…"); }

Sure, you can do that, but at some point you will find that you need to go back and adjust it. Assuming the user experience is so important, that's an ongoing task for which you or your client will need to pay. If you don't believe that at some point you'll need to update that, look at the historical evidence which you have already acknowledged.

Let's not forget that in your example you cited a specific plug-in that was causing things to break in a particular browser release. This approach shuts out all users of the browser version, not just the users of the offending plug-in. In essence, you are blocking more users than is warranted because this approach is so easy, not because it's correct.

If anything it is proof why UA detection is a shotgun approach to an issue that requires a far more nuanced and multi-faceted approach.

> Apparently, from reading the answers here, options a), b) and c) are 
> somehow preferable to d)…?

I don't see why you wouldn't consider doing (a), (b), and (c) regardless of whether or not (d) was even viable. In a perfect world of an ideal Navigator object, *you still need to do those first two (or three) steps*.

> I honestly fail to see how we can even be discussing this.
> It seems as if you treat web-apps the same way as desktop apps: wait 
> for the upgrade and hope for the best…?

Not at all. Code around the issue. When possible.

> Charles and Adrian, what problems does browser detection cause for the 
> users?

In a vacuum, none. In the hands of developers, lots.

Given your example above, you are making an assumption that (d) is the best approach and perhaps the only approach, when in reality you should be considering all of them. In short, having the Navigator object doesn't reduce the work *you* need to do, if anything it creates more work for you down the road and, if you don't do that work, may eventually harm your users (see all the other emails about the Firefox and Opera teams trying to get sites to fix their broken code).

So, here's my response in a nutshell:

UA detection shouldn't be done in a vacuum given its current state and historical track record. All the other workarounds still need to happen. Adding UA detection as a solution builds in the need for ongoing maintenance without removing the need to still perform the other workarounds.

By leaning on UA detection your are just adding work, not reducing it.

[...]


NVIDIA GmbH, Wuerselen, Germany, Amtsgericht Aachen, HRB 8361
Managing Director: Karen Theresa Burns

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Received on Thursday, 13 February 2014 16:36:16 UTC