• Richard Cutts (unregistered)

    Ha

     

    Nothing wrong with that,

    Patience is a virtue.

  • martinl (unregistered)

    Well, keeping the users in awe and fear of the automagic application is always more important than the correctness of the "facts". ;-)

  • IpNextGen (unregistered)

    Nway.. if you had turned off the monitor before the computer..  the NOISE on those old tandys was remembering you that the Computer was still ON!

    Mostly idiots think people are more idiot then them.

  • YodaYid (unregistered)

    Hey - EditPlus :-)

    I always scratch my head when I see something like this - someone actually took the time to write that sentence, so something must have been going through their heads...

    --YY

  • jayh (unregistered) in reply to IpNextGen

    regarding the monitor note, there was a belief (don't know if it was actually well founded) that the voltage spike of the monitor shutting down would mess the computer. Of course there is a lot of ill founded beliefs floating around (auto maintenance, gardening, etc) that turns out to be fully bogus.

  • Kemp (unregistered) in reply to YodaYid

    I believe last time round someone mentioned that the reason for the "don't turn off computer before monitor" warning was that the sync hardware in the monitors relied on there being a signal from the computer and it had a tendency to go crazy and fry itself in the absence of said signal.

    Captcha = captcha (self-referential tests these days?)

  • Kemp (unregistered) in reply to Kemp

    Hmmm... killed my own point, it's the other way round. Either way, those monitors existed somewhere, so someone must have once had the inverse sign to you.

     

    Captcha = perfection (correcting myself...)

  • Nick (unregistered)

    I'm not sure this is really a WTF.

    Maybe he wanted to make sure that the user didn't navigate away from the underlying page that while they're uploading a large PDF file? Not the best solution, but maybe his line of thinking was that, by throwing up an authoritative-sounding message, the user would leave their Web browser alone.

  • (cs)

    So wait two seconds to close, regardless of errors or transmission delays.

    Use window.top.close(), which I'm a little suspicious of (and it's not like you can do something simpler, like...oh, say.... self.close)

    Insert 52 non-breaking spaces within <p> tags because... well, just because.

    Top it off with a message that is a complete lie.

     

    Maybe this was another case where the fax was being sent so fast that the user couldn't see it, and therefore complained that it couldn't possibly be working right. There was a WTF like that a little while back. Solution is to make a useless window open up that waits an arbitrary and unnecessary amount of time just to give the user that warm fuzzy feeling that the computer did its job.

  • Jonathan (unregistered)

    Perhaps in a previous version some users were expecting the fax to appear instantly on the fax machine, and were complaining about the delay.

    So to take into account the time taken to queue the fax, dial/redial, send and print it, this arbitary page with delay was put in to make it appear that something was happening!

  • Bluemoon (unregistered)

    What is with all those non-breakable spaces, are they just filling up space, is it an extention of the wait, or to create a big enough window ?

    The page is not generated with an WYSIWYG-editor (who generaly generates lots of non-breakabel spaces) because such an editor would have used the same capitals in < H1 > as in the tag < /h1 >

  • (cs)

    I actually do not consider this to be much of a WTF at all.  Considering how some users are, you have to spell out the obvious sometimes.

  • (cs)

    What if Javascript is not enabled?

    There should be a set of "noscript" tags instructing the user to wait PRECISELY 2 SECONDS before closing the window.

    That might distract them long enough to forget that the fax is slow!

  • (cs) in reply to twks

    twks:
    I actually do not consider this to be much of a WTF at all.  Considering how some users are, you have to spell out the obvious sometimes.

    Could you explain to me what is "the obvious"??

     

     

    *sarcasm intended

  • (cs)
    Jake Vinson:

    I love instructions that have absolutely no purpose. I remember back in high school, for the old Tandy 8088 in the library, the Instructions For Use sheet had, in big bold letters, YOU MUST TURN OFF THE COMPUTER BEFORE TURNING OFF THE MONITOR.



    I don't know about Tandys, but I have an old Amstrad that recieves it's power through the monitor, so turning off the monitor will cut the power to the computer. Turning off the computer first is a good thing to do in that case.
  • me (unregistered) in reply to jayh
    jayh wrote the following post at 06-29-2006 11:46 AM:

    regarding the monitor note, there was a belief (don't know if it was actually well founded) that the voltage spike of the monitor shutting down would mess the computer. Of course there is a lot of ill founded beliefs floating around (auto maintenance, gardening, etc) that turns out to be fully bogus.
    ----------

    I actually broke one harddisk when I put monitor on while my old trusty 486 was booting.. not 100% sure, but that tick-tick-sound started just at the same moment when that power spike came which comes when CRT-monitor is powered. Before that I didn't believe in that power spike and still I doubt it but it was so exact...

  • (cs) in reply to Manni
    Manni:

    Use window.top.close(), which I'm a little suspicious of (and it's not like you can do something simpler, like...oh, say.... self.close)

    According to the MSDN, those two are not in fact the same. window.top, iirc, selects the oldest browser window in the opening hierarchy. Thus, this actually closed something else.

  • (cs)

    My theory is that this output is made by a CGI script... which spits out that output, and then sends the fax.

    The author probably believed that the user's closing the window would stop the script execution.

    Under this logic, this page would have had some actual purpose. Of course, this logic is WRONG... but my point is that there is some possible, imaginable universe in which this page is not completely pointless.

  • (cs)
    Jake Vinson:

    I love instructions that have absolutely no purpose. I remember back in high school, for the old Tandy 8088 in the library, the Instructions For Use sheet had, in big bold letters, YOU MUST TURN OFF THE COMPUTER BEFORE TURNING OFF THE MONITOR.



    This was a common procedure for most computers back in the 80's. If you turned off the monitor first, you might generate electrical noise from the monitors input lines to the computer, this could actually destroy some of the electronics inside the computer.
    This was crucial the other way around too. My first computer was also fitted with an 8088 ( with math processor and turbo...). It's instruction manual told me that I should turn on the monitor before I turned on the computer.
  • (cs)

    What about something like:
    <font face="Courier New"><font color="#800080">try</font>{
    </font><font face="Courier New">    <font color="#800080">while</font>(stillFaxing()){
            out.print("&nbsp;");
            <font color="#0000ff">Thread</font>.sleep(200);
        }
    }<font color="#800080">catch</font>(<font color="#0000ff">IOException </font>e){
        stopFaxing();
    }
    </font>

  • Alan (unregistered) in reply to Kemp

    That's true - it was IBM Monochrome monitors. We used to have lots (way back when), but they all died for exactly this reason.

  • (cs) in reply to mallard
    mallard:
    Jake Vinson:

    I love instructions that have absolutely no purpose. I remember back in high school, for the old Tandy 8088 in the library, the Instructions For Use sheet had, in big bold letters, YOU MUST TURN OFF THE COMPUTER BEFORE TURNING OFF THE MONITOR.



    I don't know about Tandys, but I have an old Amstrad that recieves it's power through the monitor, so turning off the monitor will cut the power to the computer. Turning off the computer first is a good thing to do in that case.


    Would that happen to be an Amstrad PC6400? 8086, 640k of ram, dual floppies and the best part: it took 4 AA batteries to power the hungry realtime clock!
  • Borsi (unregistered) in reply to Sindri

    Well, this is a very reasonable explanation :)

  • mastmaker (unregistered)
    Jake Vinson:

    I love instructions that have absolutely no purpose. I remember back in high school, for the old Tandy 8088 in the library, the Instructions For Use sheet had, in big bold letters, YOU MUST TURN OFF THE COMPUTER BEFORE TURNING OFF THE MONITOR.

     

    The reverse is true in my case. YOU MUST turn on the monitor BEFORE the computer boots up. If you don't, you get a horrible instant-headache-giving amount of  flickering. Absolutely no flicker if you follow the above rule. For the record, I have a HP Athlon64x2 machine with a 4 year old CRT monitor.

  • (cs) in reply to Volmarias
    Volmarias:
    Manni:

    Use window.top.close(), which I'm a little suspicious of (and it's not like you can do something simpler, like...oh, say.... self.close)

    According to the MSDN, those two are not in fact the same. window.top, iirc, selects the oldest browser window in the opening hierarchy. Thus, this actually closed something else.

    Why would this window display a message saying it will close automatically, and then attempt to close something else?

    Oh wait, we're at The Daily WTF. If it made sense, it wouldn't be here.

  • AC (unregistered) in reply to Sindri

    Really, there's no WTF here. The posts that talk about looping to keep the connection alive while sending the FAX got it right (and thus the reason for all the non-breaking spaces).

    We had to do that constantly at a previous job during a job that sent a lot of e-mails, or else the batch would be killed when the browser decided to timeout the connection.

  • (cs) in reply to AC

    The page is too uninformative, this would work better:

    "IF YOU DO ANYTHING WITH THIS WINDOW YOUR FAX IS DOOMED! IF YOU EVEN THINK ABOUT MOVING YOUR MOUSE YOUR FAX IS DOOMED! DOOMED I SAY!!!"

  • muffiny (unregistered) in reply to Jeremy D. Pavleck
    Jeremy D. Pavleck:

    Would that happen to be an Amstrad PC6400? 8086, 640k of ram, dual floppies and the best part: it took 4 AA batteries to power the hungry realtime clock!


    Probably a CPC 464, 664 or 6128. Those were great machines. It was the beginning of the end for Amstrad when they decided to go 8086. So sad.
  • (cs)
    Jake Vinson:

    ... because if you do, the DoNothing subroutine will fire! And don't even think about closing this web page (from Phil Harvey) ... it could cancel your fax transmission!

    I love instructions that have absolutely no purpose.

    Well, the instructions may be incomplete (it really should be "This window will close automatically upon succesful or unsuccesful completion") but it's probably not wrong.

    Consider that the web app probably goes through the following steps, <font color="#ff0000">all in a single thread</font>:

    1) Receive user input, parse user input

    2) Open FAX device (TAPI?) via library/windows api

    <font color="#ff0000">3) Transmit the fax</font>

    4) exit the script.


    Now, I'm pretty sure that, at least in the default configuration, scripts are terminated when then client closes the connection. That means that when the user closes the browser window, the script may be in the middle of sending the fax (and knowing the analog nature of that, it may take a good minute). Since the developer couldn't figure out how to configure the web container to not kill the script when that happens, he just created a warning to keep try to keep the connection open (and the script running) long enough for it to complete.



    So the warning message is absolutely correct. The problem is that there isn't a fax spooler that the data can be left with, which would then work off the list of fax requests. I'm sure that when TWO users tried to send a fax simultaneously, the second one would receive some kind of error, as the fax device would already be in use. But wait, that would require proper error handling on part of the developer. It would probably just die silently with the 'success' message.



    OT: I've seen a PHP script that operated a scanner via SANE, scanned in an image, and then ran OCR over the acquired image. It was just as multi-user capable as this, but at least it didn't have a warning message. Probably only because it was open source, without a manager to 'fix' the wtf with a nice message.

  • (cs) in reply to AC
    Anonymous:
    Really, there's no WTF here. The posts that talk about looping to keep the connection alive while sending the FAX got it right (and thus the reason for all the non-breaking spaces).

    We had to do that constantly at a previous job during a job that sent a lot of e-mails, or else the batch would be killed when the browser decided to timeout the connection.


    This is why PHP has the ignore_user_abort() function
  • Anthony Ettinger (unregistered) in reply to merreborn

    it's always good to make sure.

  • Reed (unregistered)
    Anonymous:

    Maybe has been generated by pseudocode alike this one:

    foreach( $departaments as $depfax ){
      /* flush some data to keep conexion alive */
       echo "&nbsp;";
       flush();
    ...


    This is a pretty plausible explanation!


    My explanation was going to be this:  The designer/manager wanted closing the window to cancel sending the fax. The programmer decided it was too hard to make the web page cancel something that the server had already done before sending the page, so he just faked it.

  • (cs)
    Jake Vinson:

    ... because if you do, the DoNothing subroutine will fire! And don't even think about closing this web page (from Phil Harvey) ... it could cancel your fax transmission!

    [image]

    Actually, this could work exactly as advertised. If the underlying CGI script that's sending the fax is spitting out those non-breaking spaces at a fixed rate while it sends the fax, the window will close two seconds after the fax is finished. If there's an error, the script will send out an error message rather than the window.top.close() javascript. Closing the window will break the TCP connection, sending a signal to the underlying CGI script to stop the fax.

    The only WTF here is the use of window.top.close() rather than self.close(), and it's a very minor one.

  • (cs)
    Jake Vinson:

    ... because if you do, the DoNothing subroutine will fire! And don't even think about closing this web page (from Phil Harvey) ... it could cancel your fax transmission!


    <FONT face=Tahoma>At least it would be easy to "enhance" the application if users decided that the fax process is taking too much time...



    </FONT>

  • SliceX (unregistered) in reply to jayh

    <FONT face=Verdana>Another slighty more modern take is that the computer would frequently hang on shutdown (happened a lot during the Win9x era). Perhaps the poster of the note intened that users leave the monitor on long enough to verify that the system actually powered itself off or halted.</FONT>

  • SilverDirk (unregistered)

    But this was supposed to be a classic... and now both parts of it have been justified? bah. ruined my day.

    least we learned something

  • Ryan (unregistered)

    There's actually one story I've heard of where a monitor can be destroyed without signal.  :)  Some ancient monitor designs directly connected the sync detection circuitry to the line transformer; without a proper sync pattern, you'd be passing plain old DC current through the transformer, burning it out in short order.

    Of course, the cautionary sign there would be to turn off the monitor first :P

    I seem to remember hearing this story attached to a statement that viruses could not make modern monitors explode, and were limited to trashing your hard drive (and flashing the firmware on your BIOS if you're unlucky).  As it happens, the captcha today is hacker ;p

  • (cs)
  • (cs) in reply to Richard Cutts
    Anonymous:

    Ha

     

    Nothing wrong with that,

    Patience is a virtue.



    yeah maybe when they don't display that, customers will complain that their fax isn't send, because this is way too fast.
  • jsut curious (unregistered) in reply to Manni
    Manni:

    So wait two seconds to close, regardless of errors or transmission delays.

    Use window.top.close(), which I'm a little suspicious of (and it's not like you can do something simpler, like...oh, say.... self.close)

    Isn't this a race condition? If the javascript starts to interpret the window.top.close() at the exact instant you manually close the window, but before the javascript is halted, won't the browser close the next 'top' window? What's the rule?

  • (cs) in reply to Carnildo
    Carnildo:
    Jake Vinson:

    ... because if you do, the DoNothing subroutine will fire! And don't even think about closing this web page (from Phil Harvey) ... it could cancel your fax transmission!


    Actually, this could work exactly as advertised. If the underlying CGI script that's sending the fax is spitting out those non-breaking spaces at a fixed rate while it sends the fax, the window will close two seconds after the fax is finished. If there's an error, the script will send out an error message rather than the window.top.close() javascript. Closing the window will break the TCP connection, sending a signal to the underlying CGI script to stop the fax.


    OMG this is sarcasm? I hope! So if my connection blows the fax isn't send? But how will I know?
    Does your mailman keep a ongoing connection with you if you post a letter? My mailman doesn't but that maybe because I have  bad breath...
  • Puma (unregistered)

    This is not a WTF.

    The non-breaking spaces are being sent to the client to keep the connection alive while the fax sends from a script running synchronously on the server. When the script completes it sends the javascript to the browser signaling it to close.

    Closing the window would kill the script and stop the fax.

    It's not an elegant solution but it's no WTF.

    It's a WTF that this made it on here.

  • Puma (unregistered) in reply to zamies
    zamies:
    Carnildo:
    Jake Vinson:

    ... because if you do, the DoNothing subroutine will fire! And don't even think about closing this web page (from Phil Harvey) ... it could cancel your fax transmission!


    Actually, this could work exactly as advertised. If the underlying CGI script that's sending the fax is spitting out those non-breaking spaces at a fixed rate while it sends the fax, the window will close two seconds after the fax is finished. If there's an error, the script will send out an error message rather than the window.top.close() javascript. Closing the window will break the TCP connection, sending a signal to the underlying CGI script to stop the fax.


    OMG this is sarcasm? I hope! So if my connection blows the fax isn't send? But how will I know?
    Does your mailman keep a ongoing connection with you if you post a letter? My mailman doesn't but that maybe because I have  bad breath...


    Although it's not an elegant solution, it's a common one. Btw, if your connection just died, then your browser would never send a cancel notice to the server and the fax would still send.
  • Dazed (unregistered) in reply to AC
    Anonymous:
    Really, there's no WTF here. The posts that talk about looping to keep the connection alive while sending the FAX got it right (and thus the reason for all the non-breaking spaces).

    We had to do that constantly at a previous job during a job that sent a lot of e-mails, or else the batch would be killed when the browser decided to timeout the connection.

    Good grief! You think that a set-up where closing the browser window kills the fax is NOT a WTF?? Why in heavens name don't you just pass the fax to a server process which sends the fax in a sane and reliable fashion, creating a record of the transmission which the sender can check at his leisure. Ditto any process which potentially takes a long time. Ditto with emphasis for any process which may involve retries.

    I look forward to the submissions here from one of your successors.

  • Tim (unregistered) in reply to YodaYid

    I've actually seen this a lot where there used to be an activex control, that was ripped out because it didn't work or for browser compatability. The code gets ripped out, but the dialog remains, either through laziness, or because if the user waits that long and starts navigating again, experience says that things will be mostly ok. It's not great, but sometimes you've gotta make users wait so they don't ask difficult to answer questions.

  • Puma (unregistered) in reply to Dazed
    Anonymous:
    Anonymous:
    Really, there's no WTF here. The posts that talk about looping to keep the connection alive while sending the FAX got it right (and thus the reason for all the non-breaking spaces).

    We had to do that constantly at a previous job during a job that sent a lot of e-mails, or else the batch would be killed when the browser decided to timeout the connection.

    Good grief! You think that a set-up where closing the browser window kills the fax is NOT a WTF?? Why in heavens name don't you just pass the fax to a server process which sends the fax in a sane and reliable fashion, creating a record of the transmission which the sender can check at his leisure. Ditto any process which potentially takes a long time. Ditto with emphasis for any process which may involve retries.

    I look forward to the submissions here from one of your successors.



    Two reasons: Time and Money.

    Again, it's not the best solution, but it's a common one with a long running server side script. Sure, they could create a server process to accept, spool, and send faxes (complete with logging and auditing); but then again, this is The Daily WTF, not The Daily Could've Been Better.

  • privateer (unregistered)

    What about a cgi spitting nbsps during some processing and then, after successful operation spitting the window.top.close() as said above?

    Then on an error it would spit "There was an error ..." etc. and notify the user immediately.

    This does not mean that the warning serves any purpose or is correct though


  • (cs)

    Is this the wrong time to mention that I'm in love with the chick playing foosball in the sponsored ad up yonder?

  • Puma (unregistered) in reply to privateer
    Anonymous:
    What about a cgi spitting nbsps during some processing and then, after successful operation spitting the window.top.close() as said above?

    Then on an error it would spit "There was an error ..." etc. and notify the user immediately.

    This does not mean that the warning serves any purpose or is correct though




    That is probably the most likely explination, since it explains 1) the warning, 2) the non-breaking spaces, and 3) the script at the bottom of the page.
  • Winston Ewert (unregistered)
    1. The page continues to pump out data as the script is running sending the end of page only after everything is done.

Leave a comment on “Classic WTF - Whatever you do, don't click that button ...”

Log In or post as a guest

Replying to comment #79804:

« Return to Article