Delay's Blog

Silverlight, WPF, Windows Phone, Web Platform, .NET, and more...

February, 2007

Posts
  • Delay's Blog

    Safely avoiding the "access denied" dialog [How to: Work around the access denied cross-domain IFRAME issue in the AJAX Control Toolkit]

    • 27 Comments

    Bertrand recently blogged "How to work around the access denied cross-domain frame issue in ASP.NET Ajax 1.0". Unfortunately, a similar issue exists in the AJAX Control Toolkit - with a similar workaround that's detailed in this post.

    Background: The AJAX Control Toolkit attempts to use as much of the ASP.NET AJAX infrastructure as possible in order to keep things simple and benefit from the established architecture of ASP.NET AJAX. However, the ASP.NET AJAX 1.0 implementation of Sys.UI.getLocation was not accurate for IFRAME content with certain page layouts in IE6 - one of which was used by the Toolkit test harness. We couldn't have our automated tests failing - and the ASP.NET AJAX team wasn't able to include a fix in their 1.0 release - so we needed to address this somehow. Since we had developed our own getLocation implementation that was accurate in IE6, we decided to route all Toolkit calls to getLocation through our own wrapper function - which used our improved implementation for IE6 and called through to the ASP.NET AJAX implementation for everything else. This works pretty well - except that our version suffers from the same cross-domain permissions issue that the ASP.NET AJAX version suffers from (please refer to Bertrand's post for more details).

    Fix: We've just checked in a fix to the Toolkit's Development branch to add the same try/catch wrapper that Bertrand suggests; this fix will be included with the next Toolkit release (in about a month). In the meantime, people who want the fix sooner are encouraged to apply the changes themselves. To do so, open AjaxControlToolkit.sln in Visual Studio, open the file AjaxControlToolkit\Common\Common.js, find the getLocation function, add the yellow, italic block below, and build the project to get a new AjaxControlToolkit.dll with the fix. The complete function definition with the fix applied is included here to make this as easy as possible:

    getLocation : function(element) {
        
    /// <summary>Gets the coordinates of a DOM element.</summary>
        /// <param name="element" domElement="true"/>
        /// <returns type="Sys.UI.Point">
        ///   A Point object with two fields, x and y, which contain the pixel coordinates of the element.
        /// </returns>

        // workaround for an issue in getLocation where it will compute the location of the document element.
        // this will return an offset if scrolled.
        //
        if (element === document.documentElement) {
            
    return new Sys.UI.Point(0,0);
        }

        
    // Workaround for IE6 bug in getLocation (also required patching getBounds - remove that fix when this is removed)
        if (Sys.Browser.agent == Sys.Browser.InternetExplorer && Sys.Browser.version < 7) {
            
    if (element.window === element || element.nodeType === 9 || !element.getClientRects || !element.getBoundingClientRect) return new Sys.UI.Point(0,0);

            
    // Get the first bounding rectangle in screen coordinates
            var screenRects = element.getClientRects();
            
    if (!screenRects || !screenRects.length) {
                
    return new Sys.UI.Point(0,0);
            }
            
    var first = screenRects[0];

            
    // Delta between client coords and screen coords
            var dLeft = 0;
            
    var dTop = 0;

            var inFrame = false;
            
    try {
                inFrame = element.ownerDocument.parentWindow.frameElement;
            }
    catch(ex) {
                
    // If accessing the frameElement fails, a frame is probably in a different
                // domain than its parent - and we still want to do the calculation below
                inFrame = true;
            }

            
    // If we're in a frame, get client coordinates too so we can compute the delta
            if (inFrame) {
                // Get the bounding rectangle in client coords
                var clientRect = element.getBoundingClientRect();
                
    if (!clientRect) {
                    
    return new Sys.UI.Point(0,0);
                }

                
    // Find the minima in screen coords
                var minLeft = first.left;
                
    var minTop = first.top;
                
    for (var i = 1; i < screenRects.length; i++) {
                    
    var r = screenRects[i];
                    
    if (r.left < minLeft) {
                        minLeft = r.left;
                    }
                    
    if (r.top < minTop) {
                        minTop = r.top;
                    }
                }

                
    // Compute the delta between screen and client coords
                dLeft = minLeft - clientRect.left;
                dTop = minTop - clientRect.top;
            }

            
    // Subtract 2px, the border of the viewport (It can be changed in IE6 by applying a border style to the HTML element,
            // but this is not supported by ASP.NET AJAX, and it cannot be changed in IE7.), and also subtract the delta between
            // screen coords and client coords
            var ownerDocument = element.document.documentElement;
            
    return new Sys.UI.Point(first.left - 2 - dLeft + ownerDocument.scrollLeft, first.top - 2 - dTop + ownerDocument.scrollTop);
        }

        
    return Sys.UI.DomElement.getLocation(element);
    },

    Sorry for the trouble - we hope this patch helps any people who might be running into this issue!

    Updated at 6pm: Modified the getLocation implementation to return the correct value in all cases.

  • Delay's Blog

    Toolkit talk, take two [Spoke at the TechReady4 conference]

    • 2 Comments

    Earlier today I presented the DEV304: ASP.NET AJAX Control Toolkit Unleashed: Creating Rich Client-Side Controls and Components session at Microsoft's TechReady4 conference here in Seattle. TechReady is a Microsoft-only conference that non-Redmond-based employees attend to get an opportunity to meet with product team members (typically Redmond-based) and catch up on all the new technology each year. Most of the session content is Microsoft-only, but because the presentation I gave today had no private information, I'm posting the (sanitized) slide deck and demos here for everyone to use (note: the attachment is at the bottom of this post).

    If you saw the content for my ASP.NET Connections talk a few months ago, the slide content for today's TechReady4 talk was very similar. The first demo was identical and the second (new) demo was just a quick overview of the sample web site that comes with the Toolkit. However, the third demo was completely new and demonstrated how to encapsulate existing script into a new Toolkit control. For demonstration purposes, I took a simple web page with a WPF/E (February CTP) control (the use of which requires two <script>/src tags and a <script>/code block) and showed how to wrap that all into a single "one-liner" Toolkit component which can be more easily used/maintained/added to a page. Those of you who are paying close attention will realize that I took my inspiration from a similar effort by my manager, Shawn Burke - though I wrote all my demo code from scratch so I'd be more familiar with it. :) The final result is a pretty handy way of handling WPF/E controls and folks are welcome to use it however they want!

    I hope those of you who attended today enjoyed the talk and learned more about the Toolkit - it was great to have an opportunity to meet with you!

    PS - We're always looking for more contributors and additional control ideas, so please let me know if you want to contribute!

  • Delay's Blog

    A quick update to address some top customer issues [AJAX Control Toolkit update!]

    Just a few moments ago we made available the 10201 release of the AJAX Control Toolkit to address some of the most significant issues reported since the 10123 release last week. We chose these issues based on feedback from our users in our support forum and online issue tracker and tried to prioritize issues with widespread benefits while minimizing the risks of breaking anything.

    In particular, we:

    • Fixed problems that occurred when using the new AutoComplete or Tabs controls inside an UpdatePanel
    • Improved the localization behavior of the Calendar so that it works better in other countries/time zones
    • Simplified and improved the implementation of the new "draggable popup" feature of ModalPopup
    • Addressed a TextBoxWatermark focus issue that was inconveniencing users

    Recall that you can sample any of the controls right now (no install required). You can also browse the project web site, download the latest Toolkit, and start creating your own controls and/or contributing to the project!

    If you have any feedback, please share it with us on the support forum (or email me)!

Page 1 of 1 (3 items)