Comment On Classic WTF - Whatever you do, don't click that button ...

Ha

 

Nothing wrong with that,

Patience is a virtue.

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

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.

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

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

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...)

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.

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.

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!

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 >

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.

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!

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

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.

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.

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.

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.

Maybe has been generated by pseudocode alike this one:



foreach( $departaments as $depfax ){

  /* flush some data to keep conexion alive */

   echo "&nbsp;";

   flush();



   /* extend page automatic termination */

   set_time_limit("2000");

 

   SendFax( $depfax, $faxtitle );

}



/* Add a artificial delay for when count($departaments) == 1 or 0, so users can actually SEE the OK message */

echo html("script","setTimeout('window.top.close();',2000);");



--Tei

What about something like:
try{
    while(stillFaxing()){
        out.print("&nbsp;");
        Thread.sleep(200);
    }
}catch(IOException e){
    stopFaxing();
}

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

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!

Well, this is a very reasonable explanation :)

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.

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.

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.

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!!!"

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.

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, all in a single thread:

1) Receive user input, parse user input

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

3) Transmit the fax

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.

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

it's always good to make *sure*.

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.

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.

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

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!

At least it would be easy to "enhance" the application if users decided that the fax process is taking too much time...

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.

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

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

MY FIN-GER ... IS-ON-DA-BUT-TON...

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.

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?

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...

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.

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.

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.

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.

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.

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.

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

Not to target you specifically, but yours was the last that I read, and I got fed up with these "explinations". We have to assume that this is the entirety of the HTML page that the user receives. So let us consider the two possible options that occur once the user selects to send a fax:

1) A new browser window pops up with this page. This is meant to be a distraction while the previous window (now in the background) opens a connection to the webserver to process the fax send request. In this instance, the nbsp's are completely pointless.
2) The request to send the fax was sent by the user in the browser window, and they receive this page back, within the same browser window. At this point, connections to the web server are static (in fact, should be closed since HTTP does not use persistant connections). All processing to send the fax on the client end will be completed, and on the server one of two options have happened: a new thread was spawned to process the send request which will be closed automatically when complete, and this page was sent back immediately, or the web server processed the the fax request compeltely and is done with it and has sent this back to the user. In either case, the nbsp's are still pointless, as well as the page as a whole. There is nothing in that page that allows it to be dynamic and prematurely closing it will have an effect on the send request.

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

Anonymous:

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.

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

Not to target you specifically, but yours was the last that I read, and I got fed up with these "explinations". We have to assume that this is the entirety of the HTML page that the user receives. So let us consider the two possible options that occur once the user selects to send a fax:

1) A new browser window pops up with this page. This is meant to be a distraction while the previous window (now in the background) opens a connection to the webserver to process the fax send request. In this instance, the nbsp's are completely pointless.
2) The request to send the fax was sent by the user in the browser window, and they receive this page back, within the same browser window. At this point, connections to the web server are static (in fact, should be closed since HTTP does not use persistant connections). All processing to send the fax on the client end will be completed, and on the server one of two options have happened: a new thread was spawned to process the send request which will be closed automatically when complete, and this page was sent back immediately, or the web server processed the the fax request compeltely and is done with it and has sent this back to the user. In either case, the nbsp's are still pointless, as well as the page as a whole. There is nothing in that page that allows it to be dynamic and prematurely closing it will have an effect on the send request.

3) Replace the non-breaking spaces with the following pseudo code:

StartSendingFax();

if (!FaxIsComplete)
{
    SendToBrowser(NonBreakingSpace);
}