SP2013: Custom script interfering with OOTB ribbon controls

Question

I've got a weird one here, and my JavaScript/SP2013 skills aren't up to the task apparently. I've got a custom script that I made by bashing together other scripts & snippets from around the web. The resulting script is messy and far from optimized, but it works. However, when loading the JS file on the page, the OOTB ribbon controls start acting funky. Specifically, the options on the Files tab such as "Check Out", "Check In", "Delete Document", "Download a Copy", etc. - all things that would normally light up when you select a file - are grayed out.

Despite being grayed out, they still work when clicked about half of the time, which is really weird. The other half, they really do show as disabled when you hover the mouse over them. When I comment out my script call on the master page, everything starts working normally again. So I'm pretty sure it's something in the script doing it. My working theory at this point is that the context is conflicting, and the OOTB script (sp.js, I think) doesn't realize there's a file selected when in fact there is...

The script itself wouldn't paste on here properly, so I've instead put it on JSFiddle for review. Here's the link:

http://jsfiddle.net/h9umJ/

The code on JSFiddle probably speaks for itself, but if you want the thought process behind it all, keep reading...

---

The user side of things works in the following way:

• JSLink file on the list view webpart overrides a 'single line of text' column on the view. That field is replaced by a checkbox.
• When a checkbox is checked, it adds the document's server relative URL to an array in the script. Unchecking the box removes it from the array.
• After the user has checked one or more files, they click a button that calls the CopyFiles(); function inside the script.

At that point, the script takes over:

1. The array of document URLs is looped through and broken into individual files on each loop (one for each file URL)
2. On each pass, the script checks if the URL is a folder or document. Our content type names are unreliable, so I cheated by assuming anything without a period in the name is a folder (no file extension)
3. If it's a folder, the script creates the folder in the destination library then parses the files in the source folder. For each file, it then copies it to the newly-created folder
4. If the URL is a document, it then checks to see if the URL starts with "/2/", which is something I pass from the checkbox if the document belongs to a certain category
5. The document is then copied to one of two destinations, depending on whether or not the passed URL starts with "/2/"
6. Lastly, when the whole thing is said & done, the user gets an alert message that they have to click OK on to continue.

Throughout the process, the user gets passive pop-ups in SharePoint letting them know what's going on. Behind the scenes, the process is also logged in the console for troubleshooting.

Answer 1

I never did figure out what exactly in the script is interfering with the normal ribbon functionality, but it appears to be one of my context calls. Since I finally got my script working the way I wanted after weeks of work, I didn't want to change the script and risk breaking it.

In the environment, users only need maybe 3 functions off the ribbon anyway, so instead I hid the ribbon altogether and replaced those functions with buttons built into my JSLink file on the view (Check In, Check Out, Open in Explorer).

Not a fix, just a Band-Aid. The only reason I can get away with it is because this site is so tightly controlled from a use perspective.