3 ms·

"I have 500,000 corporate users on Firefox 3.6. We just completing a test cycle of Firefox 4 on many thousands of internal business web applications" I don't r

by middus 15y ago

"I have 500,000 corporate users on Firefox 3.6. We just completing a test cycle of Firefox 4 on many thousands of internal business web applications" I don't really get the problem? Firefox 4 is a browser that honours web standards. So if your web apps work on version 4, why shouldn't they on 5? Firefox won't drop JavaScript or the <table> element!?

gaius 15y ago
Evidently not Because there is the possibility that there are bugs in 5 that were not in 4? As many others have said, extensions that work in 4 do not work in 5...
- middus 15y ago
  This manager is not talking about extensions, he's talking about web apps. I'm pretty sure that it's rather unlikely that Mozilla has a major screw up in the Gecko rendering engine or their javascript implementation. Even if so, the accelerated release cycle will ensure that it'll be fixed right away.
  - jbk 15y ago
    Rather unlikely can still be very annoying if it breaks one of your major corporate web application.
  - vessenes 15y ago
    It's interesting -- when I have my software company that builds web apps hat on, I assume that if there's a rendering problem with a new browser, it's our problem: these guys lead the standards groups, so we fix our app as best we can, and remember that people are used to seeing occasionally broken stuff on the internet. Not the end of the world. That's contrary to this point of view, and maybe just speaks to how IT and internal corporate application mindsets are different.
    - Silhouette 15y ago
      > when I have my software company that builds web apps hat on, I assume that if there's a rendering problem with a new browser, it's our problem I used to assume that, but I've spent so much time in the past few months fixing silly bugs that really were regressions in mainstream browsers that my default is now to assume that if something works in two or three browsers but not another then they really have broken something. This is why I have been so critical of the rapid updates policy in various recent discussions.
      - vessenes 15y ago
        Interesting.. And frustrating! I haven't had that experience so far; got any tips on what to avoid right now?
        Silhouette 15y ago
        For no browser in particular, or in some cases for several of them: - Typography (text rendering that is actually illegible on some platforms, due to basic kerning issues, poor antialiasing when CSS3 effects are applied, misapplication of OpenType features, and so on) - Java applets (outright crashing, or more annoying things like not quite passing keyboard/mouse events through properly) - HTML5 video (which encoding shall we use this week?) - CSS3 rounded corners and gradients (assorted rendering bugs that made these look awful if you'd relied on the new features) All of these have been pushed in minor/point releases, with the exception of Google dropping H.264 video support, where they appear to have quietly done a U-turn at some point having made a big announcement that they were going to push it.
  - gaius 15y ago
    Well, neither of us know exactly what he's talking about, but clearly his organization does think testing on a new version is worthwhile enough to pay people to do it, which suggests they have been burnt by it in the past. People who fiddle with their computers at home for fun really have no experience that carries over to supporting non-technical users who absolutely rely on in-house developed apps to do their work, and no-one gets paid if they can't.
  - fierarul 15y ago
    >I'm pretty sure that it's rather unlikely that Mozilla has a major screw up in the Gecko rendering engine or their javascript implementation. You're giving the Firefox guys too much credit. Bugs do happen even in web browsers and not all corporate websites are made by people that don't know about programming or standards. The thing is: somebody pays (sometimes a whole lot) to use an webapp and you have to guarantee that your site will work for him on a given browser version. This means you actually test the product in various ways. You can't just put blind trust into Firefox that is will just be perfect from now on. >Even if so, the accelerated release cycle will ensure that it'll be fixed right away. Yeah, and who pays for the downtime, losses, etc. in the mean time? As an user I like Chrome and I see the value of having it autoupdate on my parent's computer so I don't have to manage that myself. But in a corporation some pretty big money are starting to depend on browsers so you can't just believe new updates won't subtly break something.
    - eftpotrm 15y ago
      While I don't dispute the honest good intentions here, I do, strongly, dispute the cost benefit analysis. They're testing every last security fix, every last point release, every last sneeze from the platform vendors against everything in their entire app pool. That might've been viable Way Back When; now, I doubt it. There's just too much changing at too many levels. What about if the user combines this service pack with these security fixes but not that one, this particular browser release, running over a remote link with either a 3G modem or a home firewall and a particular model of router? Bugs happen, both in the platform and in the app. I've had my code suddenly fail due to a new version before, too. Once, in ten years, and a dev team of two had a fix up and running in a few hours. What's the cost to the business to run all this checking? What's the cost to the business to be running older, less secure, less featureful versions of the software? What would be the cost of the likely scale of failure if they were broken by a new release (factoring in the very, very low likelihood of that happening)? What would be the business interruption cost of having the app down? What would be the opportunity cost of having to pull developers off their other projects and push them quickly onto fixing this internal app? If it's an internal app, you've likely got a small enough, contained enough userbase that it's manageable for you to have a short period of downtime occasionally - I've never known such a service that didn't, frankly. If it's a public app, good luck to you trying to tell your customers they can't use this new version. If it's a third-party app, that's their problem. If Oracle want to tell me their latest, greatest, very expensive CRM dashboard isn't compatible with a new browser point release, exactly what am I paying them all that money for? Stop being officious. Stop being risk averse beyond reason. Look at the actual numbers and just let it run.
  - encoderer 15y ago
    > I'm pretty sure that it's rather unlikely I don't get your assertion. Is it that you don't really need to do testing the way your quoted manager did? Have you any idea what you're talking about? Have you any notion of the cost of downtime -- whether your company is big or small? "pretty sure" and "rather unlikely" are absurd in this context. I don't even understand what your point is? That Mozilla shouldn't do anything to cater to these scenarios because people should just deploy new versions on trust?
bluedanieru 15y ago
A lot of those internal apps hang by a thread with regard to cross-compatibility. Many large companies still live in IE6 land where change occurs on a geologic scale, and what's more that's sort of the way they want it. As much as businesses like to bitch about IT costs the fact is that, for what they pay, most of them get a quite a lot of utility out of their poorly-budgeted and mismanaged IT departments. Even their talented developers are so overworked and underpaid and mismanaged that they churn out mostly garbage, but it's usually garbage that gets the job done right then. Anything more than that is always viewed as a luxury anyway, until you can't upgrade anymore because 10% of the internal apps misperform running under a newer JS implementation. Nevertheless, the business sees something better and thinks they might need it but they first have to wake up to the fact that OSS != free shit, and they don't like that at all. "What happens if they EOL FF5?" Well, you have the source, fix the problem yourself, that's how it works. You're a big organization, you got this amazing tool for absolutely nothing, give something back. If you can't accept those terms, fuck off back to IE land. So Dotzler is absolutely right. There is no way his organization can please enterprise as they have impossible demands, so fuck them.

by middus 15y ago

gaius 15y ago

Evidently not Because there is the possibility that there are bugs in 5 that were not in 4? As many others have said, extensions that work in 4 do not work in 5...

middus 15y ago
This manager is not talking about extensions, he's talking about web apps. I'm pretty sure that it's rather unlikely that Mozilla has a major screw up in the Gecko rendering engine or their javascript implementation. Even if so, the accelerated release cycle will ensure that it'll be fixed right away.
- jbk 15y ago
  Rather unlikely can still be very annoying if it breaks one of your major corporate web application.
- vessenes 15y ago
  It's interesting -- when I have my software company that builds web apps hat on, I assume that if there's a rendering problem with a new browser, it's our problem: these guys lead the standards groups, so we fix our app as best we can, and remember that people are used to seeing occasionally broken stuff on the internet. Not the end of the world. That's contrary to this point of view, and maybe just speaks to how IT and internal corporate application mindsets are different.
  - Silhouette 15y ago
    > when I have my software company that builds web apps hat on, I assume that if there's a rendering problem with a new browser, it's our problem I used to assume that, but I've spent so much time in the past few months fixing silly bugs that really were regressions in mainstream browsers that my default is now to assume that if something works in two or three browsers but not another then they really have broken something. This is why I have been so critical of the rapid updates policy in various recent discussions.
    - vessenes 15y ago
      Interesting.. And frustrating! I haven't had that experience so far; got any tips on what to avoid right now?
      - Silhouette 15y ago
        For no browser in particular, or in some cases for several of them: - Typography (text rendering that is actually illegible on some platforms, due to basic kerning issues, poor antialiasing when CSS3 effects are applied, misapplication of OpenType features, and so on) - Java applets (outright crashing, or more annoying things like not quite passing keyboard/mouse events through properly) - HTML5 video (which encoding shall we use this week?) - CSS3 rounded corners and gradients (assorted rendering bugs that made these look awful if you'd relied on the new features) All of these have been pushed in minor/point releases, with the exception of Google dropping H.264 video support, where they appear to have quietly done a U-turn at some point having made a big announcement that they were going to push it.
- gaius 15y ago
  Well, neither of us know exactly what he's talking about, but clearly his organization does think testing on a new version is worthwhile enough to pay people to do it, which suggests they have been burnt by it in the past. People who fiddle with their computers at home for fun really have no experience that carries over to supporting non-technical users who absolutely rely on in-house developed apps to do their work, and no-one gets paid if they can't.
- fierarul 15y ago
  >I'm pretty sure that it's rather unlikely that Mozilla has a major screw up in the Gecko rendering engine or their javascript implementation. You're giving the Firefox guys too much credit. Bugs do happen even in web browsers and not all corporate websites are made by people that don't know about programming or standards. The thing is: somebody pays (sometimes a whole lot) to use an webapp and you have to guarantee that your site will work for him on a given browser version. This means you actually test the product in various ways. You can't just put blind trust into Firefox that is will just be perfect from now on. >Even if so, the accelerated release cycle will ensure that it'll be fixed right away. Yeah, and who pays for the downtime, losses, etc. in the mean time? As an user I like Chrome and I see the value of having it autoupdate on my parent's computer so I don't have to manage that myself. But in a corporation some pretty big money are starting to depend on browsers so you can't just believe new updates won't subtly break something.
  - eftpotrm 15y ago
    While I don't dispute the honest good intentions here, I do, strongly, dispute the cost benefit analysis. They're testing every last security fix, every last point release, every last sneeze from the platform vendors against everything in their entire app pool. That might've been viable Way Back When; now, I doubt it. There's just too much changing at too many levels. What about if the user combines this service pack with these security fixes but not that one, this particular browser release, running over a remote link with either a 3G modem or a home firewall and a particular model of router? Bugs happen, both in the platform and in the app. I've had my code suddenly fail due to a new version before, too. Once, in ten years, and a dev team of two had a fix up and running in a few hours. What's the cost to the business to run all this checking? What's the cost to the business to be running older, less secure, less featureful versions of the software? What would be the cost of the likely scale of failure if they were broken by a new release (factoring in the very, very low likelihood of that happening)? What would be the business interruption cost of having the app down? What would be the opportunity cost of having to pull developers off their other projects and push them quickly onto fixing this internal app? If it's an internal app, you've likely got a small enough, contained enough userbase that it's manageable for you to have a short period of downtime occasionally - I've never known such a service that didn't, frankly. If it's a public app, good luck to you trying to tell your customers they can't use this new version. If it's a third-party app, that's their problem. If Oracle want to tell me their latest, greatest, very expensive CRM dashboard isn't compatible with a new browser point release, exactly what am I paying them all that money for? Stop being officious. Stop being risk averse beyond reason. Look at the actual numbers and just let it run.
- encoderer 15y ago
  > I'm pretty sure that it's rather unlikely I don't get your assertion. Is it that you don't really need to do testing the way your quoted manager did? Have you any idea what you're talking about? Have you any notion of the cost of downtime -- whether your company is big or small? "pretty sure" and "rather unlikely" are absurd in this context. I don't even understand what your point is? That Mozilla shouldn't do anything to cater to these scenarios because people should just deploy new versions on trust?

bluedanieru 15y ago

A lot of those internal apps hang by a thread with regard to cross-compatibility. Many large companies still live in IE6 land where change occurs on a geologic scale, and what's more that's sort of the way they want it. As much as businesses like to bitch about IT costs the fact is that, for what they pay, most of them get a quite a lot of utility out of their poorly-budgeted and mismanaged IT departments. Even their talented developers are so overworked and underpaid and mismanaged that they churn out mostly garbage, but it's usually garbage that gets the job done right then. Anything more than that is always viewed as a luxury anyway, until you can't upgrade anymore because 10% of the internal apps misperform running under a newer JS implementation. Nevertheless, the business sees something better and thinks they might need it but they first have to wake up to the fact that OSS != free shit, and they don't like that at all. "What happens if they EOL FF5?" Well, you have the source, fix the problem yourself, that's how it works. You're a big organization, you got this amazing tool for absolutely nothing, give something back. If you can't accept those terms, fuck off back to IE land. So Dotzler is absolutely right. There is no way his organization can please enterprise as they have impossible demands, so fuck them.