Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Amplitude callback isn't fired if a user enables adblock #142

Closed
tanin47 opened this issue May 15, 2018 · 6 comments · Fixed by #342
Closed

Amplitude callback isn't fired if a user enables adblock #142

tanin47 opened this issue May 15, 2018 · 6 comments · Fixed by #342

Comments

@tanin47
Copy link

tanin47 commented May 15, 2018

One of our developers enables adblock and have found that the callback of logEvent isn't fired.

I wonder if we can make the callback fires even the sending-data-to-amplitude action fails.

Thank you

@blazzy
Copy link
Contributor

blazzy commented Mar 27, 2019

Hi @tanin47, Could you explain why you would want this?

Usually you should be firing and forgetting when you invoke logEvent and should not have any application logic depend on an event being logged.

@pioug
Copy link

pioug commented Oct 12, 2020

Well in my case, I need to log events before the visitor leaves a page so opt_callback must be called.

donaldpipowitch added a commit to donaldpipowitch/Amplitude-JavaScript that referenced this issue Dec 7, 2020
jooohhn pushed a commit that referenced this issue Jan 7, 2021
jooohhn added a commit that referenced this issue Jan 8, 2021
…are dropped (#342)

* fixes #142

* fix error handling

* revert commit

* extend callback interface

* fix callback call for deleted events

* Added tests

* single letter variable nit

Co-authored-by: Donald Pipowitch <pipo@senaeh.de>
github-actions bot pushed a commit that referenced this issue Jan 11, 2021
## [7.4.1](v7.4.0...v7.4.1) (2021-01-11)

### Bug Fixes

* Bug with logEvent callbacks not being called when unsent events are dropped  ([#342](#342)) ([f243a92](f243a92)), closes [#142](#142)
@mattlong
Copy link

I'm still observing the behavior described in this issue. Using the JS snippet currently on https://developers.amplitude.com/docs/javascript that attempts to load version 8.1.0. With uBlock Origin enabled on Chrome v89, logEvent callbacks are not triggered when attempting to track outbound link clicks.

Related, the console.log statement from the snippet (console.log("[Amplitude] Error: could not load SDK")) isn't actually being logged. An active ad blocker seems like a situation when when I'd expect to see it triggered.

@yuhao900914
Copy link
Contributor

@mattlong Can you provide more detail about how you implement the Amplitude code?
@jooohhn @ajhorst Could you take a look at this issue?

@yuhao900914 yuhao900914 reopened this Apr 14, 2021
@mattlong
Copy link

mattlong commented Apr 14, 2021

Sure, after including the Amplitude snippet I define the following function:

<script>
function outboundClick(e) {
  amplitude.getInstance().logEvent("Outbound Link Clicked", null, function() {
    window.location= e.target.href;
  });
  return false;
}
</script>

And use it in my HTML like this:

<a onclick="return outboundClick(event)" href="https://amplitude.com/">Check out Amplitude</a>

With uBlock Origin disabled, it all works as expected: The event show up in amplitude and the browser navigates to https://amplitude.com/.
With uBlock Origin enabled (and the Amplitude client is blocked from loading), nothing happens when clicking the link.

My current workaround is to add a check to see if Amplitude was successfully loaded at the top of outboundClick like so:

<script>
function outboundClickWithWorkaround(e) {
  if (!e.amplitude.runQueuedFunctions) {
    return;  // Don't return false so links will behave like normal
  }

  amplitude.getInstance().logEvent("Outbound Link Clicked", null, function() {
    window.location= e.target.href;
  });
  return false;
}
</script>

This workaround is working fine for me, but isn't ideal since I'm having to peak inside the implementation of the Amplitude client.

@ajhorst
Copy link
Contributor

ajhorst commented Jul 30, 2021

this issue is fixed by #413 , which was released with v8.4.0

The existing callback for logEvent has specific logic to only be called once (either right away if logEvent is misconfigured, or on logging success), so there is a second callback to logEvent that is called when logEvent fails, e.g when the user has an adblocker enabled

@ajhorst ajhorst closed this as completed Jul 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants