Skip to content

Issue with conflicting jQuery modules #38

Closed
ztane opened this Issue Oct 14, 2011 · 20 comments

7 participants

@ztane
ztane commented Oct 14, 2011

we use $(function() {}), aka ondomready quite extensively. After enabling debugtoolbar we found out that the global $ object did not contain necessary extensions anymore. This is probably caused by the debug toolbar fragment (https://github.com/Pylons/pyramid_debugtoolbar/blob/master/pyramid_debugtoolbar/templates/toolbar.jinja2#L11) injecting the scripts in separate elements;

Now, we have seen some browsers, e.g. Chrome, parsing the body scripts in order, the onDomReady event is sometimes (quite often actually) fired after the debug toolbar's jQuery has been loaded, but before $.noConflict() is called.

Thus, 2 things should be changed.

1) $.noConflict(true) should be used to remove the jQuery variable too
2) all these scripts should be catenated, and even then they should refer to $ only by closure.

@ztane
ztane commented Oct 14, 2011

Sorry, $.noConflict(true) was called :) So only 2) applies. To further elaborate, we do not notice any issues in Firefox, but with Chrome, the ondomready functions most of time see the wrong window.$ variable, which is missing our jQuery plugins.

@mcdonc
Pylons Project member
mcdonc commented Oct 14, 2011

Do you think you can supply a patch that gets rid of the symptom?

@blaflamme
Pylons Project member

can you checkout latest changes and tell me if it's fixed?

@ztane
ztane commented Oct 20, 2011

I am not sure if this is enough, the problem was that our $() handlers could fire between any two scripts that are injected to document.body. We can use closures but many other ppl will have needless hours debugging.

Furthermore, fresh checkout caused random infernal server errors ;)

@ztane
ztane commented Oct 20, 2011

The 500 error reported here #41.

After fixing that, saw yet another race cond, this time "$(".pDebugSortable").tablesorter" is not a function.

I am leaning towards a solution where both the jquery AND tablesorter.js would be patched by hand to use a variable name like pyramid_debugtoolbar_jquery instead of $ :D It seems to be the only way to avoid such race conditions.

@blaflamme
Pylons Project member

Have you flushed you cache? jQuery is now called as jq from the script and will not work properly if used with the previous way.

@blaflamme
Pylons Project member

Actually var jq = jQuery.noConflict(true); and we use closure and reference jq as $. So it's sets our jQuery to jq and restore any previous loaded jQuery to $ so you shouldn't have problem with your own scripts. Be sure to clear up your cache or you'll definitely have problem with table sorter and the debugger.

I can see you got server errors because of the bad join list, however if you got random error I would like to see your tracebacks to know where the problem is.

@ztane
ztane commented Oct 26, 2011

the problem is that ondomready can be fired between any two consecutive script loads for script elements document body. The closure in place "x" does not help, because ondomready can fire after jquery-1.6.4.min.js is loaded and before tablesorter, OR after tablesorter is loaded but before the noconflict line is run. With Chrome, one can read "can fire" as "most probably fires."

I would say that there are only 3 possible fixes

  1. Do use the jquery that is already linked on the page, and hope it works, and that tablesorter does not clash with anything else
  2. or catenate all scripts together and make a closure around them
  3. rename the jQuery and $ variables to something else INSIDE jquery.js and use them everywhere.

All three options mean the jquery source has to be hacked - one way, or another.

I think 2 could be the cleanest option. I can post a patch when we have our release out of hands.

@blaflamme
Pylons Project member

A cleaner solution wouldn't be to go with require.js then?

@blaflamme blaflamme added a commit that referenced this issue Oct 27, 2011
@blaflamme blaflamme attempt to fixed issue #38 by including plugin into the toolbar names…
…paced, closured with jquery.noConflict(true)
01c51b9
@jayd3e
Pylons Project member
jayd3e commented May 28, 2012

I just received this error 'Uncaught TypeError: Property '$' of object [object DOMWindow] is not a function' while using the Debug Toolbar, and removing the toolbar fixed the error. I think it is related to this issue. Debug toolbar is still overwriting '$' somewhere.

@blaflamme
Pylons Project member

Are you using the latest toolbar release? On what browser and os you get the error?

@jayd3e
Pylons Project member
jayd3e commented May 28, 2012

I'm using the latest release, and I'm on Mac OSX Lion on Chrome v19.

@blaflamme
Pylons Project member

Can you replicate the behaviour in a sample app and share it?

@jayd3e
Pylons Project member
jayd3e commented May 28, 2012

That might be difficult, because it was working before my project reached a certain size. I'm sure load times factor into this in some way. I'll definitely try though.

@blaflamme
Pylons Project member

if you app is becoming large, js speaking, you could benefit using requires to modularize and load your code.

@jayd3e
Pylons Project member
jayd3e commented May 28, 2012

I checked it out, didn't really like it. I use the module system detailed here.

@AaronAsAChimp

This error still occurs in v1.0.4. The version of jquery included with the toolbar uses the global define rather than pyramid_debugtoolbar_define. This causes it to load in the app's requirejs and overwriting its version of jquery.

Wrapping the library like so will fix it:

define = pyramid_debugtoolbar_define;
/*! jQuery v1.7.2 jquery.com | jquery.org/license */
/* ... */
define = pyramid_debugtoolbar_std_define;
@blaflamme
Pylons Project member

Can you fix it, test it and send a pull request?

@rclmenezes

I discovered a similar issue using v1.0.6 when doing browser compatibility testing in IE. I was having this infuriating error where a jQuery plugin I wrote would only work three quarters of the time and the other fourth of the time be undefined. After digging around for a couple hours, I discovered that my jQuery plugin was extending my version of jQuery while the code on the page was running the jQuery used by pyramid_debugtoolbars!

I'm not entirely sure what caused this kind of behavior (the IE gods are fickle) and it's difficult to replicate regularly. I have my version of jQuery and my plugin both running in the page's <head>, so I think I'm doing it correctly...

Any ideas?

@mmerickel
Pylons Project member

This issue is no longer relevant as the toolbar is hosted in a separate tab now.

@mmerickel mmerickel closed this Sep 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.