• sokobahn (unregistered)

    Possible reason could that CSS is hard-coded in some "platform code" and dev cannot change that. Or maybe CSS are one team, JS is another team and bugfix task for visuals was assigned to JS guy. So he did his best.

  • scriptMonkey (unregistered)

    jQuery. The cause of, and solution to all of Javascript's problems - https://www.youtube.com/watch?v=SXyrYMxa-VI

  • Dave (unregistered)

    OP here. What I didn't mention is that the script is loaded by a <script src=... tag, which was then cargo-culted to another site (managed by the same devs) with an absolute url to load it from the original site. That's where I discovered it and found it broken on both sites. Also, the CSS classes mentioned are defined in a file loaded from yet another site that the devs don't manage.

  • Robin (unregistered)

    While polling for an element to exist is indeed a bad solution most of the time, I can see that it may be necessary - perhaps the elements concerned are added by some third party code, in some asynchronous manner, and the library concerned has no API for "run some code once it's definitely here". Although almost certainly there's a much better to achieve whatever outcomes are actually needed.

    But not putting any kind of upper limit on the number of retries, or time to keep trying, before giving up and ideally logging that the element couldn't be found, is amusingly bad. Still not likely a noticeable problem for users unless there are hundreds of these never-working checks going on at once - but still a true WTF.

  • Sauron (unregistered)

    At least, it uses class selectors.

    Also, TRWTF is jQuery.

    No, I take back what I said, TRWTF is actually JavaScript.

  • Dave (unregistered)

    OP here again. The sites managed by the devs mentioned in my submission have some pages that get data from a database by making AJAX calls to a controller, which returns JSON data, which is parsed and put into an empty div via innerHTML. Recently, one of the pages stopped displaying data. Why? Because one of the devs saw an empty div and decided it wasn't needed. Poof!

  • WTFGuy (unregistered)

    Dave, my friend ...

    My advice is to look for other work. Either that or become a paid contributor here at TDWTF. This may be comedy gold, but it's worklife insanity.

  • The Dave G (unregistered) in reply to Dave

    FTFY

    Insert data from X here.

    I get the sense that this group of "devs" would be a great source of WTF fodder, but I also sense it would get old after the 20th WTF or so...

  • Daniel Orner (github) in reply to Robin

    I invite you to check out https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver .

  • noOne (unregistered)

    'The thing you don't see in this code block is that the CSS class gsc-search-button doesn't exist and is never used in the DOM. gsc-search-button-V2 is,'

    Maybe, someone tried to style the class, which didn't work, as the class get's immediately removed from the button, and they noticed, that renaming the class 'gsc-search-button-V2' just works.

  • (nodebb)

    Add another [:wtf:]: The call to setTimeout() recursively calls the check() function. The code does not busy-loop every 250ms, it busy-recurses every 250ms. Four times per second, it adds another layer to the stack.

  • sokobahn (unregistered) in reply to toodle

    No, setTimeout() just remembers a closure with enclosed params in the queue and immediately ends. The stack doesnt change.

  • (nodebb) in reply to toodle

    I know nothing about JS - but doesn't the outer check() return immediately after setting the timeout? Why would it recurse?

    (fully prepared to be educated if my impression is wrong)

  • Ollie Jones (unregistered)

    Cool. Another thing for the list of "stupid pranks a webdev can pull to run down the batteries on peoples' cellphones".

  • And then I realised (unregistered)

    I was all like I can't wait to comment on this and say ahem it's not setInterval, it's setTimeout which only runs once but then I saw someone mention recursion in the comment and I checked again and was like OMG it's worse than what I imagined :/

  • Mohit (unregistered)
    Comment held for moderation.
  • David Mårtensson (unregistered) in reply to Sauron

    I disagree, for all its quirks and faults, javascript still is the ONLY common scripting language for web browsers.

    While WebAssembly exists, it cannot work on it own, you still need javascript for any interaction with anything since WebAssembly can ONLY talk to the javascript engine, nothing else.

    And there have been many attempts to replace javascript, they either failed due to not getting general acceptance (vbscript in brower, googles dart and some others), or they failed due to security problems (flash, java applets, silverlight) so javascript have proven the only surviving contender which is an achievement :)

Leave a comment on “The DOM Checker”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article