Write me an error message



  • Okay, this is going to be an odd little challenge. I have a browser-based application that needs to set its window to a specific size when it first starts up. This works fine. However, I've just tripped over an interesting misfeature of IE that was apparently introduced in XP SP2-- if the user is holding down a mouse button while Javascript is attempting to execute either the resizeTo() or moveTo() methods of the Window object, the method call fails with an "access denied" error. Grrrr. This behavior is detailed here:

    http://support.microsoft.com/kb/904947

    Well this sucks, but at least I can work around it by wrapping the resizeTo/moveTo calls in a try/catch block and keep retrying until it works. My first attempt was a do/while loop that repeated infinitely until success, but that tended to lock up IE for reasons that aren't entirely clear. My second attempt involved placing an alert() statement in the catch block. This works great, as the user is forced to release their mouse button to dismiss the dialog, thus freeing the script to do its business.

    So my question to you all is this-- what the heck should the alert dialog say?




     



  • "Please read the article at http://support.microsoft.com/kb/904947 to learn more about why you need to see this dialog."



  • Genuine Microsoft Windows installation detected.

    Proceeding in Windows Enhanced Mode.



  • Ahh, excellent. Way better than the "You just won a free X-Box 360!" I was planning on using.



  • @Zylon said:

    Okay, this is going to be an odd little challenge. I have a browser-based application that needs to set its window to a specific size when it first starts up. This works fine. However, I've just tripped over an interesting misfeature of IE that was apparently introduced in XP SP2-- if the user is holding down a mouse button while Javascript is attempting to execute either the resizeTo() or moveTo() methods of the Window object, the method call fails with an "access denied" error. Grrrr. This behavior is detailed here:

    http://support.microsoft.com/kb/904947

    Well this sucks, but at least I can work around it by wrapping the resizeTo/moveTo calls in a try/catch block and keep retrying until it works. My first attempt was a do/while loop that repeated infinitely until success, but that tended to lock up IE for reasons that aren't entirely clear. My second attempt involved placing an alert() statement in the catch block. This works great, as the user is forced to release their mouse button to dismiss the dialog, thus freeing the script to do its business.

    So my question to you all is this-- what the heck should the alert dialog say?

    Javascript is single-threaded, and thus ties up resources until the code has finished executing.  The thread will block the UI update thread, this is most likely the 'lock-up' you are experiencing.  (Note that IE should eventually prompt you to kill the thread if you leave it up long enough)

    There is at least one way around it so you do not have to include a pop-up.

    Instead of implementing a do/while loop, do something like this  (pseudo-code):

    function myResizeFunction() {
      try {
        window.resizeTo(...);
        window.resized = true;
      } catch (e) { }

      if (!window.resized)
        window.setTimeout("myResizeFunction", 1);
    }



  • @djork said:

    "Please read the article at http://support.microsoft.com/kb/904947 to learn more about why you need to see this dialog."

     

    Nice. 



  • @Zylon said:

    However, I've just tripped over an interesting misfeature of IE that was apparently introduced in XP SP2-- if the user is holding down a mouse button while Javascript is attempting to execute either the resizeTo() or moveTo() methods of the Window object, the method call fails with an "access denied" error.

    Excuse me while I giggle helplessly. As bizarre misfeatures go, this one is really impressive.



  • @RaspenJho said:

    There is at least one way around it so you do not have to include a pop-up.

    Instead of implementing a do/while loop, do something like this  (pseudo-code):

    function myResizeFunction() {
      try {
        window.resizeTo(...);
        window.resized = true;
      } catch (e) { }

      if (!window.resized)
        window.setTimeout("myResizeFunction", 1);
    }

    Yeah, something like that would have been preferrable. Unfortunately, there's a bit of ugliness I run at initialization that needs the resize calls to execute synchronously. This browser-based app (I'm stressing this part because I'd never do something like this with a normal web page) needs to fit the browser window precisely to its content. Unfortunately, the major browsers offer no way to specify the size of the client area. You can only resize the window, which will leave you with lord-only-knows how much room after all the UI cruft is taken into account. The hackish workaround to this is to set the window size, then retrieve the client size, then resize the window again based on the difference.

    Of course it would be possible to accomplish this asynchronously, but it would take more refactoring than I have the time for right now. 



  • @asuffield said:

    Excuse me while I giggle helplessly. As bizarre misfeatures go, this one is really impressive.

    Isn't it though? The best part is that since it throws an exception instead of just failing silently, it kills Javascript execution entirely. Since this app needs to maintain constant contact with an LMS, this is a Very Bad Thing.

     



  • @Zylon said:

    @RaspenJho said:
    There is at least one way around it so you do not have to include a pop-up.

    Instead of implementing a do/while loop, do something like this  (pseudo-code):

    function myResizeFunction() {
      try {
        window.resizeTo(...);
        window.resized = true;
      } catch (e) { }

      if (!window.resized)
        window.setTimeout("myResizeFunction", 1);
    }

    Yeah, something like that would have been preferrable. Unfortunately, there's a bit of ugliness I run at initialization that needs the resize calls to execute synchronously. This browser-based app (I'm stressing this part because I'd never do something like this with a normal web page) needs to fit the browser window precisely to its content. Unfortunately, the major browsers offer no way to specify the size of the client area. You can only resize the window, which will leave you with lord-only-knows how much room after all the UI cruft is taken into account. The hackish workaround to this is to set the window size, then retrieve the client size, then resize the window again based on the difference.

    Of course it would be possible to accomplish this asynchronously, but it would take more refactoring than I have the time for right now. 

    Couldn't you load a different page first that does your screen measurements and resizing, then redirect to your crazy-initialization page?

     



  • I don't want to question your design (you don'tsound as if you had any guilt anyway) but how is this thing supposed to work if the browser is maximized?

    Did you try using a popup or one of IE's fancy "web page dialogs"? I think those give you much more control over the window size and if you open them inside a button click handler (as opposed to timeout and onload handlers) you shouldn't have many problems with popup blockers either.
     



  • I hate web sites that want to change my browser window - especially when the site is in just one of many tabs. Fortunately, my browser ignores scripts that try to do that (Firefox/Tools/Options/JavaScript/Advanced/Allow scripts to move or resize windows-->NO) 



  • @PSWorx said:

    I don't want to question your design (you don'tsound as if you had any guilt anyway) but how is this thing supposed to work if the browser is maximized?

    It's launched as a popup by a learning management system. It still works if the window somehow ends up the wrong size, the user is just left with ugly black space below and to the right of the layout. And no, I won't use any proprietary IE crap. Contractually we're allowed to state "IE-only", but I make sure everything at least works under Firefox as well.

     
    JvdL, I appreciate that you're a very special snowflake who knows how to click checkboxes, but I've already stressed that this isn't a web site. It's courseware that happens to run via a browser window. In any case, we're hoping to transition to an all-Flash interface eventually which will just scale the whole thing to whatever size the window is.
     



  • If you're already using a popup, your problem should be pretty easy to solve. Just specify your desired width and height as options in the third parameter of window.open(), possibly also add resizeable=no lock the popup into this size:

    var myPop = window.open("<url>", "", "width=<desired width>, height=<desired height>, location=no, menubar=no, toolbar=no, resizeable=no");

    From what I know, the window is resized before anything is loaded, so your init routine shouldn't make problems.

    Wouldn't it be easier though, to put the whole app page into a fixed size table/div and center that on the screen bypassing the whole resize stuff? 



  • If it's a windows application, you could use the IE webbrowser control...

    Just google it, there's about a gazillion more examples.



  • @Zylon said:

    @PSWorx said:

    I don't want to question your design (you don'tsound as if you had any guilt anyway) but how is this thing supposed to work if the browser is maximized?

    It's launched as a popup by a learning management system. It still works if the window somehow ends up the wrong size, the user is just left with ugly black space below and to the right of the layout. And no, I won't use any proprietary IE crap. Contractually we're allowed to state "IE-only", but I make sure everything at least works under Firefox as well.

     
    JvdL, I appreciate that you're a very special snowflake who knows how to click checkboxes, but I've already stressed that this isn't a web site. It's courseware that happens to run via a browser window. In any case, we're hoping to transition to an all-Flash interface eventually which will just scale the whole thing to whatever size the window is.
     

    It runs in a browser "window", but it's not a website? What do you mean by a "browser window"? Do you mean a browser control in a windows application?  Or in an actual browser, like IE or Firefox?  You mentioned Firefox so I assume it does run in a browser, but then you said it's not a "website", so now I am confused (easily accomplished, of course).  Or are you trying to say it is not a website but a web application ?  If so, there's really no difference as far as the client-side browser code is concerned.

    If you are hosting a "browser window" in a control, then all of your window sizing should be done via the application that hosts the control, not via javascript. 



  • It sounds to me like he's shelling to the web browser by launching a URL somehow.



  • @PSWorx said:

    If you're already using a popup, your problem should be pretty easy to solve. Just specify your desired width and height as options in the third parameter of window.open(), possibly also add resizeable=no lock the popup into this size:

    var myPop = window.open("<url>", "", "width=<desired width>, height=<desired height>, location=no, menubar=no, toolbar=no, resizeable=no");

    From what I know, the window is resized before anything is loaded, so your init routine shouldn't make problems.

    Wouldn't it be easier though, to put the whole app page into a fixed size table/div and center that on the screen bypassing the whole resize stuff? 

    The width and height parameters specify the size of the window, not the client area. The resultant client area is, for all practical purposes, unpredictable, due to the variance in chrome overhead between browsers and even themes. Also (and this is what prompted me to add this code in the first place), a new security feature of IE7 is that it will permanently jam a warning bar at the top of the screen under certain conditions, further shrinking the client area.

    Everyone else, when I say this isn't a web page, I'm just speaking metaphorically. The client side is nothing more complex than HTML, CSS, Javascript, and some Flash movies. What I mean is that this page is not sitting on the internet for anyone to see. It's using the web browser to deliver a CBT "application" to a very specific internal audience. As such, we've gone to great lengths to give it a consistent, application-esque appearance. At the same time, I've endeavored to keep the whole thing cross-platform compliant. None of this Windows-specific twaddle some of you seem so enamored of.



  • You can remove the IE7 address bar if your host is in the trusted sites zone.



  • True. But I prefer solutions that don't require users to mess around with their configuration settings.

    Don't all good developers? 



  • @Zylon said:

    True. But I prefer solutions that don't require users to mess around with their configuration settings.

    Don't all good developers? 

    You could make your installer mess with the user's configuration settings. That always works well. 



  • bangs head on desk

    It's launched from a link on a learning management system. There is no installer.
     



  • I agree. You don't seriously want to tamper with the users security settings to hide a f*ing ugly gray border, do you?



  • That totally depends on the application.  If your users are limited to internal users, and your "web" application is really an "intranet" application, then by all means you should have yourself added to the trusted zone. 

    If you are hosting on the internet then this, of course, does not apply.

    All in all, it depends who your users are.



  • @PSWorx said:

    I agree. You don't seriously want to tamper with the users security settings to hide a f*ing ugly gray border, do you?

    You people suck at sarcasm. 



  • @asuffield said:

    @PSWorx said:

    I agree. You don't seriously want to tamper with the users security settings to hide a f*ing ugly gray border, do you?

    You people suck at sarcasm. 

     damn. and i thought I'd be better... my apologies...
     


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.