Feature - Implemented Make stationary buttons stationary

[matt.chugg]

Its generally not a good idea to load multiple versions of the jQuery Library, unless loaded using noConflict().

http://stackoverflow.com/questions/1566595/can-i-use-multiple-versions-of-jquery-on-the-same-page

I find loading them from the google, or jQuery CDN useful too (also meaning you could knock a few kb off the build size)

Javascript files can also be referenced using a querystring as per my post #22 in this thread to prevent caching instead of file renaming.

However, I really don't want to take anything away from the great work done in getting this implemented, it's certainly a better experience now! Thanks!

 

[Veracity]

Javascript files can also be referenced using a querystring as per my post #22 in this thread to prevent caching instead of file renaming.

I saw that, but, the fact is, I don't want to prevent caching. So, I am willing to live with version numbers in the names of (very) infrequently modified Javascript files that we provide.

Its generally not a good idea to load multiple versions of the jQuery Library, unless loaded using noConflict().
…
I find loading them from the google, or jQuery CDN useful too (also meaning you could knock a few kb off the build size)

KoL has its own versions of jquery that it uses sometimes. Various user-supplied relay scripts use diverse versions of jquery. And now KoLmafia itself is using it a bit. We can certainly synchronize with KoL - especially since we get to rewrite KoL's HTML to our heart's content - but user scripts are out of our control. It's a similar situation to the link you posted, where customers were allowed to insert their own code - including scripts.

 

[matt.chugg]

I saw that, but, the fact is, I don't want to prevent caching. So, I am willing to live with version numbers in the names of (very) infrequently modified Javascript files that we provide.


KoL has its own versions of jquery that it uses sometimes. Various user-supplied relay scripts use diverse versions of jquery. And now KoLmafia itself is using it a bit. We can certainly synchronize with KoL - especially since we get to rewrite KoL's HTML to our heart's content - but user scripts are out of our control. It's a similar situation to the link you posted, where customers were allowed to insert their own code - including scripts.

Fair enough! Perhaps i'll edit the wiki secton on user scripts and make a note that jQuery is already loaded, which version and some reccomendations on using noConflit(). In my time working as a web developer I've very rarely found the need to load an older version of jQuery, the truth being that anything that relies on an old version, should itself be updated, however forcing only one version and potentially breaking scripts would probably be a bad move here as KoLmafia relay isn't as centralized as a website.

RE: your first comment "I don't want to prevent caching": My solution (using version number) would cache, and only force a "hard refresh" when a new build was used for the first time, I appreciate the infrequency that JS and CSS files are modified, so the as you said it really isn't an issue anyway.

 

[Theraze]

RE: your first comment "I don't want to prevent caching": My solution (using version number) would cache, and only force a "hard refresh" when a new build was used for the first time, I appreciate the infrequency that JS and CSS files are modified, so the as you said it really isn't an issue anyway.

But with daily builds, it considers r13211 to be a different version than r13212 and would therefore not cache that. Whereas with Veracity's current solution, it would only break the caching when the file itself actually changes...

Tying it into the version number is great if you've decided that anytime there's an update to that file you're going to spin a new version and only then. It's not great when new versions are only spun for major breaking content being supported and is completely unrelated to whether or not the CSS files are updated or not.

 

[Veracity]

Ah, yes. It caches until the revision number changes. Which will happen substantially more often than our built-in .js files change. So, no, for now.

We should discuss jquery standardization more in a new Feature Request

- Should we always load jquery - and make the version available to scripts?
- If so, get it from "the google, or jQuery CDN", rather than bundling it. That would make it trivial to update.
- If so, how about suppressing any KoL loads of it, since we will do it?

We could then encourage the relay scripts that load it to stop including it in their svn/relay directories and instead assume that it will be available.

I don't really have an opinion on the "right" answer to those. Perhaps somebody who is more knowledgable about it than I could open a Feature request for us to discuss this.

 

[Theraze]

The negative part about not including it is that it presents an additional point of failure for those who are using proxies or with wretched connections. We already have a FReq to allow using a stored copy of the Faxbot list due to proxy/bad-connection download failure. If we stop including this, I'd expect those same people to almost immediately (on realization) create a FReq to allow caching the JQuery so that they can continue seeing things properly.

 

