arisoft

The bug is reported a month ago and the js-code is the same as it was two months ago. It is possible that this kind of minor bug will be fixed silently without specific announcement. How did you get the idea that it was repaired?

Well, being hesitant is the correct approach, of course. But rest assured, that extension is not evil If you want you can always download the file first and extract the contents and then check them with an editor for any suspicious stuff. Sadly, it doesn't work. FF reports that it is corrupted. And we should continue to ping GC until the issue is resolved. The extension file is an ordinary zip file. Try to unzip it first. Then you can review the contents and rebuild your own version if you want to be absolutely sure. Anyway the extension is already rewiewed and signed by Mozilla. The GCHQ (Not the British one ) already knows the problem, but their experts did not find the solution for the problem - yet. Meanwhile our options are limited. Either suffer from the bug or use the temporary fix. ps. I found that the original download page for unofficial version http://geo.arisoft.fi/mcwb/index.html did not contain link to the the official version of the extension. This may explain the error you saw. The link is now fixed.

Some new findings about this subject. The suspected js-code actually has been reviewed by someone. The original version did not have comments at all, but now the code is well documented. In the beginning there is the most revealing new comment line: //You should realy get rid of this file when you can. Actually there is just few lines of dangerous code you should get rid but this is a good start! The current code does not show the number of unread messages. That is why my "fixed version" shows the numbers slightly shifted. This seems to be the only relevant change so I decided not to update these new comments to my Firefox/Chrome extension. ps. Please, do not get rid of the separate script file until you get it working properly. It is much easier to replace one specific script instead of the core-js.

You have to change the timezone until the date match. For example, I live in Finland and my time zone is set to Central Time (UTC-6) to get correct dates. In most cases the needed offset is -8 hours.

Try this https://www.geocaching.com/account/settings/preferences

There is a long lived time zone bug in processing of drafts (field notes). Just change your time zone in your profile settings until the time match. For example, I have adjusted my time zone setting -8 hours from normal to get correct date in drafts (field notes).

Communication is encrypted. I have no way to tell what is going on. Due to encryption I have no idea about the version, but the last update to the app I used was made at 2013. Description says: "Secure and official geocaching.com access. Powered by Geocaching Live." If this is question about dropped support then the app should stop working. As far as I see the support has already dropped for all versions. But the idea of using API-versions is to maintain functionality of old applications while developing new ones. If there is no "support" there should be no modifications either.

I am sorry to interrupt this speculative discussion. Because this bug definitely have impact to my daily life and it seems that nobody knows who to blame on it, I made some research with my network protocol analyzer. The assumption was that field notes with wrong time zone from unsupported old applications somehow bypass the so called API-interface. My application is called "Neongeo" and it has already been unsupported for years. I did one fieldnote using this application and tracked all communication during the event. What I found is worrying me. I saw only communication between api.Groundspeak.com and my phone. Because there is no change that my applications has been changed, I am pretty sure that api.Groundspeak.com has been modified to shift my field notes for 8 hours.

Good news! Now it is official If you have experienced your browser to go completely stuck when using geocaching.com site, the problem is very likely due to a problem with the javascript that you can avoid by using this add-on. For Firefox the fix is now available from https://addons.mozilla.org/addon/message_center_widget_blocker/ For Chrome and compatibles the fix is available from https://chrome.google.com/webstore/detail/message-center-widget-blo/cngeggmoenbomonegnpgohbnldhgcjgb

The basic idea of API-solutions is to avoid future changes in the way the data is presented for applications. This idea got somehow broken few months ago. I waited a while for immediate fix and now there is more more unexpected changes in the way how corrected coordinates are presented in the API. To fix the fieldnote timing problem, I changed my time zone from Finland to Canada (-8 hours). The corrected coordinates problem I can handle the same old way I was used before this feature was published to API years ago. You, at Groudspeak, have to break little more to make my long lived mobile app totally unusable.

I can not say wether the bug is in Firefox or in the javascript code. It is kind of mystery to me. My simple solution is to just get rid of unnecessary code to avoid the bug anyway. My friend took a photograph of the screen, when it happened to him. Perhaps the Print Screen button with OCR tool could save the log while you are waiting the fix.

Queue Position: 98 of 308. I am almost sure that this will be published this year. I have not noticed even a single freezing in Firefox after this fix. What experiences do others have?

I found this problem in my own device recently. No problems with corrected coordinates from the day when this feature released - until now. Failure seems to be dependent on some unknown parameters. Old caches works fine but new caches does not go right. I found this behaviour first time when I was hunting for FTF and the mobile device was my only source of the solved coordinates and the cache was still at the bogus on the map... Then I luckily found, that in these cases, when coordinates are not corrected, I can see an additional waypoint which is named "(null)". I can live with these null-waypoints but I hope this feature will be fixed to API at some day.

