locked
Bug report: MouseMove on document fails over disabled objects. RRS feed

  • Question

  • User132352790 posted

    I found a bug in the event handler code of the client library related to document-mousemove and disabled DomElements.

    Steps to reproduce:

    1. Add an input button to the page and disable it:

                  <input type="button" id="Button1" value="Button 1" disabled="disabled" />

     2. Attach a mousemove event to the document in the init event of the application:

                 Sys.Application.add_init(function() { $addHandler(document,'mousemove',function(e) { }); });

    3. Run the page in IE and move the mouse over the disabled button. An exception is thrown:

                Microsoft JScript runtime error: Sys.ArgumentException: Value must be a DOM element. Parameter name: element

    This problem occurs because the event target is not null, but an empty object. The DomEvent handler tries to get the location of the element, but fails when it realizes that this is not a DomElement (Since MSAJAX doesn't check for argument types in non-debug mode, it there tries to get a property of the object that doesn't exist which fails too).

    Because of IE's buggy mouseover/out eventhandlers, attaching a mousemove event to the document is a very valid use-case in many scenarios.

    Monday, August 27, 2007 1:15 AM

Answers

  • User222791821 posted

    Hi,

    I have tested it, and found it really throw an error. but the error message is:

    Microsoft JScript runtime error: Object doesn't support this property or method

    Error position:

    var d=a.getClientRects();

    I have reported this to our bug handler team.

    Sorry for having misunderstood you.

    Best Regards

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, August 31, 2007 4:33 AM

All replies

  • User132352790 posted

    Just an update... This is not a problem with the mousemove event only. As far as I can tell, any mouse event has this behavior.

    Only workaround I've come up with so far is to create my DomEvent class (inheriting from Sys.UI.DomEvent) that checks the target before calling the baseclass constructor, and create me own $addHandler method which is more or less a copy-paste of the original one but replacing it with my "fixed" DomEvent class.

    Monday, August 27, 2007 1:00 PM
  • User222791821 posted

    Hi,

    Thank you for your post.

    I think this is by design, $addHandler method is designed to add a DOM event handler to the DOM element that exposes the event. It's hard to say that document is a DOM element.

    Anyway,I think what you did is a very good solution to aviod this error. Thanks for your post again.

    Best Regards

    Thursday, August 30, 2007 6:03 AM
  • User132352790 posted

    Are you kidding me? Duplicating all the existing eventhandler code and changing a few lines here and there is not a good solution. I mean, whats the point of having the framework if I have to do it all myself? Furthermore the document is a DOM element. If it wasn't, I wouldn't even be able to call $addhandler with the document as the element.  So you are telling me that throwing an exception by moving the mouse over an disabled element is "by design" ?

    I extended the test, and found that it's actually a problem with ANY container around a disabled object - not just the document - which I guess makes this bug even worse and very valid.

    The following will fail the same way:

    <html xmlns="http://www.w3.org/1999/xhtml" >
    <
    head runat="server">
    <title>Disabled element bug</title>
    </
    head>
    <
    body>
    <form id="form1" runat="server">
        <asp:ScriptManager runat="server" ID="ScriptManager1" />
        <div id="container">
           
    <input type="button" id="Button1" value="Button 1" disabled="disabled" />
        </div>
    </form>
    <script language="javascript" type="text/javascript">
            Sys.Application.add_init(
    function() { $addHandler($get('container'),'mousemove',function(e) { }); });
    </script>
    </
    body>
    </
    html>

    By design you say? [:D]

    Thursday, August 30, 2007 12:51 PM
  • User222791821 posted

    Hi,

    I have tested it, and found it really throw an error. but the error message is:

    Microsoft JScript runtime error: Object doesn't support this property or method

    Error position:

    var d=a.getClientRects();

    I have reported this to our bug handler team.

    Sorry for having misunderstood you.

    Best Regards

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, August 31, 2007 4:33 AM
  • User1875686366 posted

    Just to add some detail about the cause of the problem.

    It seems that IE (at least versions 6 and 7) fires the mousedown, mouseup and possibly other events with an empty object when the source element is disabled.

    This does not seem very logical and no other browser does it, but that is the reality. 

    The MS Ajax framework checks only if the object is undefined and assumes that this is enough to conclude that this is a DOM element, since it has fired the event in the first place. Soon after that it fails badly when it tries to access some of the properties, when in fact the object has none.

    It seems that a special check for this condition must be incorporated in the code. 

    Jin-Yu Yin: Try setting debug="true" in web.config to get a more detailed error message.


    Thursday, September 20, 2007 3:30 AM
  • User132352790 posted

    Jin-Yu Yin: Thanks for submitting the bug. Is this likely to make it into .NET 3.5? If it will, I'll add a version check and only apply the workaround for code running on the older version. I'm not getting the same error message you are. Are you using the beta from .NET 3.5 or MS AJAX 1.0 ?

    cvetomirconev: If you read my orignal post, I show the error message in both debug and release mode (they are not the same). In my workaround I know what element I did the mousemove on, so if the target is an empty object, I replace it by the element that I hooked the mousemove event to. This messes up the position of the event, but at least it doesn't crash the app.

    I agree that IE behaves weird here (perhaps an IE bug?). IE bug or not, we still need a workaround for this, because unfortunately we can't rely on people installing their browser updates.

    Thursday, September 20, 2007 12:53 PM
  • User-953211759 posted

    Is this bug fixed in .NET 3.5? I'm experiencing this bug in .NET 2.0 right now (IE7), is there anything I can do about this to avoid the javascript error?

    Saturday, January 12, 2008 10:02 PM
  • User1875686366 posted

     I am not sure if it has been fixed in Net 3.5. The workaround we have used is to detach the event handlers when we disable the element and reattach them after enabling it.

    Sunday, January 13, 2008 10:25 AM
  • User517637359 posted

    Does anyone have examples of how to fix this issue with specific elements on a page?  I need a workaround for several inactive text boxes that will toggle between active and inactive several times during a session.

    Thanks for any help you can offer.

    -Travis
     

    Wednesday, July 2, 2008 1:22 PM
  • User-529266022 posted

    Instead of disabling the textbox, i assigned the textbox readonly attribute

     Cheers!

    Thursday, July 17, 2008 11:49 AM
  • User132352790 posted

     That will only work for textboxes though. My problem is actually with a button, but any input element seems to have this problem.

    Thursday, July 17, 2008 1:24 PM
  • User818571376 posted

    I was able to get around this problem by setting the z-index of the problem button to -1 and placing it behind a transparent div the same size/position as the button.

     Note, in my original reply I posted: 

    Really annoying problem - also, the above solution is only 99% consistent - I still on occasion get an error using this method when I mouse over / out of the disabled button even though the button has no attached mouse events, however, I get the error 100% of the time without the z-index toggling.

     I was able to completely resolve the issue by setting the margin on the disabled button to 1px 1px 1px 1px.  It turns out the occasional error I was getting was coming from the rare instance where I'd hit the button's top border...  once the margin was set the transparent container div completely covers the element and prevents the behavior...

     Hope that helps.

     

    Brian

    Tuesday, May 26, 2009 3:51 PM
  • User1859759103 posted

    Another way to fix it is by putting the button or textbox inside a html container like div (I have used a td) and disabled the container instead of actual control. It works for me.!

    Saturday, September 18, 2010 1:59 AM