[Veracity]

Do you come in through a proxy, Theraze? No? I didn't think so. Too bad, because otherwise YOU could test your supposition yourself and either confirm or deny it.

If you use Stationary buttons, KoLmafia includes the following script be in the page it sends to the browser, which will then load it without going through KoLmafia:

http://code.jquery.com/jquery-1.9.1.js

I will be flabbergasted if we get so much as a single bug report from people complaining that their proxy blocks that server. Of course, if it is, there are thousands of other web pages that will be similarly screwed up for them, and KoL via KoLmafia will be the least of their troubles.

We have no reason to "cache" jquery. Your browser will do it. The FR for the Faxbot config file is completely orthogonal to this issue.

 

[Theraze]

Sorry, I was thinking that we had it currently stored in our compiled source since your second point talked about not bundling it. I misunderstood that you were referring to the possibility of bundling something that had not been bundled yet, and saying that we probably would continue not to bundle it so that the redirects can just be updated rather than actually needing to change the files which are stored locally.

Or am I still misunderstanding? I'd thought I had it sorted out, but... I'm really not trying to be confused or confusing here, just clarify so that the options are more clear.

 

[Veracity]

I find loading them from the google, or jQuery CDN useful too (also meaning you could knock a few kb off the build size)

This is what we are doing when we ask for "http://code.jquery.com/jquery-1.9.1.js". It is the opposite of "bundling" a particular version in with KoLmafia - or in an SVN-hosted script's relay directory.

I misunderstood that you were referring to the possibility of bundling something that had not been bundled yet, and saying that we probably would continue not to bundle it so that the redirects can just be updated rather than actually needing to change the files which are stored locally.

I want to continue to not bundle it. I want to have somewhere in KoLmafia:

String JQUERY_HOST = "http://code.jquery.com/";
String JQUERY_VERSION = "jquery-1.9.1.js";
String JQUERY_URL = JQUERY_HOST + JQUERY_VERSION;

which we can use when we decorate KoL pages and which we can make available to ASH relay scripts so they know what is available.

Or something.

I continue to want this discussion to move to its own Feature Request.

 

[xKiv]

If you use Stationary buttons, KoLmafia includes the following script be in the page it sends to the browser, which will then load it without going through KoLmafia:

http://code.jquery.com/jquery-1.9.1.js

This breaks KoL's use of jquery. For some reason, it prevents kol's native right-click (context) menu on combat-gained items. That's not good.
Incidentaly, when I used my magical eclipse debug powers and included just stationarybuttons.1.js (without jquery-1.9.1.js) and relied on kol-supplied jquery 1.3.whatever, I got both context menu and stationary buttons, on the same page ....

 

[Darzil]

This breaks KoL's use of jquery. For some reason, it prevents kol's native right-click (context) menu on combat-gained items. That's not good.
Incidentaly, when I used my magical eclipse debug powers and included just stationarybuttons.1.js (without jquery-1.9.1.js) and relied on kol-supplied jquery 1.3.whatever, I got both context menu and stationary buttons, on the same page ....

I'll bet you didn't get the content dynamically moving to just under the buttons, no matter how many rows they appear on, and thus stationarybuttons.1.js wasn't actually doing anything.

 

[xKiv]

I'll bet you didn't get the content dynamically moving to just under the buttons, no matter how many rows they appear on, and thus stationarybuttons.1.js wasn't actually doing anything.

That's possible. Still, I think "breaks existing functionality that I use" is something to be avoided.

 

[Veracity]

KoL includes jquery-1.3.1.min.js
Try including both stationarybuttons.js and jquery-1.9.1.js and excluding jquery-1.3.1.min.js.
In other words, only pull in one jquery.
Do KoL's context menus work with the the newer jquery when it is not conflicting with the earlier one?

 

[Darzil]

I agree. If Matt (or someone else) can advise on that no conflict thing to get this working I'd be delighted, or if anyone can suggest a better way of handling stationarybuttons.js stuff.

Because removing this breaks stuff for others too, sadly.

Edit - All I actually need stationarybuttons.js to do is to change the top of the content_ div to be the same as the overall height of the mafiabuttons div on load and on resize of the window. As jquery is a javascript library I suspect it must be possible in javascript. It is probably possible in jquery-1.3.1.min.js, if I knew the syntax. Probably trivial for someone who knows javascript, but that someone is not me. It is apparently not possible in plain css or html.

