Closed (duplicate)
Project:
Drupal core
Version:
5.x-dev
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
14 Feb 2007 at 00:37 UTC
Updated:
24 Dec 2007 at 10:43 UTC
Jump to comment: Most recent file
Comments
Comment #1
drummThis is not a patchfile, see http://drupal.org/diffandpatch.
Developments like this happen on 6.x-dev.
Comment #2
mr700 commentedI've tested this and see no javascript errors with drupal 5.1 (only textarea.js uses this and it works) with the builtin jQuery.
I think it's a good thing if this breaks nothing and makes drupal jQuery 1.1.1 compatible, so I'll attach this as a patch.
Comment #3
Roi Danton commentedThx for the follow ups, next I'll heed the Drupal patch guidelines!
I think so, too, that this should be added to Drupal 5.x b/c it's a minor change with a great impact. The function I've changed is supported by most of jQuery's previous versions and the function will be supported in future by jQuery. Instead of the two old functions which aren't supported by jQuery anymore.
Comment #4
dries commentedWhile the patch looks good, it's not clear what bug this fixes. How can I reproduce the original bug? Rescaling the textarea seems to work with Drupal 5 on FF2.
Comment #5
mr700 commentedThis is probably related to publishing options NOT available in Firefox and Two text area "body" fields. I think I saw 1/2 others, but can't find them now.
Comment #6
mr700 commentedI think node 110935, from comment 181672 is quite informative and jQuery 1.1.1 really breaks collapsible fieldsets.
Still, I think if this change in textarea.js breaks nothing and brings drupal 5/6 closer to jQuery 1.1.x it's a good thing.
Comment #7
dries commentedCommitted to CVS HEAD. Needs to go in Drupal 5.
Comment #8
webchickHm. Does it?
I thought we specifically weren't upgrading jQuery to 1.1 in Drupal 5.x since it broke backwards compatibility with 1.0?
Comment #9
mr700 commentedWebchick, this change does not upgrade to jQuery 1.1.x, it just makes textarea.js compatible with both jQuery 1.0.x and 1.1.x.
Comment #10
Steven commentedUnnecessary for 5.0. It will never be bundled with 1.1.x and we should not be encouraging this sort of mismatching of jQuery and Drupal versions. It will only lead to random/incorrect bug reports in the future.
Comment #11
joshk commentedI understand stephen's point about drupal5 bundling and version mismatches. At the same time, I don't see the harm in having drupal's .js file more compatible. If it broke backwards compatibility obviously it would be a no-go, and I don't think anyone's talking about making it a featured suggestion for site admins to upgrade jQuery on their own.
Still, I don't see a downside to having core be more compatible.
Comment #12
Roi Danton commentedWrong, there will be no mismatching because the jQuery version won't be changed.
Reasons to use the patch:
Reasons not to use the patch:
nothing
Why?
Comment #13
Steven commentedjQuery 1.1 is not backwards compatible with 1.0. When we included jQuery in core, we said we would sync up with major jQuery versions only with major Drupal versions.
This means all contributed modules need to be built for jQuery 1.0 if they are to work everywhere. If we start accommodating 1.1, it will undoubtedly encourage people to use it and will most likely cause bug reports down the line when someone assumes 1.1.
Comment #14
z.stolar commentedDries has commited to head, but it seems that finally the idea is not to leave things as they are.
So I'm confused as to the current status in HEAD and Drupal 5.1 - Will the patch be part of Drupal 5.2, or not?
Comment #15
joshk commentedjQuery 1.1 is not backwards compatible with 1.0.
That's not really true, and speaking of "backwards compatibility" in this context is misleading. It's not jQuery which is compatible, it's Drupal's .js files. Javascript code which depends on jQuery -- such as the scripts that ship with core in /misc -- may or may not be backwards compatible, depending on how it's written.
For instance, with the changes mentioned in this thread, textarea.js becomes compatible with both 1.0.x and 1.1.x. That's better than only 1.0 compatible, right?
This means all contributed modules need to be built for jQuery 1.0 if they are to work everywhere. If we start accommodating 1.1, it will undoubtedly encourage people to use it and will most likely cause bug reports down the line when someone assumes 1.1.
First of all, I strongly doubt you'll get a lot of people hand-replacing their javascript library and "assuming 1.1," especially if you don't tell people to do so, and/or make the point that this isn't supported. I just don't see the support nightmare you're talking about emerging: this isn't stuff that your average user pays any attention to or feels comfortable with.
What seems smart would be to have Drupal core be forward-compatible, and to try and get the community's JavaScript experts outline some best practices on how to write jQuery .js code for contrib modules which supports both 1.0 and 1.1, since this is obviously possible.
Comment #16
BioALIEN commentedI can see both sides of the argument here. While I would like to see Drupal 5.x be inline with the latest jQuery libraries, it does create a burden on other developers and support. But then again, you have to account for the fact that these same module authors will also be keeping with HEAD (Drupal 6.x) which will ship with jQuery 1.1+, so one way or another they will have to upgrade at some point.
This then makes their job harder having to maintain two derivatives one with jQuery 1.0x and a separate one with jQuery 1.1x+
Code consistency aside, the overall picture might actually be that its easier to just upgrade to the latest .js libs and classify it as a bug fix - along with any fixes that make their way in minor Drupal versions.
Just my 0.02p
Comment #17
Nimstad commentedI had a bug in advpoll_binary that was solved with upgrading JQuery. The bug was that the ajax poll result wasn't inserted correctly when using Mozilla.
Comment #18
mykle commentedThe jquery.compat-1.0.js jquery plugin seems to be designed to solve this very problem. It seems to fix the textareas. (I'm still having problems with collapsing sections, but maybe that's a different bug?)
Comment #19
rmpel commentedIf I may make a remark;
I have some jquery-based modules. One of them is a jquery extension to make shufflepuzzles out of images. It requires jquery 1.2+.
I think, however, it's rediculous to force upgrade to D6 just for a library update, so, I overwrote the jquery.js file.
I have NOT seen any problem except for the resizable textarea.
the patch above to replace unmousemove(fn) and unmouseup(fn) with unbind('mousemove', fn) and unbind('mouseup', fn) fixes this.
And for those wanting to experience the bug; Drupal 5.x with jQuery 1.1 or newer on IE7.
What I don't understand is that this bug does not occur on FF; resizing works like a charm even with the textarea.js and jquery.js mismatched.
And on a note of concern - programming wise;
with a minor version change, from 1.0 to 1.1 or 1.2.1, a big change in function-naming should not occur. "Minor version change" means "backwards compatible" which is clearly not the case with jquery < 1.0 vs. 1.1+
IMHO, jQuery 1.1 should be called 2.0 -OR- both function calls should be allowed.
But this is dicussion for the jQuery development group and not for Drupal.org :P
Attached find version 1.2.1 of jQuery, works with D5.x as long as textarea.js is patched. I'd like to ask people willing to test it to do so (as I still am doing ofcourse)
Also attached the patch on textarea.js (not because my patch is better, just to keep it all together; these two files play nice :D )
Comment #20
rmpel commented(post removed; after loads of page refreshes it showed up as double post. my apologies)
Comment #21
rmpel commented(if i'm double posting, please forgive me; my posts don't seem to show up on this page)
On a further note; the patch suggested above, changing
$(document).unmousemove(performDrag).unmouseup(endDrag);to
is off. Not wrong, but too much
The new code dismisses ANY hooks on mousemove and mouseup, while the original code only dismisses the hook to performDrag and endDrag respectively
$(document).unbind('mousemove', performDrag).unbind('mouseup', endDrag);is the only 100% correct replacement.
I have attached the correct patch to this effect to a previous post, but it doesn't seem to show up here :S
So, with apologies in advance for possible doubleposting; hereby again the patch;
Comment #22
magico commentedDiscussion follows at http://drupal.org/node/156221