I am getting a page error in IE8 which breaks all javascript on the page (for dynamic menu, lightbox modules). Invalid argument, Line 65, character 174, Code: 0 in extlink.js
Everything works fine in Firefox and Safari, and by disabling the module the page returns no errors and the other javascript actions work fine.

Thanks

CommentFileSizeAuthor
#2 screenshot.png40.14 KBdivbox
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

Status: Active » Postponed (maintainer needs more info)

I am unable to confirm this problem in any version of IE (6/7/8).

divbox’s picture

FileSize
40.14 KB

hello,

i'm getting the same error.
you can see this error on this url

http://dev.thegeorgetowndish.com/thescene

the 2nd block in right column (Friends of Quinn) is showing 3 external link icons. one next to title (Friends of Quinn) and one next to headline (Thirty Inches of Snow) and one at bottom of copy block. The headline is not a link though, but it's trying to attach to it.
IE is trying to attach and can't. which generates the script error. the icon only appears in FF/Safari for me, which don't generate any script errors.
it should not be attaching to that headline though, as its not a link.

this block is driven by views (plain, no slideshow or cycle). and its pulling content that is inserted into drupal via RSS aggregation. going to look over the view/rss pull to see if a link is in there hidden somehow.

thanks!!

div

divbox’s picture

Update:

Looking at the generated source, it's adding a link before the copy block. Not sure why. But there is nothing inside the A tags. Perhaps that is why this error is being thrown?

      <div class="view-content">
        <div class="views-row views-row-1 views-row-odd views-row-first views-row-last">
    
<a href="/node/355"><span class="author-highlight">by Quinn Bradlee</span></a>
<br>

<span class="user-picture"><a href="/node/355"><img src="/sites/default/files/user-pictures/picture-29.jpg"></a></span>

<strong>Thirty Inches of Snow</strong>

<a target="_blank" class="ext" href="http://www.friendsofquinn.com/share/c/16684/1342/thirty-inches-snow"></a><span class="ext"></span>

<p><a target="_blank" class="ext" href="http://www.friendsofquinn.com/share/c/16684/1342/thirty-inches-snow">Every year at Christmas I remember the times when I was little; I remember leaving cookies for and milk for Santa. I also remember that after my parents would put me to bed I would go to my other room (or my playroom as I called it), and look out one of these two big windows that I had. I would...</a><span class="ext"></span>
  </p>

</div>
    </div>

divbox’s picture

Update:

Apologies for the update-itus :)

I have narrowed this down. The copy block that was displaying through views was set to trim the output, on a word boundary and to add an ellipsis. When i un-checked the box to trim the output and just display the entire contents, the additional ext link icon went away, and then script error stopped. (checking the trim box, and un-checking word boundary and ellipsis still caused the error)

The copy in question was surrounded by <P> tags, so when it trimmed it, it removed the ending

tag, and I think this is where the script error comes from. If I trim this copy w/ my own trim php code, and put a closing on the end, the error does not happen.

So this looks like somehow when views trims the string, ext link tries to add the ext link icon before (and after) that piece of text. IE was chocking on the "before" icon, not the after. W/out views doing the trimming, the icon only appears after and the script error goes way.

After trying a few things, all of which did not prevent the 2nd ext link icon, I went back to views, and went back to trim the output. I also checked the "strip html tags" box, and the P tags are now gone and now the icon is not there a 2nd time.

So I'm not sure I'd say this is a bug, or how the content was being used. Perhaps extlink.js can check for missing closing tag before trying to put link before. Or maybe just an update to docs informing users to double check that their tags are all closed properly.

div

quicksketch’s picture

Category: bug » support
Status: Postponed (maintainer needs more info) » Fixed

Thanks for your sleuthing divbox, that certainly would have been hard to deduce alone. An unclosed tag would certainly make things difficult. Some browsers (like Firefox) actually rearrange the DOM to make sense and correct HTML mistakes. My guess is that your ending code looked something like this: <a href="#"><p>something</a></p>. Note the mismatch between the opening and closing A and P tags. In such scenarios I don't think there's much to be done by External Links, though in truth you probably saved yourself more than just one problem by stripping out the HTML before trimming the output in Views.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.