Hi everyone!

After the update (6.x-3.1 to 6.x-3.2) I experienced the problem that if a link have target="onclick = "window.open (this.href); return false;" html tag, after the click not just the new page opens, but the original page loads the target site too.

Sorry for my bad english. :S

Black154

Comments

Status:Needs review» Active

Bad news. I have read somewhere user should not use the target attribute... :-). Can you share the full link wrapped into CODE tags here, please.

Priority:Major» Normal
Status:Active» Postponed (maintainer needs more info)

Code wise I would say - if the href attribute is empty (what should be the case here) you should not see this issue...

Assigned:black154» Unassigned

I'm having a similiar issue. I just updated to the latest 6.x-3.2 version and I have the check boxes checked to track outbound links, etc. And any link that has the normal target="_blank" will pop the new window just fine but also directs the main site to the same destination.

So a link like a href="http://mysite.com" target="_blank" will pop a new window like designed and also change the orginal site to the new url. I need to have the ability to pop a new window and not change the original location.

This only started happening with the latest release. Any help would be greatly appreciated. Thanks for a great module!

Scott

Removed tag abuse

Status:Postponed (maintainer needs more info)» Active
Issue tags:+google analytics, +target, +new window, +blank

Same behaviour for me, also reported by others in http://drupal.org/node/1057688.

All the links with target="_blank" open a new window but also changes the main windows url with the same href of the link.

And also some links working with colorbox-load (modal iframe) start to load the colorbox modal iframe, but suddenly they open the url directly in the main window.

Here some examples behaving wrong with ga 6.x-3.2:
<a href="http://twitter.com/Villa_Acquaviva" title="" target="_blank">Twitter</a>
<a title="" href="http://villaacquaviva.tumblr.com" target="_blank">Blog</a>
<a class="colorbox-load initColorboxLoad-processed cboxElement" title="Video" href="http://www.youtube.com/embed/ZvctkhQES-c?width=640&amp;height=390&amp;iframe=true"><img height="46" width="54" alt="Video Villa Acquaviva" title="Video Relais Villa Acquaviva" src="/sites/www.villacquaviva.com/files/btn-video.png"></a>

reverting to the 6.x-3.1, evrything works like charm.

What else do you need to know Hass?

Tag abuse.

Title:The outbound link tracking, causes error if link opens one in new tab!Custom outbound link tracking with outdated link targets or javascript is broken

For those of you having trouble with _blank, the solution can be found here http://drupal.org/node/1059274

I have the same problem. Disabling "Track outbound links" removes the problem, but that takes that feature away.

Subscribing.

This bug appears to relate to the latest update of googleanalytics.js, with the offending line being #54:
setTimeout('document.location = "' + this.href + '"', 100);

Although this is noted as a necessity for catching all outbound links, in over a year of tracking links without this line of code I haven't noticed a problem so I'm happy to comment this out until a solution is found..

Btw, this bug also occurs on using Ctrl + Click to open a link in a new tab and not just on links using a target attribute..

PS: the name of the _trackEvent associated with this timeout snippet changed in the latest release from 'Outgoing links' to 'Outbound links'.. This is a tad irritating as past and new events are now categorised separately in Analytics..

Same issue, subscribing.

Here are quick rollback patches. But we need to find a better solution.

Thanks for the patch.

Not sure if it will help with the eventual solution, but I noticed from looking at the code in googleanalytics.js and http://www.google.com/support/analytics/bin/answer.py?hl=en&answer=55527 that nowhere do you return false in your code in order to prevent the default browser behavior for the click. You'll notice in Google's example at the link, they return false after the call to recordOutboundLink(). This would prevent the browser from loading the linked page and leave the Javascript to do it. I guess what I'm trying to say is, without a return false, is the Javascript loading the new page as intended? I could be missing something though.

Matt

No, #1057890: Prevent browsers default behavior if monitored links are clicked is correct way, but cannot solve the issue with target and custom js code.

subscribing

Ahh right, preventDefault() is definitely the way to go. To accommodate the target then, I guess you would need to look at the target attribute, if any, and if its '_blank', do a window.open(). I know that's messy, but that may be the only way to accommodate.

Not sure how relevant this is but I noticed the conflict with external links only occurred for anonymous users not logged in users and disabling "Track outbound links" eliminates the problem.

@m4olivei: the problem is we cannot guess what the browser will do. Maybe someone have written very custom js with conditions... I do not like to develop a webbrowser in js :-)

Status:Active» Fixed

Committed rollback patches. Followup in #1057890: Prevent browsers default behavior if monitored links are clicked if there is any light (I guess not).

StatusFileSize
new1.34 KB

Hi

Had this same problem as well, rolled a little patch to allow target="_blank" links to just do their thing. Seems to work for us so far, hasn't broken anything else as yet..

Yeah, I also have written a target exception patch, but struggled about custom javascript later and never made it public.

Subscribing.

hass --

The patch from #1057890: Prevent browsers default behavior if monitored links are clicked seems to prevent targets from working properly. For example, if I set target=_blank, that patch prevents opening the link in a new window/tab. Instead, the link opens in the current window/tab.

