-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jQuery getting stomped on #48
Comments
I have started to look into this issue, and as far as I can tell there are two versions of jQuery in use in the GUI of OpenWayback. /WEB-INF/query/BubbleCalendar.jsp uses v1.4.2, while /WEB-INF/replay/Toolbar.jsp uses v.1.3.2. This alone could cause problems if the API of these versions differ. The suggested solution 1 must rely on jQuery always being backwards compatible. If this holds true, I think that OpenWayback would not need to always have the latest version included. If a newer version of jQuery got loaded it would be compatible with the original OWB API, and things should work. If an older version got loaded we could have a problem, as it might not have all functionality that the OpenWayback code relies on. This solution probably can't be used to ensure proper operation. Solution 2: It is indeed possible to run several versions of jQuery independently using "jQuery.noConflict()". The limitation is that the different versions of the library must be loaded in order from oldest to newest. The question is what happens when we load another version of the library. If using noConflict() requires at all versions must be referenced by its version number, this solution will fail when loading web pages with an older version of the jQuery library. If it is possible to mix noConflict() against the verison(s) that OpenWayback uses with ordinary reference within loaded web pages, solution 2 might work. Solution 3 would not work, since the library loaded from the web page might be older than the one used by OpenWayback and might not include all required functionality. Solution 4 is probably the best, but would require some work, and should probably exclude this fix from versjon 2.0.1 |
I think (2) should work, i.e. if within OpenWayback we only use a dedicated noConflict version of jQuery, and allow the archived page to load it's own jQuery however it wishes, as long we load our jQuery last? I guess we'll need to test it to find out. |
Have looked further into the problem, and it seems jQuery got a major overhaul in v 1.9.0 which makes this and newer versions partial incompatible with other versions. Versions from 2.x.x does not support IE 6, 7 and 8, so always using the newest version of jQuery is not a good solution for now. If we decide on solution 2, we probably need to do a lot of testing to make (almost) sure that it works properly on all variants of usage of the different versions of jQuery in the archived web pages. It might be less work to just look into how to replace the library. |
I realized it's only Toolbar.jsp that has the risk of conflicting jQuery versions since it's the only jsp mixing in with replay. As far as I can tell, jQuery is only used the get element offset for mouseOver events. I tried to reimplement the used functionality and then avoiding jQuery in Toolbar.jsp. I have made a pull request for it #210. The implementation is based on this post: http://stackoverflow.com/a/21880020. Please have a look and validate as I'm no Javascript guru. |
Solution to #48 - Removed dependency on jQuery from Toolbar.
Fixed in PR #210 |
As was discussed over on SourceForge it looks like Wayback's use of jQuery is causing some problems because it uses an older version (v1.3.2) which can stomp on previously loaded versions, which can break functionality on the page. I think it may also interfere with any jQuery plugins that have already been installed.
I don’t know what the best solution is, but it seems to me there are (at least) four options:
Personally, I think 4 is probably the best option, to keep things as simple as possible. But it's not entirely clear to me why jQuery was added, and what it and the associated plugins, are currently used for.
The text was updated successfully, but these errors were encountered: