In this example, Facebook Connect (technically Facebook Login) has an open bug that prevents IE8 users from connecting. It send error messages, and it isn't clear to users that the error is with Facebook. It's a pretty consistent bug, so our IE8 users will never be able to connect until Facebook fixes the bug.

Should we…

  1. Issue a warning or alert after they click the button, but before Facebook gives an error?
  2. Put a warning around the FB Login button saying it won't work?
  3. Remove the FB Login option altogether until the bug is fixed?
  4. Remove the FB Login button and let people know it's because of a bug on FB's side?
  5. User your even better idea? What is it?
  • Related: ux.stackexchange.com/questions/12756/… Dec 19, 2011 at 23:51
  • @PatrickMcElhaney, that's interesting but it doesn't quite apply to bugs and errors, does it?
    – Taj Moore
    Dec 19, 2011 at 23:54
  • Related, not duplicate. :-) Dec 20, 2011 at 0:04
  • As a hack, you could force IE8 into IE7 compatibility mode. Of course that may not be what you want, as it could brake other stuff... As a sidenote, could you provide some kind of reference to the open bug, that would show this is indeed an acknowledged bug? There are oh so many of them, I think it's the same one I stumbled upon, but can't be sure - this will also help discourage answers / comments of the "this might not be a bug" variety.
    – user5595
    Dec 20, 2011 at 1:33
  • 2
    Edited the title to be generalizable. Advice related to this (aside from "fix it") should be applicable to most situations where a feature must be disabled because of uncontrollable circumstances.
    – Ben Brocka
    Dec 20, 2011 at 5:39

3 Answers 3


I agree with TamDenholm in that you should not display the connect option for IE8 users.

However I feel there are some users that do care. For example:

  • I may have created an account using FB connect in a different browser
  • I may be using a different computer (most corporate environments use/force IE)

These are probably still edge cases, but I would provide a link along the lines of 'Why can I not login using Facebook?'. Any user who chooses this link can be told of the issue, and offered a workaround ('use a supported browser').

  • I agree that there should be an explanation somewhere on the site. Probably in FAQs or suchlike. But displaying something that doesn't work is a problem with your site, not FB. Dec 20, 2011 at 9:51
  • Agree, that is why I suggested not to display it.
    – Jon White
    Dec 20, 2011 at 14:29
  • In the end, we replaced the button with this text: “Facebook Login is currently not supported in Internet Explorer 7 or 8. You may use IE9, Firefox, or Chrome to log in using Facebook.” (each browser links to the respective download page.)
    – Taj Moore
    Dec 21, 2011 at 21:28

You should not display the facebook login at all for IE8 users and dont explain why either, the user doesnt care. The people specifically looking to log in with Facebook that use IE8 and will NOT go with the alternative solution you have offered them, is a very small amount of people.

Assuming you have an appropriate way for customers to contact you without logging in or signing up, if they care that much they will email you to ask about facebook login, but i'd be surprised if you get a single inquiry.

When the bug is fixed, you can add the facebook login, if you really want to promote it, send an email to those accounts that use IE8, telling them its now available, assuming you're logging that kind of thing.

The user demographic you're concerned about is absolutely tiny, those that use IE8 and require facebook login and will NOT use the alternative solution. Those that perhaps would prefer to use both those technologies will likely just go with the alternative you provide them.

Other things to look into, have you made sure that the bug is defo 100% facebook's fault? Also, has anyone from the developer community come up with a work around for it?

  • It is 100% Facebook; no workarounds that anybody understands.
    – Taj Moore
    Dec 19, 2011 at 23:48
  • @YannisRizos Perhaps i was unclear, what i meant was people that will not choose an alternative solution if there is no facebook login. What you're talking about is the people that will choose FB login if available, those that absolutely require it and will not go forward with the provided alternative is a very small subset.
    – TamDenholm
    Dec 20, 2011 at 1:58
  • @YannisRizos I hope my edits have made it more clear.
    – TamDenholm
    Dec 20, 2011 at 2:28

I think transparency and good communication is part of good customer relations. So if a feature is broken, then you should mention it in a blog post or tweet to let users know that it's being addressed.

If you can, disable the functionality in whichever way is quickest so you can get to solving the actual problem (but not have users waste their time trying to use a broken feature in the meantime). Depending on how important the feature is, it may be worth the effort to point users to an alternative (either within the UI, or if the explanation is too long, then just point them to the blog post / support page that explains it).

Naturally, all of this only applies if it doesn't take more time to explain/redirect/disable than it does to actually fix the glitch.

And, although it doesn't apply in this particular case, good SCM can also be of great help. Ideally, if your code is modular enough, you can simply rollback that portion of the app to the last working revision and not have to deal with any of this on the production site. And as a preventative measure, the next time you roll out any changes, you conduct extensive regression testing before you push the changes to the production site.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.