[MGNLSLOCK-6] Introduction of jQuery.noConflict() in javascript.js can break author instances already using jQuery and its $ alias. Created: 04/Jan/11 Updated: 19/Jul/17 Resolved: 06/Jan/11 |
|
| Status: | Closed |
| Project: | Magnolia Soft Locking Module |
| Component/s: | None |
| Affects Version/s: | 1.0 |
| Fix Version/s: | 1.0.1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Federico Grilli | Assignee: | Federico Grilli |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
As received via email by Kees de Koning from MediaCatalyst
jQuery.noConflict() slipped into our softLocking.js (and thus into javascript.js) probably due to some thoughtless code copy&paste. However we should carefully test the author without it as Magnolia too defines the $ as an alias to document.getElementById() An alternative to replacing all occurrences of $ could be wrapping code using jQuery like this jQuery(document).ready(function($) {
// Code that uses jQuery's $ can follow here.
});
|
| Comments |
| Comment by kees de koning [ 04/Jan/11 ] |
|
Thanks Jan. Do you have any ETA on a fix for this? thanks, Kees |
| Comment by Federico Grilli [ 04/Jan/11 ] |
|
Indeed, removing jQuery.noConflict() breaks the author instance with a weird javascript error at DHTMLUtil.hide(element) function where element.style is now undefined. I tried to debug the code but was not able to find the reason for this. |
| Comment by Jan Haderka [ 04/Jan/11 ] |
|
Unless anything changes the fix should be included in 4.4.2 bundle that will go out before end of January. |
| Comment by Jan Haderka [ 04/Jan/11 ] |
|
Federico, would it be possible to wrap just the DHMLUtil.hide(element) instead of using global jQuery.noConflict() if this is the only reason? |
| Comment by Federico Grilli [ 04/Jan/11 ] |
|
I'm looking into a solution without using jQuery.noConflict() but I can't wrap DHMLUtil.hide(element) which is a Magnolia js function and does not even use our $ function. The javascript error I get is very strange indeed as I went through the call stack and could not find any reference to the $. I'm not even 100% sure that the missing jQuery.noConflict() is the error cause, although apparently it is. |
| Comment by Federico Grilli [ 04/Jan/11 ] |
|
Kees, can I ask you if you experience this problem either in adminCentral or in authoring/preview mode, or both? I'm asking this because if jQuery.noConflict() gives no problem on the authoring/preview side I would tend to keep it, as it will prevent conflicts with other libraries possibly integrated into Magnolia and using the $ function. Furthermore, it would allow different jQuery versions to live in the same page without conflicting with each other (see http://stackoverflow.com/questions/1566595/can-i-use-multiple-versions-of-jquery-on-the-same-page) |
| Comment by kees de koning [ 05/Jan/11 ] |
|
Hi Federico, The problem is in our own code, in author/preview mode. AdminCentral seems to work fine, and on public there are no problems with our site at all. We use an older version of JQuery (1.3.2) due to compatibility issues of newer versions with the PlayStation3 browser (a required platform for us). |
| Comment by Federico Grilli [ 06/Jan/11 ] |
|
OK, then I'll remove jQuery.noConflict() from our script. I actually had some strange issues in AdminCentral after removing it but now they've gone as the softLocking.js script is no longer loaded when we're in adminCentral (before it was loaded as a side effect of being included into javascript.js as the soft locking feature needs that script in every page). |
| Comment by kees de koning [ 06/Jan/11 ] |
|
thanks Federico! |
| Comment by Federico Grilli [ 06/Jan/11 ] |
|
Sure! Well, to know more about "soft locking", you can read here http://www.magnolia-cms.com/magnolia-cms/magnolia-4-4/soft-locking.html and watch the video on the page to have a feeling of how it works. I'll only add that, contrary to JCR's "hard locking", soft locking allows multiple concurrent editing on a page and does not lock it for exclusive access to a single user. Now, for the temporary/fix, either you uninstall the soft locking module or replace it with the latest 1.0.1-SNAPSHOT artifact http://nexus.magnolia-cms.com/index.html#nexus-search;quick~soft%20locking. It is actually possible to disable the soft locking feature via configuration but the module's js code would be still included in javascript.js, so it would be of no use in your case. HTH. |
| Comment by kees de koning [ 06/Jan/11 ] |
|
great, this definitely helps! thanks a lot! |
| Comment by kees de koning [ 09/Jan/11 ] |
|
ok, that works in the sense that the JS conflict is gone, but shows a few new problems with soft-locking (not necessarily related with the patch though): I booted with a fresh repo, which has the most current state of the site (currently live in version 4.1.1) in its bootstrap folder. Is there a way to 'reset' the softlocking feature for an existing tree? |
| Comment by Federico Grilli [ 10/Jan/11 ] |
|
1) Hum, that's weird: of course a 200 response from the server should be OK and not caught as an error on client-side. However, it looks like jQuery.ajax()'s onError callback treats it as an error. From your screenshot it looks you're using firefox on windows. Is that correct? Can you give more details on the environment you're having that problem? As to resetting soft-locking for an existing tree, there is no such feature and I will definitely file it as an improvement. Currently the only way to reset soft-locking is either restarting the webapp or waiting that the timeout for each user working on a given page expires. |
| Comment by kees de koning [ 10/Jan/11 ] |
|
Hi Federico, Indeed, using FF 3.6.13 on Windows 7. Same problem with Chrome 8.0.552.224. IE 8 doesn't seem to have the problem though! |
| Comment by Federico Grilli [ 10/Jan/11 ] |
|
OK, I moved the error message problem to a new ticket |
| Comment by Rupak [ 19/Jul/17 ] |
|
Hello Team, We are using Magnolia 4.5 with magnolia-module-soft-locking-2.0.3 jar having jquery-1.4.2.min.js inside the jar. The application I am running in windows 7 withchrome Version 59.0.3071.115 . We have tried by updating the js file to 1.12.4(Jquery version) but still we are facing the broken page in IE and chrome. |