3 ms·

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 G

by 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?

by middus 15y ago

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?