Weird Chrome prototype/jQuery conflict

前端 未结 2 1056
无人及你
无人及你 2020-11-29 08:25

We have an application with legacy code that relies on prototype, but we\'ve found it to be too \'heavy\' for most of the places we want to use it and and have found jQuery

相关标签:
2条回答
  • 2020-11-29 08:48

    From Core/jQuery.noConflict:

    NOTE: This function must be called after including the jQuery javascript file, but BEFORE including any other conflicting library, and also before actually that other conflicting library gets used, in case jQuery is included last. noConflict can be called at the end of the jQuery.js file to globally disable the $() jQuery alias. jQuery.noConflict returns a reference to jQuery, so it can be used to override the $() alias of the jQuery object.

    Maybe try changing it to:

    <script language="javascript" type="text/javascript"
      src="jquery-1.3.2.js"></script> 
    <script language="javascript" type="text/javascript">
        $j = jQuery.noConflict();
    </script>
    <script language="javascript" type="text/javascript"
      src="prototype-1.5.1.2.js"></script>
    
    0 讨论(0)
  • 2020-11-29 08:57

    I've found the root of this problem to be:

    1. Prototype loads, and because WebKit lacks document.getElementsByClass(), Prototype (insidously) creates it.

    2. jQuery initialization begins, and at the very top, it sets window.$ to jQuery.

    3. During JQuery's initialization, the Sizzle engine (added in 1.3.2?) initializes. As part of its introspection, it checks for, and then tests the functionality of document.getElementsByClass(). As a result, it calls Prototype's impelementation of getElementsByClass(), which depends on window.$ being set to Prototype's $, not jQuery's.

    Ultimately, this will need to be fixed in jQuery (see tickets http://bugs.jquery.com/ticket/4365 and 5027). My quick patch was to remove the assignment to window.$ in the top of jQuery's initialization.

    0 讨论(0)
提交回复
热议问题