Links in first panel

[mikestecker]

Thank you for your script!

I have one major issue that seems to be killing me. It seems like all the links inside the first loaded panel throw errors when clicked on. When I advance to the next panel and go back, there is no problem anymore. I was able to replicate this with having it start on a panel burried deep, and it happens then too. It's really strange. What's even stranger is that is doesn't happen with 'regular' links either, just ones that are generated by .NET.

Here is the code generated by .NET for the first panel contents:

You Belong

Select Design

Here's my slider config:

        $(".bulletin-selection-selector ul.bulletin-selection-results").anythingSlider({
            easing:"easeInOutExpo",
            infiniteSlides:false,
            autoPlay:true,
            delay:0,
            startStopped:false,
            animationTime:0,
            hashTags:false,
            buildNextPrevButtons:true,
            buildNavigation:false,
        });

The error I get is: Unspecified error. jquery.min.js line 144 character 314

What I did was modify a version of jQuery, run a alert in a around that error spot and had it alert me with the property it was getting at the time. What I returned was that the links seemed to be wanting to trigger 'slideLeft' and then the number of pixels to slide.

I hope I'm giving you enough information to try and track down what is causing this.

Thanks!

[Mottie]

Hi Mikestecker!

Hmmm, ok I didn't read your issue well enough... I thought the problem you were having was with the cloned panels and IDs in them - that was the reason I pushed version 1.5.7.3. But I just noticed you have the infinite slide feature turned off. I wonder if the problem might be the inline javascript that is being generated. Is there any way to make it unobstrusive?

[mikestecker]

Thank you for getting back to me so quickly! Yeah, I am running the latest version of AnythingSlider. I just grabbed that today. I had turned off infinateSlides because I thought the cloning was causing the problem, but the problem still exists with it turned off. I was wondering the same thing about the inline javascript, but I tried to do a manual insert of an inline javascript, one that just does an alert on click, and that seemed to work fine. The next thought I had was with the way .NET outputs their javascript and how ugly it is. I'm not a .NET developer, so I don't know much about how to clean that up, but I've spoken with my developer and he doesn't seem think that's the problem. (Although he likes to blame every problem on jQuery and seems a bit lazy on things like this.)

But the strange thing is that these scripts work on all the other panels, just not the one that loads in when the script is initialized. Also, once you to to the next panel and go back to the first, it all seems to work. It's only when you click on the links inside the first displayed panel, and only giving the errors until it is moved off that panel.

[Mottie]

That is very odd... I wonder if the slider is being called inside a $(document).ready(...) function? Also, I guess I'm not clear on this (I don't know much about .NET), but is everything in place when the slider is initialized?

[Mottie]

Hi Mike!

Did you ever resolve this issue? If not, do you have an example site I could look at to help diagnose the problem?

[rayrad]

I have run in to the same problem with an ASP.NET site (using the Sitefinity CMS) system. I have narrowed the problem down to lines 187-189 in v1.5.2 of jquery.anythingslider.js. The lines read:

        base.$el.find('li.cloned').find('a').each(function(){ // disable all links in the cloned panels
            $(this).replaceWith('<span>' + $(this).text() + '</a>');
        });

I am not a github (much less git) user, but a little searching yielded the following comment from the v1.5.1 of the release notes:

"Fixed a problem with clicking control links inside a slider (links that take the slider to other panels). This also required that all links in the cloned panels are modified (changed into spans) – this will mess up any FX you add to these links but only in the first and last panels."

I can also see that the basic functionality to remove the links is still in the current 1.5.9 version (lines 191-195), albeit modified some. I also believe we tried the latest already and it did not resolve the issue for us.

In v1.5.2, commenting out lines 187-188 fixes the immediate problem for us, but I don't what else it might break as I don't understand how the control panels are used and why it is important to remove the links in the first and last panes, so if an official fix for this came out it would be much preferred. However, I also acknowledge that this is a volunteer effort, so the mere existence of the library is greatly appreciated, as well as the work of those who keep it alive and improving.

If anyone wants to dig in to this further, I could point you at the site being built (out of band, though, since it is for a client and not yet public). However, it is part of a somewhat complex hierarchy of ASP.NET controls, so just viewing the generated HTML may or may not be useful.

Thanks,
Dave Parker

[Mottie]

@dave

Hmm, those lines (187-189) were included because of links inside the cloned panel could be tabbed into and thus causing the positioning of the slides to be off, the targeted link would end up at the left edge not accounting for the left edge of the image.

Looking at it now with fresh eyes, I had a duh moment... just replace that code with this:

base.$el.find('li.cloned').each(function(){
  // disable all <a> in cloned panels to prevent shifting the panels by tabbing
  $(this).find('a').attr('disabled', 'disabled');
  $(this).find('[id]').removeAttr('id');
});

And that should stop the problem.

Another alternative would be to turn off the infinite slide feature (wrapping from last to first, or first to last) by setting the "infiniteSlides" option to false. Either way, I'll update the version with this code change.

[rayrad]

Yes, that seems to work in the tests I have done so far. Thank you very much.

[Mottie]

@Dave-coherent and @mikestecker: Thanks for reporting this issue, it has been included in version 1.5.10.