Skip to content
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

Closed
edsu opened this issue Jan 7, 2014 · 5 comments
Closed

jQuery getting stomped on #48

edsu opened this issue Jan 7, 2014 · 5 comments

Comments

@edsu
Copy link

edsu commented Jan 7, 2014

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:

  1. From a brief search It looks like jQuery takes backwards compatibility pretty seriously. So if Wayback must have a jQuery dependency perhaps it could simply be upgraded to use the latest version.
  2. It looks like it’s possible for multiple versions of jQuery to co-exist on the same page. So perhaps Wayback could be updated to use jQuery in this way, so that it doesn’t interfere with archived pages that also use jQuery?
  3. Perhaps Wayback should test to see if jQuery could be loaded before re-loading it? This is what was recommended in a previous bug report
  4. Perhaps Wayback doesn't need jQuery at all anymore?

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.

@johnerikhalse johnerikhalse added this to the 2.0.1 Release milestone Sep 30, 2014
@RogerMathisen
Copy link
Contributor

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

@anjackson
Copy link
Member

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.

@RogerMathisen
Copy link
Contributor

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.

@johnerikhalse
Copy link
Contributor

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.

PsypherPunk pushed a commit that referenced this issue Feb 3, 2015
Solution to #48 - Removed dependency on jQuery from Toolbar.
@kris-sigur
Copy link
Member

Fixed in PR #210

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants