Closed (fixed)
Project:
Content locking (anti-concurrent editing)
Version:
6.x-2.6
Component:
User interface
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
27 Jan 2012 at 19:41 UTC
Updated:
6 Nov 2012 at 16:30 UTC
Comments
Comment #1
GRRaka commentedComment #2
eugenmayer commentedCL tries to match your patch and white-lists specific paths the user can "change to". Those paths are mostly generic, like node/add//edit, but we had some issues in the paths. Please tell us, what is the path you are currently using? Are you using any weired redirects?
UPDATE: well, if FF works, our regexp might be flaky for IE? We are actually using CL with IE8 on a D 6.22 without any issues. IE7 is, for "authors", not part of what i would go for support here, i dont care about this browser and wont actually actively fix anything for it :)
Comment #3
ohnobinki commentedThis is fixed in f5d88cd which will appear in 6.x-2.8 and fb06fe4 which will appear in 7.x-1.3.
A related issue that needs to be looked at is how content_lock uses certain JS libraries. For example, this bug appears to be caused by a misfunctioning (and possibly outdated?)
onUserExit.jsjQuery plugin.Comment #4
ohnobinki commentedAlso, another note, I encounterred this error in seamonkey-2.7.1 which should function in the same way as firefox. I'm not sure if the fix handles IE, it doesn't fix it on IE6 for me—but few people seem to support IE6 nowadays. Yet I was unable to test it on IE7 or IE8 just yet because that platform is inaccessible to me at the moment.
Comment #5
GRRaka commented