CodeSOD: NoNoscript


  • Trolleybus Mechanic

    I KNOW YOU LOVE CLEVER CODE!

    Actually, go back to that message that you just read, and ignore it. You do not like clever code after all.

    @another site that's making my Monday so cuddly like a porcupine dual-weilding nunchucks made of cactusesii said:

    <script>
    <!--
    function hideJSWarn() {
        if(window.top == self) {
            document.getElementById('noJSWarn').style.display = "none";
        }
    }
    //--></script>
    

    1) I doubt that [url="http://stackoverflow.com/questions/1507939/using-html-comment-tag-still-relevant-around-javascript-code"]Netscape 1.x[/url] is much of an issue anymore.

    2) "if (window.top == self)" is what 'plz give me teh codes' people use to test to see if the browser is Javascript enabled. Note that it runs inside a Javascript function.

    3) the message is, of course, by default set to display:block-- so it's present on the screen for a good few seconds until the page is rendered enough to run the Javascript.



  • @Lorne Kates said:

    another site that's making my Monday so cuddly like a porcupine dual-weilding nunchucks made of cactusesii

    +1



  • @Lorne Kates said:

    2) "if (window.top == self)" is what 'plz give me teh codes' people use to test to see if the browser is Javascript enabled. Note that it runs inside a Javascript function.

    Wouldn't that be false if the site was securely mediated by frames?



  • Not that I am advocating this particular script (not really looked into their reasons for doing it this way instead of just a NOSCRIPT), but they may have somewhat reasonable reasons. For example, they may be testing for some particular level of scripting support. Eg. before calling hideJSWarn, they may be testing (or at some point in history, they may have originally tested) to see if the browser supports all the APIs they needed to use. Maybe before using DOM 2 StyleSheets, they may have wanted to test, and say "sorry, your browser either doesn't have JS enabled, or is not good enough to run the scripts required here".@Lorne Kates said:

    2) "if (window.top == self)" is what 'plz give me teh codes' people use to test to see if the browser is Javascript enabled.
    Looks like the thinking is backwards. "We only want the text to appear on the top-most page if there are IFRAMEs." But of course in this case, it will only hide the warning on the top-most page of a frameset. What this will instead achieve is to hide it only on the top-most page, while leave it visible in any child FRAMEs or IFRAMEs, even if script is enabled. Doh.@Lorne Kates said:
    3) the message is, of course, by default set to display:block-- so it's present on the screen for a good few seconds until the page is rendered enough to run the Javascript.
    This just means they are running the script too late, such as from an onload event handler. Putting the hideJSWarn call near the /body or in a DOMContentLoaded(/onreadystatechange for older IE) handler would make it run faster.


  • Trolleybus Mechanic

    @TarquinWJ said:

    "sorry, your browser either doesn't have JS enabled, or is not good enough to run the scripts required here"
     

    The wording of the noJSWarn div is a WTF by itself: "Your browser is executing scripts on this page. If this message persists, please make sure that you are visiting a correct site and JavaSript support is enabled in your browser, and then try again."

    Make sure I'm visiting the correct site? Wha?  They can make this message appear on incorrect sites and-- but I'm not executing js, that's why the noJS warning is there-- I-- shitfuck!

    @TarquinWJ said:

    they may be testing for some particular level of scripting support

    The only scripts the site runs:

    1) Set a cookie (what you can set cookies serverside since when omg wtf qqb)

    2) Write some css (what you can just have a .css file and serve it wmf wto?)

    3) Load a custom .js file that is over 200 lines long, does janky browser sniffing, and create a frame work-- all to capture KeyDown event so it can submit the form on Enter (what is jquery or any other client side crossbrowser framework and what do you mean pressing enter just submits the default form anyways MMMMMMMMMMMMMMMM)

     



  • @Lorne Kates said:

    3) Load a custom .js file that is over 200 lines long, does janky browser sniffing, and create a frame work-- all to capture KeyDown event so it can submit the form on Enter (what is jquery or any other client side crossbrowser framework and what do you mean pressing enter just submits the default form anyways MMMMMMMMMMMMMMMM)

    Because adding a submit button was too hard?


  • Trolleybus Mechanic

    @Ben L. said:

    Because adding a submit button was too hard?
     

    This is the extent of the form:




  • @Lorne Kates said:

    @Ben L. said:

    Because adding a submit button was too hard?
     

    This is the extent of the form:



    Is the "Sign In" button controlled by javascript, too? Because browsers should automatically submit-on-enter if there's a submit button.



  • @Lorne Kates said:

    "Your browser is executing scripts on this page.
    And this is what appears when JS is disabled? o_O I assume the word "not" is missing.@Lorne Kates said:
    Make sure I'm visiting the correct site?
    Maybe they expect all users to have JS enabled only on certain sites. Site-specific settings and the NoScript extension are in use everywhere, right?@Lorne Kates said:
    shitfuck!
    Couldn't have put it better myself.@Lorne Kates said:
    all to capture KeyDown event so it can submit the form on Enter
    Ouch. That is some true WTFery.


  • :belt_onion:

    @Ben L. said:

    Is the "Sign In" button controlled by javascript, too? Because browsers should automatically submit-on-enter if there's a submit button.

    Lorne literally JUST SAID THAT.


  • Trolleybus Mechanic

    @Ben L. said:

    Is the "Sign In" button controlled by javascript, too? Because browsers should automatically submit-on-enter if there's a submit button.

    <input type="submit" value="Sign In" name="btnSubmit">

    That's it. That's all there is. You're starting to see my frustration now?



  • @Lorne Kates said:

    @Ben L. said:

    Is the "Sign In" button controlled by javascript, too? Because browsers should automatically submit-on-enter if there's a submit button.

    <input type="submit" value="Sign In" name="btnSubmit">

    That's it. That's all there is. You're starting to see my frustration now?

    Does the developer's keyboard not have an enter key and they were just doing it from the spec?



  • @Ben L. said:

    Does the developer's keyboard not have an enter key and they were just doing it from the spec?



  • Isn't that div a "break out of frames" message with a terrible name? If I'm reading it right, that's what this code does...


  • Trolleybus Mechanic

    @blakeyrat said:

    Isn't that div a "break out of frames" message with a terrible name? If I'm reading it right, that's what this code does...
     

    It might be, if there were any frames, or break out of frames code anywhere on the page. =(



  • @Lorne Kates said:

    Make sure I'm visiting the correct site? Wha?
     

    Putting a site inside a frame is a common technique for hijacking the browser and steal data (on this case, the passwod). You just need to add some DNS poisoning (the only hard part) and a 301 redirection. Depending on what site is that, this is quite a sensible warning.



  • This looks like a perfect example of "web development by copy-paste from w3schools".



  • @Lorne Kates said:

    1) I doubt that Netscape 1.x is much of an issue anymore.

     

    Tell that to Ron Paul: http://www.ronpaulcurriculum.com/public/department24.cfm

     


Log in to reply