Not at all! It is on the right track. Queue Position: 199 of 319 (It was about 300 at the beginning) Reviewing extensions is not like reviewing geocaches. It is much slower. Additional questions have not yet been asked. Anyway... if you know what you are doing, you can review the extension by yourself. It happens to be plain javascript in a zip file.

Thank you for the notice! I put a link to the official version too early before it was reviewed. Extension for Chrome and compatibles is already published in Chrome Web Store and Firefox version is waiting for review. Meanwhile it can be installed only from the homepage.

Try this

Offset depends on zoom level. In this case you are searching the cache from wrong building from wrong street, much longer than allowed saturation distance between caches. And finally! The headquarters have been moved to Canada.

Map without search filters Map with search filters Sure you know which one is correct

Due to the error messages I suspect that the problem could be the polling message center widget on the top corner. It seems to crash sometimes the browser when clicking a page where it is loaded. To prevent the widget running on background I made a Firefox add-on which modifies it to run only once when the page is loaded. You can install it from here

Two features of Message Center does not work any more. 1) Link "Message this owner" from any cache page does not open converstion to the CO as it did before. It works just like the "Messages" link on the top. I am sure this is not intented to work that way. 2) The original version attached images automatically to the message when a image file was dragged and dropped to the message center. Now it does not. Actually it just opens the local image and discards any message written in to the message box instead. FYI: I am using Firefox browser.

Today I got an email notification about a new mystery cache. The message was very brief. In the source code I found this Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 R28gZmluZCA6IA== Few days ago I got a slightly longer email. (As you see, I do not read the HTML formatted email for security reasons.) I hope that this is just a temporary feature. May be there could be some more fields in the plain text formatted part but even the link would be fine.

Replying to the Message Center notification email does not appear in the message center any more. No error message is bounced back and no message is shown in the MC. This feature worked earlier with the same device setup.

As a cache owner I read new log entries as soon as possible. For me, any new log which does not contain information about the experience is worthless. I found a solution - I created a filter in my mail server which sends all too short log entries to the black hole. My idea is: "What I do not see, is not any problem for me." Unfortinately this kind of filter is quite difficult to construct for most users, because the log message is not sent in plaintext format. I hope that Groundspeak could offer this kind of "spam" message filter option in the user account settings.

Näissä on tosiaan ollut monenlaista ratkaisua, joten pelkkiä tehtyjä esimerkkejä tutkaillen selkeän näkemyksen saaminen lienee hyvin vaikeaa. Ohjetekstin sanamuoto jättää paljon mielikuvituksen varaan. Jos puretaan vaatimuket osiin, niin niihin on helpompi kommentoida. Tämä vaatimus koskee samanlaisena kaikkia geokätköjä tradista mysteeriin, joten vaatimus ei sisällä mitään uutta. Tässä sallitaan lisävihjeiden antaminen kätkölle. Sikäli erikoista tuon sanan "may" käyttö, että tämä ei siis olekaan vaatimus. Letterbox hybridissä ei siis tarvitsisi olla koordinaattien lisäksi muita vihjeitä. Luulen kuitenkin, että yleensä tämä mielletään juuri päinvastoin, että näissä tulisi olla nokkelia vihjeitä, joiden avulla voisi välttää GPS:n käyttämisosion. Lisävihjeitä (paikan spoilaaviakin) saa laittaa normaaleille geokätköille, joten tämäkään kohta ei oikesti sisällä mitään uutta. Tämä näyttäisi rajoittavan näitä vapaaehtoisia lisävihjeitä niin, että lisävihjeiden käyttäminen olisi oltava etsijälle vapaaehtoista. Mukana olisi siis oltava aina myös koordinaatit. Normaalin geokätkön vaatimusten lisäksi edellä sallitut GPS:n käytön ohittavat lisävihjeet eivät siis saa olla kätkön löytämisen kannalta pakollisia. Tämä kohta on ehkä vaikea ymmärtää, koska pitäisi käsittää mihin tässä lopulta pyritään. Mutta tämäkin kohta taitaa olla sellainen, ettei se tuo mitään uutta ehtoa kuvioon mukaan. Sama asiahan sanottiin jo ensimmäisessä lauseessa. Tässä on ensimmäinen olelellinen ero muihin kätköihin. Leimasin pitää olla. Tämä on selkeä asia. Ja taas kätkön kannalta merkityksetön lisätieto. Summa summarum: Letterbox hybridin tarkennetut ohjeet eivät sisältäneet muuta todellista lisävaatimusta kuin leimasimen. Leimasimen lisäksi kätkön on täytettävä normaalit geokätkön tunnusmerkit, jotka vaaditaan muiltakin geokätköiltä. Vaatimuksissa ei edes vaadita kätköön mitään Letterbox-tyyllisiä vihjeitä. Pelkkä leimasin tekee kätköstä potentiaalisen Letterbox Hybridin!

Harvemmin täällä tulee käytyä, kun on aika hiljaista ollut.