Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#22 | google analytics target _blank.patch | 1.34 KB | michel_v |
#14 | ga_rollback_setTimeout_location-D6.patch | 1.81 KB | hass |
#14 | ga_rollback_setTimeout_location-D7.patch | 1.82 KB | hass |
Comments
Comment #1
hass CreditAttribution: hass commentedBad news. I have read somewhere user should not use the target attribute... :-). Can you share the full link wrapped into CODE tags here, please.
Comment #2
hass CreditAttribution: hass commentedCode wise I would say - if the href attribute is empty (what should be the case here) you should not see this issue...
Comment #3
hass CreditAttribution: hass commentedComment #4
orange peel CreditAttribution: orange peel commentedI'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
Comment #5
hass CreditAttribution: hass commentedRemoved tag abuse
Comment #6
d.sibaud CreditAttribution: d.sibaud commentedSame 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&height=390&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?
Comment #7
hass CreditAttribution: hass commentedTag abuse.
Comment #8
hass CreditAttribution: hass commentedComment #9
FranciscoLuz CreditAttribution: FranciscoLuz commentedFor those of you having trouble with _blank, the solution can be found here http://drupal.org/node/1059274
Comment #10
naxoc CreditAttribution: naxoc commentedI have the same problem. Disabling "Track outbound links" removes the problem, but that takes that feature away.
Comment #11
anrikun CreditAttribution: anrikun commentedSubscribing.
Comment #12
hypertexture CreditAttribution: hypertexture commentedThis 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..
Comment #13
Danny EnglanderSame issue, subscribing.
Comment #14
hass CreditAttribution: hass commentedHere are quick rollback patches. But we need to find a better solution.
Comment #15
m4oliveiThanks 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
Comment #16
hass CreditAttribution: hass commentedNo, #1057890: Prevent browsers default behavior if monitored links are clicked is correct way, but cannot solve the issue with target and custom js code.
Comment #17
izmeez CreditAttribution: izmeez commentedsubscribing
Comment #18
m4oliveiAhh 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.
Comment #19
izmeez CreditAttribution: izmeez commentedNot 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.
Comment #20
hass CreditAttribution: hass commented@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 :-)
Comment #21
hass CreditAttribution: hass commentedCommitted rollback patches. Followup in #1057890: Prevent browsers default behavior if monitored links are clicked if there is any light (I guess not).
Comment #22
michel_v CreditAttribution: michel_v commentedHi
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..
Comment #23
hass CreditAttribution: hass commentedYeah, I also have written a target exception patch, but struggled about custom javascript later and never made it public.
Comment #24
jerry CreditAttribution: jerry commentedSubscribing.
Comment #25
jsquyres CreditAttribution: jsquyres commentedhass --
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)
Comment #26
cato CreditAttribution: cato commentedConfirming that patch in #22 is working correctly for me. Thanks michel_b :)
//Christopher
Comment #27
hass CreditAttribution: hass commentedPlease use DEV. #22 will not committed.
Comment #28
cato CreditAttribution: cato commentedAh. So it's fixed in dev? I'll use that then. Thanks :)
//Christopher
Comment #29
hass CreditAttribution: hass commentedThis is why this case has a status FIXED
Comment #30
theMusician CreditAttribution: theMusician commentedIf 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
Comment #31
boftx CreditAttribution: boftx commentedsubscribe
Comment #32
mcfilms CreditAttribution: mcfilms commentedNo need to subscribe. I can confirm that google_analytics-6.x-3.x-dev does indeed fix this issue.
Comment #33
Vacilando CreditAttribution: Vacilando commentedI 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.
Comment #34
Gekiboy CreditAttribution: Gekiboy commentedIf 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.
Comment #35
hass CreditAttribution: hass commentedYes, after #1070574: Empty page filter if form has been reseted to defaults and maybe #613648: Tracking Zero Result Searches is fixed.
Comment #36
opsidao CreditAttribution: opsidao commentedSubscribing.
Comment #37
joostvdl CreditAttribution: joostvdl commentedThis problem is not fixed for the 7.x-1.x-dev version
Comment #38
kotnik CreditAttribution: kotnik commentedI am also affected by this. I provided a patch in #1095970: Track outbound links option and target _blank but it's like in #22.
Comment #39
hass CreditAttribution: hass commentedIs for sure fixed in 7.x-1.x-dev
Comment #40
nelslynn CreditAttribution: nelslynn commentedsubscribing
Comment #41
beyond67 CreditAttribution: beyond67 commentedsubscribe
Comment #42
drupalsteve CreditAttribution: drupalsteve commentedsubscribing
Comment #43
gregglesComment #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.
Comment #44
hass CreditAttribution: hass commented#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.
Comment #45
sreynen CreditAttribution: sreynen commentedAs 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.
Comment #46
hass CreditAttribution: hass commentedNeed some testers of next DEV... #1101136: Create 6.x-3.3 release
Comment #47
flaviovs CreditAttribution: flaviovs commentedIf 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:
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.Comment #48
sreynen CreditAttribution: sreynen commentedThe patch applied to the dev releases appears to be from #14, not #22.
Comment #49
BBCsubscribing
Comment #50
BBCsubscribing
Comment #51
frobSubscribing.
It has been over ten days since the dev was released. I cannot let this go, it also effects the ads on our site.
Comment #52
Poieo CreditAttribution: Poieo commentedSame Issue. I can confirm that the latest dev solves the problem.
Comment #53
nnmlss CreditAttribution: nnmlss commentedThe 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.
Comment #54
frobnmlss, what browser are you using? I am using Chrome on a mac and the command+click doesn't bug doesn't happen.
Comment #55
sreynen CreditAttribution: sreynen commented@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.
Comment #56
frobGot it. Confirmed. On my site it also happened on an internal link. It must have been a www or something that through it off.
Comment #57
achtonI can confirm that 6.x-3.3 solves this issue.
Comment #59
owntheweb CreditAttribution: owntheweb commentedSorry 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.
Comment #60
rjacobs CreditAttribution: rjacobs commentedIt 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.