Chris Lloyd

Woops, there’s a stray ^M at the end of the line there.

I think that’s fine, it looked to me like the Safari performance counters did just have some kind of bug to do with the back button. I couldn’t find a way to make them behave properly.

Cheers,

– Chris

Hi Camu,

Well I was going to filter them myself temporarily until I figured out what was causing it, but then I figured out what was causing it : )

I assume it’s something that can be resolved in the JS, since it doesn’t affect other browsers. I’d be happy to look into it (at least to find the reason Safari behaves differently, perhaps the way it treats uninitialized values very early in the page load process? (because on back button it loads so quickly) (complete guess)) but I don’t know if I have access to the unminified JS?

This is caused by: https://core.trac.www.ads-software.com/ticket/27982 – should be fixed in upcoming 4.1 but I haven’t checked it myself : )

wp-slimstat/admin/view/wp-slimstat-db.php:20 is the one that triggers the issue

Hi,

That info’s in the FAQ: https://www.ads-software.com/plugins/wp-slimstat/faq/
Under “Can I track clicks and other events happening on the page?”

It’s somehow related to the UAN ads network, if the data returned from that service is corrupt then you get that effect intermittently. If you turn UAN off in the Advanced settings tab then the problem should go away.

Yep, I noticed that in the changelog so I knew right where to look ??

Issuing:

ALTER TABLE wp_slim_browsers CHANGE browser_id browser_id SMALLINT(8) UNSIGNED NOT NULL AUTO_INCREMENT;

fixed it up no problem.