The google analytics target _blank.patch on this ticket (from reply #22) is a suitable workaround for the time being, but it doesn't seem like it's the Right answer. Perhaps it should check for != '' rather than == '_blank'...? (it also misses one of the cases where event.preventDefault() was added in the patch from #1057890)

Confirming that patch in #22 is working correctly for me. Thanks michel_b :)

//Christopher

Please use DEV. #22 will not committed.

Ah. So it's fixed in dev? I'll use that then. Thanks :)

//Christopher

This is why this case has a status FIXED

If you use drush 4 to install the dev version remember to update the database from the admin page. Otherwise it will appear as if the dev release does not resolve the issue.

drush dl google_analytics-6.x-3.x-dev

subscribe

No need to subscribe. I can confirm that google_analytics-6.x-3.x-dev does indeed fix this issue.

I confirm the current dev fixes this very scary issue. I recommend publishing a stable version as soon as possible so that not every user of this module has to go hunting for solutions, finding this issue thread and installing the dev version.

If this is fixed on Dev then can we get a new stable release with the change? That way people will see it when they check for updated versions of their modules rather than having to track down this thread.

Subscribing.

Version:6.x-3.2» 7.x-1.x-dev
Status:Fixed» Active

This problem is not fixed for the 7.x-1.x-dev version

I am also affected by this. I provided a patch in #1095970: Track outbound links option and target _blank but it's like in #22.

Version:7.x-1.x-dev» 6.x-3.2
Status:Active» Fixed

Is for sure fixed in 7.x-1.x-dev

subscribing

subscribe

subscribing

Status:Fixed» Active

Comment #39 doesn't make it clear if this has been fixed in the 6.x branch and, if so, in which version.

Looking at the commitlog I see that commits are made without referencing specific issue nodes which makes it harder to track what is happening.

I'm tempted to mark this as critical for the 6.x branch given #1080608: GA on drupal.org needs updating to resolve outbound link command-click problem which affects d.o.

Status:Active» Fixed

#14. All supported branches have been fixed. And on 23. Feb the committ also have the case id logged. If some guys wouldn't have converted to suxxxx Git my life would be much easier.

As far as I can tell, this fix has been applied to dev branches of supported releases, but not any stable releases.

@hass, of the two issues mentioned that you'd like to get into the next stable release, #1070574: Empty page filter if form has been reseted to defaults is now fixed, but #613648: Tracking Zero Result Searches is still active, and seems very open-ended, so I wouldn't expect that to get fixed soon. Any chance we can get a stable release before that's fixed, only including the current fixes?

If you need help referencing issue numbers in commits and/or doing stable release branches in Git, I would be happy to help, and expect many others would as well. I'm sreynen in IRC.

Need some testers of next DEV... #1101136: Create 6.x-3.3 release

If the solution provided is the one in #22 then I think we need more work on this issue.

The target attribute may contain many values other than "_blank", and some of then will open new windows. The following list summarizes the possibilities and expected behavior:

_blank
Open in new window, always.
_self
Open the link in the same frame. This is the default behavior.
_parent
Open in parent frameset. If not in a frame, open in current frame (same as "_self").
_top
Always open in the top frame. If not in a frame, open in current frame (same as "_self").
anything-else
Open in the frame named "anything-else". If no such frame exist, standard behavior is to open a new window with a (single) frame named "anything-else".

So as we see doing just if ( this.target == "_blank") is not enough. I'm so sorry for not providing a patch right now, though it seems to me that writing code to accomplish all situations is somewhat simple.

The patch applied to the dev releases appears to be from #14, not #22.

subscribing

subscribing

Subscribing.

It has been over ten days since the dev was released. I cannot let this go, it also effects the ads on our site.

Same Issue. I can confirm that the latest dev solves the problem.

The problem is not only if there is a target="_blank" attribute but also when you Command+Click(Cntrl+Click) on a link to open it in a new tab. It happens even on the www.drupal.org home page with Command+click on the link in the footer, also on any module page. Disabling "Track outbound links" eliminates the problem on my Drupal installations.

nmlss, what browser are you using? I am using Chrome on a mac and the command+click doesn't bug doesn't happen.

@frob, it's only an issue with outbound links, which means links to pages on domains other than drupal.org. It happens in every browser.

Got it. Confirmed. On my site it also happened on an internal link. It must have been a www or something that through it off.

I can confirm that 6.x-3.3 solves this issue.

Status:Fixed» Closed (fixed)

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

Sorry in advance to bring this one back to life after all the conversation.

I installed the latest dev version, and it worked!... until I moved my website to a subdomain. I'm looking into way to alter the code now.

It seems that the specific issue highlighted here is fixed as of 6.x-3.3. However, it might be worth noting that it also seems that the "click delay" functionality for outbound links (which was ultimately behind this issue) has now been removed. Though this is a relatively small problem, anyone curious about that may best be served by #1580144: Links not tracked in some browsers as jquery click event exits before tracking code finishes.