So if anyone can advise I'd be very grateful, as this update once working even as well as it does now is a great quality of life improvement for me, but I hate the idea of it breaking things.

 

[Veracity]

It is probably possible in jquery-1.3.1.min.js, if I knew the syntax. Probably trivial for someone who knows javascript, but that someone is not me. It is apparently not possible in plain css or html.

Recall that the .min version is the regular .js file with whitespace trimmed out. So, you can look at the readable version at

http://code.jquery.com/jquery-1.3.1.js

The readable version of the version you pull in is:

http://code.jquery.com/jquery-1.9.1.js

 

[xKiv]

Actually, after trying it in a "controlled environment":

<html>
        <head>
                <meta charset="utf-8" />
                <title>a</title>
        </head>
        <body>
                <div style='height:50%;'>
                  <div style='width:100%; position: absolute; top:0px; left:0px;' id='header'>
                        <div id="txt">something something 1 2 3</div>
                         <button id="btn">more</button>
                  </div>
                  <div id='content' style='position:fixed; margin: 0px; padding: 0px; top:200px; left: 0px; right: 0px; bottom: 0px; overflow: auto; width:100%'>
...lots of lines with <br/> go here
                        ar ---------------<br/>
                  </div>
                </div>
                <script src="http://code.jquery.com/jquery-1.9.1.js"></script>
<!--    <script src="http://127.0.0.1:60080/images/scripts/jquery-1.3.1.min.js"></script> -->
                <script language="javascript">
                        function resetPosition() {
                                var topbar = $('#header').height();
                                $('#content').css( 'top', topbar + 'px' );
                        }
                        $(document).ready( resetPosition );
                        $(window).resize( resetPosition );

                        $('#btn').click( function () { $('#txt').html( $('#txt').html() + 'a moretext lorem ipsum blablamentum gergufonum iomarentum hula gura naseterenaovanaka alberacht');} );
                </script>
        </body>
</html>

I think that
1) the initial resize works with both 1.3.1.min (served through mafia) and 1.9.1 (from jquery.com)
2) resize on window resize also works with both
3) resize on element content change isn't handled with either (understandably - there's nothing in the code for that, and no reason to expect the buttons to change without reload).

 

[matt.chugg]

sorry for late return

I think the best solution is loading latest jQuery from the CDN (as we are now) and encourage script writers to use it, if they really don't want to I think it's their responsibility to ensure what they load doesn't break existing functionality.

However, am I right in thinking, from reading the last few posts that using 1.9.1 from the CDN breaks kol (not kolmafia) functionality?

if this is the case I suggest we leave KoL loading 1.3.1 and load 1.9.1 ourselves (maybe on every page, from the CDN, the overhead is neglegible) but we load it using noConflict() making it available through something like "kmjq = jQuery.noConflict( true );"

The clever bit is that by loading in this manner we return the global variables to 1.3.1 meaning anything KoL wrote will still work and anyone using "$" selectors will be using 1.3.1, we then encourage scriptwriters, and in any kolmafia generated code to use kmjq("selector") to use the current CDN loaded version.

It makes sense in my head, but i'm afraid explaining things isn't my strong point, the example here (at the bottom of the page) http://api.jquery.com/jQuery.noConflict/ will probably make it clearer, as we have seen in the past, my java isn't up to much, but will try to help as much as possible!

 

[matt.chugg]

Another thought is that we only need the stationarybuttons code on a fight page, and it's not a lot of code, since we have the ability to modify pages as they come through the relay browser we could just put the javascript in the head tag, in a script tag.

 

[Veracity]

We put them on choices for the "auto" button, and non-combats (which are responses to adventure.php that did not redirect to fight.php or choice.php), for the "again" button. In fact, in the latter case, if you have KoL's CAB, we handcraft a CAB for you that has an "again" button, since KoL itself does not give you the CAB in that case.

 

[Veracity]

Which makes think that we could be tricky about which buttons we show, depending on context:

fight.php: as now: attack, script, skills
choice.php: auto - and one button per choice button
noncombat (or a fight or choice when it is complete): again

That's probably another feature request.