We have one page that for just one user is occasionally returning nothing but a hash symbol (#). This page works perfectly fine for other users all of the time, and perfectly fine for this user much of the time. We cannot reproduce the problem internally. Unfortunately, this problem is sporadic and occurs within a modal dialog, so we cannot really test outside the modal dialog and we cannot get the html source when it does occur.
I recall running into a similar problem once before. Some random page was returning just a pound sign. Being able to see what was actually going on since it wasn't in a modal dialog, and having it occur in a dev environment, I resolved it pretty quickly then. But it was a while ago and I can't recall any details of the incident. Has anyone else ever seen CF do this before? Any thoughts on what might cause it?
I would be sure that you are not caching the ajax pages, also there could be an extra hash somewhere like on a color ##ffffff for example and certain browser standards are allowing it while it crashed and shows # in others, I would also check your markup for any extra tags, especially closing ones. I have seen this with dialog before. I would love to see code on this if you have it.
Related
I have this code for many years, implementing TCFv2 cookie consent with Google Funding Choices.
window.googlefc.callbackQueue.push({
'CONSENT_DATA_READY': function () {
/* __tcfapi is undefined!! */
return __tcfapi('addEventListener', 2, function (tcData, success) {
if (success
&& tcData.gdprApplies
&& (tcData.eventStatus === 'tcloaded' || tcData.eventStatus === 'useractioncomplete')
&& tcData.purpose.consents[1]) {
...
}
});
}
});
It works 99.99% of the time, it has appeared so.
However, today, one of my Chrome profiles seem to have got "broken", in that whenever this CONSENT_DATA_READY event is triggered, __tcfapi is not defined.
I tried a number of things, like making sure all extensions are disabled, close Chrome and re-open it, clear just my domain's cookies, etc, but nothing worked. All other Chrome profiles were working well all the time.
I compared the "Sources" tab in DevTools between two Chrome profiles (on the same webpage), and the one working well had a few more scripts loaded and iframes loaded (TCF-specific iframes).
Only when I cleared all the cookies (including the "google.com" scoped cookies), this issue got fixed.
--
I've just released a temporary piece of code, that checks if __tcfapi is undefined in that spot and reports that to the server (this user data will be fully erased as soon as this test is complete), and I see that a small subset of my users is having this issue right now.
EDIT 18 Dec - 181 distinct European users reported so far.
--
I'm not able to find any solution by doing some research. I found someone on Reddit (in the comments) having the same issue as me, and they "resolved" by just removing the event. Other places that report issues with __tcfapi seem to be a slightly different error, like __tcfapi is not a function, which is not the issue I'm having.
--
This looks like it's a bug from Google Funding Choices, but does anyone have any idea how to "auto-fix" this or what can I do so that these users will stop getting this error and proceed as expected?
NB: This is a complete re-edit to reflect the discussion with the questioner.
Some thoughts.
On Error 2.1a
I first suspected that your problem may correspond to Error 2.1a, which is also indicated by the discussion in the GFC community thread you pointed at. The suggested official solution would be to check whether getTCData returns TCData.eventStatus = 'tcloaded' first.
That may work in other cases, however you pointed out -- and added corresponding code -- that you already check on tcloaded but the problem of an undefined __tcfapi seems to occur even before that flag is even created.
Another look on the problem's origin
The GFC community thread of 2020, the TCFv2 standardization history
and the circumstance that the thread has been closed indicate that the problem mainly existed before the final implementation of TFCv2 in Google Funding Choices. That corresponds to the fact that the described behavior infringes the TCFv2 Specification in the following:
Every consent manager MUST provide the following API function: __tcfapi(command, version, callback, parameter). The function __tcfapi must always be a function and cannot be any other type, even if only temporarily on initialization – the API must be able to handle calls at all times.
However, it's not unreasonable that there are still some older implementations out there in the wild which may cause this problem at some clients.
Interestingly enough, you observed that on your side one of your Chrome profiles got "broken" in the described way and only the clearing of all cookies, incl. the "google.com" scoped ones, fixed the issue.
And now?
At first it would be interesting to check for
the tcfPolicyVersion used by the problematic clients, and
differences between the temporarily "broken" Chrome profile and the other, working ones.
It also can't hurt to take a look on the official site on Publisher integration with the IAB TCF v2.0 in case some useful gem is hidden which we currently overlook.
On the other hand it could well be that this -- probably rare -- problem will resolve by itself over time when
all clients have been updated and support the final implementation of TCFv2, and/or
your affected users either someday delete all their Google domained cookies themselves or those time out, and fresh cookies get introduced.
It seems reasonable to assume, that your current patch -- to check whether __tcfapi is undefined -- may be indeed a (fairish) suitable fix, at least for now.
I just worked my way through the Ember tutorial app. The only thing that does not work as expected is the search box. It happens from time to time that not all data is displayed if I hit backspace multiple times to clear the search box.
After pressing Backspace all data is than displayed again.
BTW: The final tutorial app from GitHub (https://github.com/ember-learn/super-rentals) shows the same problem.
The behavior you are seeing is a known issue reflected in https://github.com/emberjs/guides/issues/1572
That tutorial code for autocomplete needs to be improved upon to better handle the asynchronous behavior.
I have a number of dynamically generated like buttons on a site (http://www.thepropaganda.com), and so I use FB.XFBML.parse to generate them all. For some reason the parser always gets into a loop and repeatedly generates "domain and protocol must match" errors as per FB.SO Question 3577947. All the facebook social plugins are created correctly.
I understand what the errors are, and they're not really a problem, other than that there's thousands of them. Funnily enough this doesn't happen at all in incognito.
I'd really like to know what's going on here, as it's a live site for a paying client.
No idea why that's occurring but if it doesn't happen in incognito I'm assuming it's something to do with a cookie/session variable.
I would have added this as a comment but I need 50 rep to do it :(
I have a CF9 site set up locally on OSX Snow Leopard, and it's started to behave very strangely - probably about 1 out of every 5 times I load any page in the site, it will throw a 'Cannot find CFML template for custom tag' error. I just refresh the page and then everything works fine. It can happen on any page, but it never happens consistently with any one page. Furthermore, this doesn't happen at all on the live server when the code is checked in through SVN, so I figure it has to be some kind of configuration problem on my local instance. I can still do my work, but it's pretty annoying having to refresh pages ALL the time. Has anyone run into similar difficulties?
Try using <cfmodule template="pathTo/yourTag.cfm"> rather than <cf_yourtag>, so you can specify the exact location of the template (in case the server is getting confused as to where it resides).
FYI, this is based on a tip from Raymond Camden's blog post: http://www.raymondcamden.com/index.cfm/2006/8/17/ColdFusion-Custom-Tag-Tips
Chris, odd that I should run into your question now, as this just started happening to me last night. I have all of my CF errors being emailed to me, and I am seeing that similar problems are happening across multiple sites that all run the same software, some of which haven't been touched in a long time. That got me thinking, it's probably a corrupt compiled template in the CF cache. You can recompile the template by making a slight change to it, say add an extra line or a comment or something, then access the site again. Or, purge the whole cache and let CF rebuild everything, which is likely what I'll do since who knows what else might be affected.
Clearing the Cache in Coldfusion Production server
Anyone else ever have the Firefox toolbar "refresh" button not work for a particular page? Works everywhere else. Firefox 3.6.15. Any clues?
EDIT: For what it's worth, I later set network.http.use-cache false, and the problem went away. No idea whether that was much more than coincidence, though.
There is not a lot of detail to go on in your question, but what will often happen is that firefox will cache certain elements of the page and not actually re-fetch them from the server. Try using the TamperData Add-On for firefox to see exactly what data is being transferred from the web server.
You can also just try a Ctrl-F5 to do a force page reload.
While I can't say that I have had that problem, most "weird" behaviors I've run into were due to extensions. You might try disabling some of the more intrusive ones. Greasemonkey perhaps?