Not worth a sidebar, but Mozilla's busted-ass site



  • I just updated my Firefox to the newest release, and the upgrade took me to this page showing off Firefox's new features:

    http://www.mozilla.com/en-US/firefox/3.6.13/whatsnew/

    The persona feature looked interesting, and the instructions say "Roll over to try, click to apply"* which rhymes. So I decided to try them out by rolling my mouse over one of the images. Hm. Nothing happened. Ok, let's roll over another one and this time wait longer-- maybe it takes a few seconds to download the image or something. Nope, still nothing...

    Turns out, the webpage Firefox is using to promote the persona feature *doesn't actually work*. The headlining feature. The feature you decided was worth spamming me over, doesn't actually work. Brilliant. I'm quickly realizing why Chrome is eating these guys' lunch.


    *) Of course that's terribly poor web design, since Tablet PCs don't have such a concept as "roll overs". (And dozens of other devices, but those devices by and large can't run Firefox.)



  •  It works almost instantly for me. are you sure you aren't just running noScripts, custom stylesheets or other unknown to me paranoid ff extensions that try to stop bad things



  • @stratos said:

     It works almost instantly for me. are you sure you aren't just running noScripts, custom stylesheets or other unknown to me paranoid ff extensions that try to stop bad things

    Here's my full list of add-ins:

    1) FiddlerHook

    2) Firebug

    3) HttpFox

    4) Java Console

    5) Microsoft .NET Framework Assistant

    None of those have anything at all to do with blocking JS, stylesheets, or anything at all. As far as I'm aware. It just plain don't work.

    Edit: Even if I were running one of those things, shouldn't FF be smart enough to not provide me with instructions that don't work? No matter how you look at it, it's a bug.



  • I disabled all my add-ins to test again, and when I went back to the URL, it's now some stupid survey. So... fuck you Mozilla.



  • @blakeyrat said:

    So... fuck you Mozilla.
     

    I'm sorry for your loss.



  • @dhromed said:

    @blakeyrat said:

    So... fuck you Mozilla.
     

    I'm sorry for your loss.

    I don't get it.

    On another note, Mozilla's sending me a t-shirt apparently as a reward for pointing out how badly they botched implementing a DOM function... far too late to save me from having to write a ream of code to work-around their bug, but I guess it's a nice gesture.



  • @stratos said:

     It works almost instantly for me. are you sure you aren't just running noScripts, custom stylesheets or other unknown to me paranoid ff extensions that try to stop bad things

    The "Roll over to try" doesn't work for me either. But that's OK.  Personas are a WTF all by themself.  It's nothing more than an image that gets loaded into the top part of the browser, behind the buttons and toolbars.  In actual use they are completely stupid and pointless because they interfere with the UI of the browser.  And what's the deal with the version numbers anyway?  Do Firefox developers not understand how decimal numbers work?  6.13 comes after 6.9 ?  Right!

     

     


  • Discourse touched me in a no-no place

    @El_Heffe said:

    And what's the deal with the version numbers anyway?  Do Firefox developers not understand how decimal numbers work?  6.13 comes after 6.9 ?  Right!
    Now now. Some developers (particularly of the opensores kind) like to use sequential minorversion numbers. Just because they didn't have the foresight to use a leading 0 earlier on doesn't mean a damned thing. Just because it's formatted like a decimal doesn't mean it always is.



  • Well, these are not decimals. Just like IP addresses aren't, despite containing dots. 6.1.3 < 6.9 < 6.13 .



  • @bannedfromcoding said:

    Well, these are not decimals. Just like IP addresses aren't, despite containing dots. 6.1.3 < 6.9 < 6.13 .
    Yes, IP addreses are different, but that's a phoney argument.  Version numbers are decimal numbers and should be treated as such.  The problem is that some people (particlarly the linuxy/unixy ones) are hung up on the idea that .01 is for very small changes and .1 is for bigger changes.  That would be OK if it wasn't for the fact that version numbers are completely arbitrary.  You can do anything you want -- even skip numbers and jump from 4.7 to 6.0 like Netscape did years ago

     Oh well, stupid version numbers is the least of Firefox's problems.


  • Discourse touched me in a no-no place

     So how do you have decimal numbers with more than one decimal point?

     

    My current Firefox version is 3.6.12 - looks to me like . is just a separator character.



  • @El_Heffe said:

    Version numbers are decimal numbers and should be treated as such.
     

    This has never been the case. There is no standard for versioning. I am absolutely in favour of multiple dots as change-severity separators. It gives you the room to breathe. Otherwise you'd have to make sure you never make more than 10 changes of a certain type, which sounds silly, doesn't it?

    @El_Heffe said:

    The problem is that some people (particlarly the linuxy/unixy ones) are hung up on the idea that .01 is for very small changes and .1 is for bigger changes.

    The problem is that nobody agrees on what sort of change consitutes which digit position, and I don't think such a general system can exist. If what you say is true and "the linuxy people" are hung up on that, then that's a good thing because at least they're trying.

     @El_Heffe said:

    That would be OK if it wasn't for the fact that version numbers are completely arbitrary.  You can do anything you want -- even skip numbers and jump from 4.7 to 6.0 like Netscape did years ago

    Yeah. So... you agree.



  • @dhromed said:

     @El_Heffe said:

    That would be OK if it wasn't for the fact that version numbers are completely arbitrary.  You can do anything you want -- even skip numbers and jump from 4.7 to 6.0 like Netscape did years ago

    Yeah. So... you agree.

    He just likes to hear himself talk.

    I "learned" that the system was of the form: A.B.Cn where:
    A is the number of full rewrites to the program
    B is the number of features added
    C is the number of bug fix releases (for the current B version)
    n is either A for Alpha (dev build), or B for Beta (testing build)

    Obviously that system is retarded-- in that system, Word would be version 1.5342.58 or something.

    It turns out, in real life, for real projects, made by real developers, "full rewrites of the program" simply never occur. (With a tiny error bar around the word "never" for you annoying nitpickers out there.) So that system might be good for a 2-man shop creating shareware, but it's useless for anything more than that.

    Now I just use dated builds. Sure, in theory that could "break" if I ever build two different versions of the product on the same day, but... seriously I don't work that fast, it'll never happen. "What version is that?" "November 12th." "Ok, I got October, I better upgrade." It works great in practice.



  • @blakeyrat said:

    I "learned" that the system was of the form: A.B.Cn where:

    A is the number of full rewrites to the program

    B is the number of features added

    C is the number of bug fix releases (for the current B version)

    n is either A for Alpha (dev build), or B for Beta (testing build)

    Obviously that system is retarded

     

    That actually makes more sense than arbitrarily assigning severity to a change.



  • @dhromed said:

    @blakeyrat said:

    I "learned" that the system was of the form: A.B.Cn where:

    A is the number of full rewrites to the program

    B is the number of features added

    C is the number of bug fix releases (for the current B version)

    n is either A for Alpha (dev build), or B for Beta (testing build)

    Obviously that system is retarded

     

    That actually makes more sense than arbitrarily assigning severity to a change.

    1. That still requires arbitrarily assigning severity to a change. How big does a feature need to be to count? Does adding one tooltip count? Or is that a bug fix? What if the program had zero tooltips before? What is that one widget had no tooltip before?

    2) The date system I outlined makes a shitload more sense. Just date the fucking build and stop thinking about it.



  • @El_Heffe said:

    It's nothing more than an image that gets loaded into the top part of the browser, behind the buttons and toolbars.
     

    This made me shudder as I remembered Internet Explorer 4. "In this version, we put pointless little swirlies behind the rebar control".

     

    It's also funny that a new feature in a modern Browser is something that a competing browser had partially implemented and then they removed it because they realized it was stupid.

     

     


  • Discourse touched me in a no-no place

     Some more non-decimal numbers that are sure to infuriate anoraks:

    http://www.24hoursoflemons.com/usercontent/lemons/2011rulesstrikeout.pdf

    OH GOD SECTION 3.10 COMES AFTER 3.9!

     

    For more heinous acts, see:

    - Any code of laws from the modern era



  • @dhromed said:

    @blakeyrat said:

    I "learned" that the system was of the form: A.B.Cn where:

    A is the number of full rewrites to the program

    B is the number of features added

    C is the number of bug fix releases (for the current B version)

    n is either A for Alpha (dev build), or B for Beta (testing build)

    Obviously that system is retarded

     

    That actually makes more sense than arbitrarily assigning severity to a change.

    I'm following the standard .NET scheme: (major version).(minor version).(revision).(build number)

    1. major version +1: a new project was defined with new features, change requests, database changes, ...
    2. minor version +1: during maintenance or change request changes occurred that broke compatibility with other systems, e.g. database schema changed
    3. revision +1: changes that don't break compatibility or change the flow of the application
    4. build number: automatically assigned by the build server whenever a build is triggerd

    I'm never in doubt about when to change what part of the version number


  • @bjolling said:

    I'm following the standard .NET scheme: (major version).(minor version).(revision).(build number)

     

    1. major version +1: a new project was defined with new features, change requests, database changes, ...
    2. minor version +1: during maintenance or change request changes occurred that broke compatibility with other systems, e.g. database schema changed
    3. revision +1: changes that don't break compatibility or change the flow of the application
    4. build number: automatically assigned by the build server whenever a build is triggerd

    I'm never in doubt about when to change what part of the version number

     

    Since we're sharing, the last shop I was at had:

    1. major version +2: originally significant new functionality, later just a euphemism for "we ran out of minor version numbers".
    2. major version +1: "roll-up" release consolidating new features from the still-in-use versions running in various sites that can't be coerced into taking a whole release at one time.  Never put into production.
    3. minor version +1: new features needed by all sites within the next few months.
    4. major revision letter: new features needed by one site "right this minute" that in most cases would break all the other sites if implemented across the board.
    5. minor revision letter: bug fixes applied on top of the "major revision" when as it usually turned out those "emergency" features also broke the site that thought they were so damn important.
    The politics referred to in several places above were truly international.  Site X in country X' has some sudden pressing need for a feature that can't wait for a proper testing cycle, while Site Y in country Y' refuses to install anything until a full regression test taking several months is carried out, during which time there will be at least four more versions shoved into the pipeline, with the roles of X and Y reversed on each iteration.  And even though this is all theoretically one company, nobody has the central authority to tell the regional markets what they must do once each update has been shipped to them.  In one case, uninstalled releases dating back three years sat on a shelf in a supposedly "strategic" market region.

Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.