• UTU (unregistered) in reply to Puma
    Anonymous:
    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.


    Actually... if the connection died, and the server attempted to write to the socket, it'd suffer massive collapse if/when it doesn't handle the "when I started the conversation there was someone here but now he's gone"-exception that gets raised.

    Cpatcha: wtf... promising :-p
  • foonly (unregistered) in reply to Raven
    Raven:
    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.


    Speaking as an LE here ('Lectrical Engineer), any electrical noise from the monitor that can kill the electronics with the power on can just as easily kill it with the power off.  There is no isolation provided to the monitor connector when turning off the power.

    The opposite is not true. Turning off the computer cuts the sync to the monitor.  Modern monitors suppress the output when sync goes away.  Old monitors burn a spot in the phospher.  The sign was backwards.
  • (cs) in reply to foonly
    Anonymous:
    The sign was backwards.


    Then how could he read it, smart guy?
  • Tei (unregistered) in reply to UTU

    HTTP its stateless and not designed for permanent conections.

    This can be solved by a Producer - Consumer pair.

    Producer: the webpage, that send fax objects to the server with ajax.
    Consumer: recive fax object, stack objects, and execute (retire) objects.

    The ajax webpage can poll the server asking for object termination. IsMyFaxStillOnTheQueue?.

    I dont like polling, but I dont think a webpage can receive push data randomly, because If the client close the webpage, theres no way the server can reopen a "server"->"client" communitacion.

    HTTP is crap, but for polling seems decently designed, theres the HEAD request, and some errorlevel codes for "not changed data".

    But coding this feature this way can be a WTF, because a simpler approach (the published on this thread) will work well, so you dont need that big, complex and formal architecture.  I love good code, but the customer will not love features that only a programmer will see.

  • (cs)
    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!

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



    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.



    The page may not be dynamic, but as the poster stated, there could be interesting server-side stuff going on. Remember, not all the content in a HTTP response has to be sent at once, and the length of the content doesn't have to be known, so you could probably send one   every 2 seconds forever if you flushed everything correctly. (Incidentally, one of the more interesting things I've come across is a service to allow you to monitor how often and for how log someone reads an e-mail you've sent. It involves embedding an image from a webserver, and the server keeps the connection open. When the person finishes reading the e-mail, the connection is cut off, and this allows it to determine how log the receiving party had the message open for.)

    Of course, it's far more likely the nbsp's were some weird trick to do with page width or something...

  • noname (unregistered) in reply to jsut curious
    Anonymous:
    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?



    Nope, JavaScript is single threaded and run in the same thread that manages the event queue.



    You think all the web monkeys out there could manage to do anything at all if they had to worry about race conditions and what not?

  • Anonymous (unregistered) in reply to John Bigboote

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

     

    Wrong to say that you fall in love with women that you've never spoken to, and have only seen in a 150 or so pixel image?  Hell, you can't even see her ass, it could be huge for all you know, or maybe she is not a very nice person, or she may have crabs.  Maybe you should not fall in love so easy. 

  • (cs) in reply to makomk

    So, all that was needed to turn this from a WTF to a WTC (Wow, That's Cool (tm)) would be to replace those  s with CSS-pretified progress bar segments.

  • Scrub (unregistered) in reply to robbak

    IIRC window.top refers to the top frame in a window

    And normally cutting the TCP connection would not halt the execution of a script unless the script tries to write something to the client and receives a "broken pipe" exception or something similar.

  • (cs)
    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!

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


    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.


    Amen to that.
  • anonymous (unregistered)

    Could we get clarification from the submitter as to whether this is a popup, and whether this (and its parent if any was html, php, or something else?

      If it is, then the parent page might have something that will check, and explicitly send a command to cancel the fax when the popup is closed.  A lot of times, people will hit send, and a second or two later (often as message xyz sent scrolls across the screen)  realize they didn't want to send that  or not to thatother address and cancel it.  That means the designers might program in something  that would let people cancel and there's no need to put the code for that in the popup.



  • (cs) in reply to anonymous
    Anonymous:
    Could we get clarification from the submitter as to whether this is a popup, and whether this (and its parent if any was html, php, or something else?

      If it is, then the parent page might have something that will check, and explicitly send a command to cancel the fax when the popup is closed.  A lot of times, people will hit send, and a second or two later (often as message xyz sent scrolls across the screen)  realize they didn't want to send that  or not to thatother address and cancel it.  That means the designers might program in something  that would let people cancel and there's no need to put the code for that in the popup.





    Jesus but that way of implementing this kind of service is the WTF.
    You shouldn't implement it in this way, and you shouldn't annoy people with non-sensical messages.
  • Joe Bloggs (unregistered) in reply to Anonymous
    Anonymous:

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

     Wrong to say that you fall in love with women that you've never spoken to, and have only seen in a 150 or so pixel image?  Hell, you can't even see her ass, it could be huge for all you know, or maybe she is not a very nice person, or she may have crabs.  Maybe you should not fall in love so easy. 



    Pixelated love is much easier then the possibility of being royally trounced by such an avid foosball player.  Note well the wooden table in the image, which seems to be required..

    captcha == bruichladdich^Wwhiskey
  • random passer-by (unregistered)

    No, that would only work if the page is static HTML. The explanations presume a CGI script, which is constantly writing to the page while processing on the server's end. Thus, the stream of   to keep the connection alive, and the final setTimeout to complete it once processing's done. Closing it before processing is done would, in most cases, halt the script on the server, unless specifically set otherwise.

    This would explain it, whether it was opened in the same window or a separate one (as the script suggests).

  • jsut curious (unregistered) in reply to noname
    Anonymous:
    Anonymous:
    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?



    Nope, JavaScript is single threaded and run in the same thread that manages the event queue.

    You think all the web monkeys out there could manage to do anything at all if they had to worry about race conditions and what not?

    Perhaps, but based on this forum, it doesn't seem to stop them from trying...

  • Carl Carlson (unregistered)

    I have an ASP.NET web application which runs a long running proccess (about 3.5 minutes right now). As the process runs it returns data to the client indicating progress and estimated time remaining by just writing to the response stream. However, even if I call Response.Flush(), after each line, IE6 would not display any results until I had sent at least a few hundred bytes, so now i open with a few hundred (collapsable) spaces. However, I let anyone who would need to run this process know that closing thier browser window will not stop the request from running. (I just verified that fact while I typed this message). Though, naturally, if there IS an "I just closed my browser while receiving this document" signal sent to the server, a differently set-up webserver <emphasis>could</emphasis> terminate a running process. If anyone knows of such a webserver, I would be interested to see how it works. (I (obviously?) have never dealt with any CGI itself).

    Conclusion: If the webserver in question works similarly to IIS, then the spaces MIGHT not be a WTF but the rest of it pretty much is.

    Second Conclusion: IF this is a page generated during the faxing process like the one I described, then some of this is still a WTF. For example, the timeout+close could give the user time to see the "Your fax has completed" message...but there is no such message! So the behavior of the system could be "Emit an error, or script to close the window if completed with no error", which STILL makes the 2 second delay a bit of mild wtf-ery.

  • Rob Garrett (unregistered) in reply to Puma
    Anonymous:
    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.


    You just gotta love the anonymous posters....

    "Time and Money" - if ever there was a bad excuse for bad software it is this one.  Has no one taught you that well engineered saves time and money in the long run because of reduced maintenance costs and less time dealing with customer complaints?  Guess not.

  • frustrated slave (unregistered) in reply to Rob Garrett

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


    You just gotta love the anonymous posters....

    "Time and Money" - if ever there was a bad excuse for bad software it is this one.  Has no one taught you that well engineered saves time and money in the long run because of reduced maintenance costs and less time dealing with customer complaints?  Guess not.

    Sometimes the engineers know better, but are forced to do it the quick-n-dirty way by short sighted managers who can't think further than the-issue-in-front-of-them into the future. I am, unfortunately, one of those engineers; however, I always at least put in a flagrantly obvious comment explaining the hack, why it was done, what is likely to go wrong, how and why, and what the correct solution should have been, so whoever gets stuck supporting it at least has a fighting chance...

    captcha = hacker - how apropos...

     

  • (cs) in reply to Joe Bloggs
    Anonymous:
    Anonymous:

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

     Wrong to say that you fall in love with women that you've never spoken to, and have only seen in a 150 or so pixel image?  Hell, you can't even see her ass, it could be huge for all you know, or maybe she is not a very nice person, or she may have crabs.  Maybe you should not fall in love so easy. 



    Pixelated love is much easier then the possibility of being royally trounced by such an avid foosball player.  Note well the wooden table in the image, which seems to be required..

    captcha == bruichladdich^Wwhiskey


    Besides, there's no way she could have a big butt with the skinny little stick-figure wrists she has.
  • Worf (unregistered) in reply to mastmaker
    Anonymous:
    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.



    There is a simple fix. The cause is because Windows rediscovers the monitor everytime it boots. It's possible your monitor isn't ready to return the EDID data when Windows wants to query it, so Windows uses the "Generic Monitor" "driver" than the "driver" for your monitor. And Generic Display defaults to 60Hz because that's the only safe refresh rate (if the monitor doesn't support EDID data, it's probably old enough to be destroyed by out-of-spec signals). I suppose the strange thing is that Windows keeps using the same resolution...

    If you go to the Display control panel, you see what display is set. If it says "Generic Monitor", just change the refresh back to 85Hz or whatever you use. I suspect if you boot it "properly", it'll say your monitor rather than "Generic Monitor".

    Happens a lot with KVM switches because most switches don't emulate EDID. Just set everything right and you're good to go.

    (first captcha - "giggity" )
  • DanixDefcon5 (unregistered) in reply to RatDancr
    RatDancr:
    Anonymous:
    Anonymous:

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

     Wrong to say that you fall in love with women that you've never spoken to, and have only seen in a 150 or so pixel image?  Hell, you can't even see her ass, it could be huge for all you know, or maybe she is not a very nice person, or she may have crabs.  Maybe you should not fall in love so easy. 



    Pixelated love is much easier then the possibility of being royally trounced by such an avid foosball player.  Note well the wooden table in the image, which seems to be required..

    captcha == bruichladdich^Wwhiskey


    Besides, there's no way she could have a big butt with the skinny little stick-figure wrists she has.


    Maybe, but ...
    I.like(BigButts) && I.canDeny(false) !!!

    CAPTCHA: foxtrot. Interesting ....
  • Wartex (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)

    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.

     

    Page size has to be greater than 512 bytes otherwise IE displays error 404.

  • danskal (unregistered) in reply to frustrated slave

    I have the answer, and it's scarily simple - the guy who coded this isn't a web developer.  He has coded fat clients all his life, but because fat client gui's aren't fashionable, he is forced to pick up som html and make his code work with web pages.....

    .... so.... he copies his fat client app, strange instructions and all into a web app.  The message was perfectly correct before - he probably needed all the nbsp's to get his gridlayout to work too.  In the webified super trendy version, most of it is irrelevant, but do you think his project manager cares?

    And the testers/customers probably had test cases expecting it to work as before..... so everybody's happy.

    Except the poor codemonkey who has to maintain the undocumented code later....... been there :o( 

  • Dan W (unregistered) in reply to privateer

    If the fax is sent using a browser-embedded ActiveX control, then closing the window could abort the fax. When I was working with browser-based TWAIN, if you closed the browser before the scan was completely finished, the scan would happen on the hardware side but it wouldn't go anywhere.

    But if that's the case, the message should not say the fax is complete.

  • Dan W (unregistered)

    Yeah... Upon looking closer it looks like just a poor hack. He is probably using an ActiveX control that beings the send process as soon as the window is opened, all kinds of properties are set and what not.

    And the 2 second timeout is stupid, most controls expose events that you can subscribe to in JavaScript, so you can just close the window when the fax tells you it's done.

    This is why people deploy apps using Citrix.

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

Log In or post as a guest

Replying to comment #79867:

« Return to Article