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

JS Tracker: enable alwaysUseSendBeacon by default #13681

Closed
mattab opened this issue Nov 7, 2018 · 9 comments · Fixed by #15405
Closed

JS Tracker: enable alwaysUseSendBeacon by default #13681

mattab opened this issue Nov 7, 2018 · 9 comments · Fixed by #15405
Assignees
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Milestone

Comments

@mattab
Copy link
Member

mattab commented Nov 7, 2018

assuming that the trial went well, then in Matomo 4.0.0 we would like to enable the feature alwaysUseSendBeacon by default.

see #13451 #6641

@mattab mattab added the Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. label Nov 7, 2018
@mattab mattab added this to the 4.0.0 milestone Nov 7, 2018
@Findus23
Copy link
Member

Findus23 commented Nov 8, 2018

Keep in mind that a large portion of users have sendbeacon disabled for privacy reasons. Disabling in Firefox via the about:config key beacon.enabled removes navigator.sendBeacon so the fallback should work.
The popular open source adblocker uBlock origin also has a (enabled by default) setting to remove sendbeacon and <a ping>, but in my test the request still worked.

So we should do a lot of testing to avoid the fallback not working (e.g. if navigator.sendBeacon still exists, but is blocked).

@tsteur
Copy link
Member

tsteur commented Nov 8, 2018

One thing to keep in mind is that the callback parameter won't work anymore (because there is no event or what so ever when the request is finished). Some users rely on this see eg #13679 (comment)

@tsteur
Copy link
Member

tsteur commented Nov 8, 2018

Actually, callbacks won't be a problem cause we call the callback if the browser confirms it sent the request.

@mattab
Copy link
Member Author

mattab commented Mar 14, 2019

  • Another concern is that if all send beacon requests are sent as POST then these request could not be replayed (FAQ), which could result in rare cases (maintenance, downtime) in lost data when recovering logs. (will need to document this more clearly in this FAQ which actions wouldn't be likely replayed because of send beacon)

@tsteur
Copy link
Member

tsteur commented Mar 14, 2019

They are sent as request parameters unless the request is large AFAIK

@mattab
Copy link
Member Author

mattab commented Oct 20, 2019

Also we just found out that when closing the tab/window, Chrome seems to not execute sendBeacon on beforeunload unfortunately!? so we wouldn't want to rely on this feature probably...

@tsteur
Copy link
Member

tsteur commented Oct 20, 2019

@mattab it's still good for sending requests when the browser closes. It will be more reliable than the XHR. It just means we can't collect all requests, optimize them, and send them at the end of the page view. Like instead of pinging Matomo every 15s using heartbeat it would have better to send only one request when the browser closes... but this won't work reliably

@sgiehl
Copy link
Member

sgiehl commented Jan 25, 2020

fixed with #15405, will be included in Matomo 4

@sgiehl sgiehl closed this as completed Jan 25, 2020
@tsteur
Copy link
Member

tsteur commented Jun 11, 2020

BTW a benefit is that it will improve page load time when using send beacon.

@mattab mattab added the Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical. label Sep 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants