HTML target attribute broken

[+arisoft]

Many cache descriptions contains links to external pages. Many of these links has a special attribute target="_blank" to open the linked external page into a new tab instead of changing the current page. It is also common to open these links by pressing "Ctrl" button while clicking the link to force it to open into a new tab.

 

Due to recent changes, both methods has been rendered useless. Instead of opening a new tab this dialog is displayed:

 

Answering "Ok" to this opens the new page always into the current tab which is not the preferred outcome.

 

One way to circumvent this unwanted behaviour is to open external link by clicking it with the right mouse button and selecting it to be opened into a new tab from the menu, bypassing this security measure. I am now trying to learn this way to open links into a new tab.

 

A simple fix to the problem is to add this option "Open Link in a New Tab" into the dialog as a new button or a persistent checkbox.

[+Hynz]

2 hours ago, arisoft said:

Due to recent changes, both methods has been rendered useless.

Yes, that's another anoying "progress" of webdesign these days.  

[+barefootjeff]

2 hours ago, arisoft said:

Many cache descriptions contains links to external pages. Many of these links has a special attribute target="_blank" to open the linked external page into a new tab instead of changing the current page. It is also common to open these links by pressing "Ctrl" button while clicking the link to force it to open into a new tab.

 

Due to recent changes, both methods has been rendered useless. Instead of opening a new tab this dialog is displayed:

 

Answering "Ok" to this opens the new page always into the current tab which is not the preferred outcome.

 

This is horrible. In my new multi that was only published a week ago, I specifically wanted it to open a link (an enhanced version of the image on the cache page) in a new tab so that the viewer could continue reading the description. I've done similar things in other caches where clicking on an image (or part of an image) is meant to open additional information in another tab, NOT leave the cache page with the rest of the description unread. Looks like in this Year of the Hide HQ are intent on breaking them.

[+barefootjeff]

Why was there no Release Note about this change? Unless this can be reversed, I'll have little choice but to archive two of my hides including one that was only just published.

[+MartyBartfast]

55 minutes ago, barefootjeff said:

Why was there no Release Note about this change?

Sadly we don't seem to get releasenotes anymore, there's so much stuff gets changed with no notification - very poor.

[+RCH65]

Veeeeery annoying...
Can't open links (even checkers) in a 2nd tab anymore by pressing CTRL

[+mustakorppi]

As you already have a list of allowable websites and API partners, why do you feel this disclaimer is necessary for sites you've already vetted to at least some degree?

[+niraD]

4 hours ago, MartyBartfast said:

Sadly we don't seem to get releasenotes anymore, there's so much stuff gets changed with no notification - very poor.

This forum really needs a "Sad" response.

[+barefootjeff]

2 hours ago, mustakorppi said:

As you already have a list of allowable websites and API partners, why do you feel this disclaimer is necessary for sites you've already vetted to at least some degree?

 

In my case:

 

 

the "external link" they're objecting to is https://img.geocaching.com/cache/525b4663-f218-4f62-98ff-b046eab7418f.jpg so I guess geocaching.com doesn't trust images hosted on geocaching.com.

 

After all the time, effort and money I put into developing this cache, it's pretty disheartening to have it effectively killed off less than a week after it was published with no forewarning or explanation from anyone at HQ. That's it, in this Year of the Hide there won't be any more hides from me.

[+Max and 99]

After reading the above posts I think I have a better idea of why I do not get this message on the app. Only on the website.

[+2Abendsegler]

There are some bugs that haven't been corrected for weeks. Instead of correcting these bugs, the developers deal with something unnecessary like this. Sorry, but I really don't understand that.

[+OusKonNé & Cétyla]

6 hours ago, 2Abendsegler said:

There are some bugs that haven't been corrected for weeks. Instead of correcting these bugs, the developers deal with something unnecessary like this. Sorry, but I really don't understand that.

 

I second that.

 

When we add the parameter target="_blank" in our HTML code, it is because we want the link to open in a new page. And now Groundspeak is changing that without respect for geocachers who, like me, take the time to code beautiful cache listings.

 

Another changes that no one asked for...!!!

Edited January 29, 2022 by OusKonNé & Cétyla

[+Mausebiber]

Try the following:

 

right ckick on the link, click on "open in a new tab"

No message and you just get a new tab.

[+barefootjeff]

6 minutes ago, Mausebiber said:

right ckick on the link, click on "open in a new tab"

 

Having to add instructions like "Right-click on the image, or long-press if using a touch screen, then select Open in a New Tab" kind of breaks the narrative of a carefully crafted description.

[+barefootjeff]

Fixed for now:

 

 

I need the linked image to be opened in a new tab because there are instructions after that point in the description on what to look for where the pointers are pointing and how to use what you find there, and I can't really move that information forward as it would have no context. I'm really not happy with this, not by a long shot, and will weigh up my options on what to do with this cache over the coming days.

 

If this change has been forced by some tinpot US legislature then so be it, otherwise it seems a pretty heavy-handed overkill for what is probably a non-existent problem.

Edited January 28, 2022 by barefootjeff

[+barefootjeff]

I see the mandatory Project-GC checkers on challenge caches are now considered to be dangerous external links:

 

 

Really?

[onepooja]

Thank you for bringing this issue to our attention.

A hotfix was deployed today so that HTML attributes other than the default target="_self" will be respected once a player confirms the browser dialogue with OK.

Feel free to use Jeff's cache that he was speaking of as a test case: https://coord.info/GC9M6X5The browser dialogue will remain as this was a necessary security improvement.

Please note, that small site security updates have traditionally not been covered by release notes as the latter are reserved for larger new feature releases.

[+OusKonNé & Cétyla]

27 minutes ago, onepooja said:

A hotfix was deployed today so that HTML attributes other than the default target="_self" will be respected once a player confirms the browser dialogue with OK.

 

Thank you Groundspeak for this prompt fix! 👍

[+barefootjeff]

48 minutes ago, onepooja said:

The browser dialogue will remain as this was a necessary security improvement.

 

Thanks for the hotfix, but I'm curious why this security improvement is deemed necessary in cases when, as with my cache, the link is pointing to an image hosted on geocaching.com. The warning is actually quite misleading in this instance as opening the link isn't leaving geocaching.com. Similarly with links in Project GC challenge checkers and third party puzzle checkers, I wouldn't have thought those posed a security risk. As mustakorppi said earlier in this thread, you already have a list of approved hosts for third party image links, so I would have thought that it would make sense to bypass the security warning when the link embedded in an image points to something hosted on one of those.

[+Bl4ckH4wkGER]

Frankly you are missing the point.

 

This functionality has long been around for links in logs and in the Message Center. There was now reason to expand it to the the Cache Details Pages, too.

 

The message informs players that they are leaving the domain geocaching.com and to be mindful of that - not more and not less. Your image from a technical standpoint is hosted on a different domain - see the URL.

 

Nowhere does it say "this is not part of our list of approved domains and is probably dangerous".

 

Now, why not cover a list of other domains here as by default okay? Because as very small a chance as it might be, people could technically put malicious stuff on one of the approved image hosting sites if they really wanted to or one of the other domains could get hijacked. Hence it is prudent to better be safe than sorry - instead of creating an option for complaints about why one blindly trusted anything outside of geocaching.com.

 

You don't have to like this change. That said, your cache that you wanted to archive is in a functioning state again. So I recommend you focus on enjoying that and its logs coming in.

[+Max and 99]

So if I'm completing a puzzle cache, and the only way to get coordinates for the final is to accept that link that gives me a warning....

That's my only option?

[+mustakorppi]

13 minutes ago, Bl4ckH4wkGER said:

Frankly you are missing the point.

I think you are missing the point that everything you said in this message comes at the cost of usability. This warning has no benefit for your users: we come to geocaching.com for the user-generated content.  If enjoying that content means clicking a link to certitudes.org, then we either click that link or have no reason to come to geocaching.com in the first place.
 

No one is blindly trusting anything on the internet, including geocaching.com. But how would your internet experience be like if every site you visit did this for their external links?

[+barefootjeff]

15 minutes ago, Bl4ckH4wkGER said:

Nowhere does it say "this is not part of our list of approved domains and is probably dangerous".

 

But it does begin with Hey wait! with an exclamation mark which to me implies that you should stop and rethink what you were about to do. If I'm walking towards the edge of a cliff and someone yells out "Hey wait!" they probably want me to stop and not go any further.

 

 

[+M.B.E.S.]

5 hours ago, onepooja said:

Thank you for bringing this issue to our attention.

A hotfix was deployed today so that HTML attributes other than the default target="_self" will be respected once a player confirms the browser dialogue with OK.

Feel free to use Jeff's cache that he was speaking of as a test case: https://coord.info/GC9M6X5The browser dialogue will remain as this was a necessary security improvement.

Please note, that small site security updates have traditionally not been covered by release notes as the latter are reserved for larger new feature releases.

Thanks for this first fix. However, using CTRL+clicking on the link to open the link in a new TAB still doesn't work. The link still opens in the current TAB after the notification.

 

Next to this it would be very nice to have a "don't show this warning anymore" checkbox in the pop-up, to be able to opt out of these (for me annoying) notifications.

[+Zouk Team]

In my job I have very much to do with user interface and user experience. No one likes to be shout at, so please get rid of the first part "Hey wait!". And I very much like to see the option M.B.E.S. suggests to have an option to not show that annoying pop-up again. Once is enough, then you've made your 'security point'.

[+arisoft]

3 hours ago, Bl4ckH4wkGER said:

Frankly you are missing the point.

 

I don't share this feeling. I understand why this is important and didn't even ask to remove the feature. @onepooja already reported that the main issue is fixed now.

 

3 hours ago, Bl4ckH4wkGER said:

The message informs players that they are leaving the domain geocaching.com and to be mindful of that - not more and not less. Your image from a technical standpoint is hosted on a different domain - see the URL.

 

For my view https://img.geocaching.com/cache/525b4663-f218-4f62-98ff-b046eab7418f.jpg is on the same domain as https://forums.geocaching.com or https://www.geocaching.com/geocache/GC9M6X5_the-bushrangers-legacy

 

These are subdomains of geocaching.com and under your control. The warning text is "Hey wait! You're about to leave Geocaching.com." is not correct if the intented feature is warning about leaving www.geocaching.com subdomain.

 

From the security point of view, it does not make sense to cry wolf just in case.

Edited January 29, 2022 by arisoft

[+barefootjeff]

3 hours ago, Bl4ckH4wkGER said:

You don't have to like this change. That said, your cache that you wanted to archive is in a functioning state again. So I recommend you focus on enjoying that and its logs coming in.

 

As I said in another thread before all this happened, I don't expect this cache to get many finders or FPs (currently 2/1 after its first week, both on the morning after publication). If I'd wanted lots of logs I'd have just put out a trail of pill bottles under bushes and saved all the hassle. What I do want is for those who decide to take it on to have the best experience I can give them, and that includes a cache page that's absorbing and as seemless as I can make it in its presentation. Breaking the suspension of disbelief is what immediately comes to mind when I see that Hey wait! box pop up right at the climax of the narrative and had I known this was about to happen I would have designed it differently to avoid embedded links in images altogether. It's too late now, I know, I just have to put it down to experience and learn not to try something like this again.

[+ChriBli]

This is silly on the level of writing "objects in mirror are closer than they appear" on vehicle rear view mirrors (or was it the other way around? R.I.P. Meatloaf). Nobody expects Geocaching.com to have reviewed those links.

 

Ironically, for me this is kind of an improvement. I wasn't aware of the ctrl-click method of opening a link in a new tab and was always annoyed when clicking the checker link for a puzzle cache made the checker replace the cache description. Especially during speed-solving efforts. Now this popup serves as a reminder to do right-click instead. Only it should say "Hey wait! You're about to replace the cache description with this external link.".

 

Funny that right-clicking and opening in a new tab does not bring up the warning popup. Is it safe to visit an unreviewed link in a new tab?

[+mustakorppi]

2 hours ago, arisoft said:

to cry wolf

Hey wait, that's a link outside geocaching.com. Stay safe everyone.

[+KRON family]

Somehow I can't understand why this popup is there.

1, It's 2022. You can do something like

"Try to find it on Google (!)."

Link through your redirector, exclamation mark to report link, block link after five reports.

Using a pop-up window on each link is a solution like in 2000.

 

2, Excessive use of pop-ups is not appropriate.

External links have not been reviewed by Geocaching.com? Yes, I think I read about it somewhere in guidelines.

First popup: OK, maybe they want to remind me.

Second popup: They still don't know that I know? OK.

Fifth popup on the same link: Do they think I'm stupid? Cancel, click the link again, Block pop-ups on Geocaching.com, OK.

A few months later, an important message in the pop-up window: I see nothing, pop-ups on Geocaching.com already blocked.

 

[+niraD]

8 hours ago, M.B.E.S. said:

Thanks for this first fix. However, using CTRL+clicking on the link to open the link in a new TAB still doesn't work. The link still opens in the current TAB after the notification.

This!

 

Please stop breaking basic built-in browser functionality. You are creating inconsistencies that reduce the predictability of browser behavior, and that reduce the usability of the web as a whole.

[+ChriBli]

14 hours ago, onepooja said:

a necessary security improvement.

Security? What do you expect people to do when they see the popup? Not follow the link, because they suddenly realize that Geocaching.com does not guarantee that it is safe? Of course not, they will follow it anyway, they already know that. The only way this is more secure is that Geocaching.com has secured itself from criticism/litigation from someone who pretends they didn't know.

 

10 hours ago, Bl4ckH4wkGER said:

You don't have to like this change.

That's no way to treat a customer.

[+arisoft]

16 hours ago, onepooja said:

this was a necessary security improvement

 

I found a security hole. The "Related Web Page" link on some geocaches is not secured with this popup as required. This needs your attention and fix. Am I eligible for your Bug bounty program?

[+fizzymagic]

15 hours ago, Bl4ckH4wkGER said:

Frankly you are missing the point.

 

You don't have to like this change.

 

OK, good.  I don't like the change.  And I believe that the one missing the point here is Groundspeak, not its customers, who, in your eyes, are apparently Never Right.

 

One more thing:  just because something makes the site more difficult to use does not make it a "security improvement."  In this case, there is no additional security whatsoever.  What there is, instead, is a plausible way for Groundspeak to avoid any hint of liability.  Calling that a "security improvement" is pretty much insulting the intelligence of your audience, so don't do that, OK?  Just call it what it is and don't blow smoke.

Edited January 29, 2022 by fizzymagic

[+Max and 99]

This really should have been a release note. It is significant enough to warrant one.

[+niraD]

1 hour ago, Max and 99 said:

This really should have been a release note. It is significant enough to warrant one.

Better yet, it should have been rejected during design review, usability review, or code review.

 

But I've been on development teams when someone non-technical (legal, marketing, etc.) dictates the implementation of some misguided feecher, so I have some sympathy for the developers.

[+thebruce0]

17 hours ago, ChriBli said:

Funny that right-clicking and opening in a new tab does not bring up the warning popup. Is it safe to visit an unreviewed link in a new tab?

 

It's a technical thing. All the website is doing is intercepting the left click on a link and inserting their own functionality before the browser dealt with the link syntax (which is why the 'target' was being lost initially). Right clicking is a browser function and the website isn't informed that "open in a new tab" was chosen. They would have to start intercepting the right click functionality - and I truly hope they do not do that because that would be even more ludicrous =/

 

5 hours ago, niraD said:

But I've been on development teams when someone non-technical (legal, marketing, etc.) dictates the implementation of some misguided feecher, so I have some sympathy for the developers.

 

And, as always, the critical is always the loudest and smallest. People in the middle who shrug it off won't say anything and accept it (the vast majority), and people who don't know any better really have no idea what's happening or why, they'll just follow what the internet tells them. So the majority of response will be okay/great. Even though the criticisms may be well-thought and valid, and implementing fixes would also be accepted by majority (because of the middle).

Focus testing is definitely no easy thing, and making decisions should never be done simply by majority neutral/positive response. When many will say "I love it!" without knowing any better, something could be broken and they'd never realize. 

 

Anyway... there are many developers and professionals in these forums, some very blunt, but overall a very very very small segment of the community. I think the only hope for constructively critical responses from here to be heard is if a developer/lackey takes a comment or idea to heart and presents it to the dev team, however that may be done at HQ, with some umph. *shrug* (and it's not like that ever happens, but I think this update is yet another good example of a whole lot of professional feedback, like decades of man-years - yet met with "you don't have to like it" - which sadly feels pretty insulting to our intelligence).  Especially when many new updates are rolled out with bugs that many forum-goers seem to catch almost immediately, wondering how they snuck by... 

 

But gah, I truly hate being negative. Sometimes things just need to be .. um, gotten off the chest.

 

Edited January 30, 2022 by thebruce0
minor sentence expansion

[+HoochDog]

Just noticed this change and here to pile on. 
 

hey Groundspeak, this change to have a pop up stinks!!!

 

we’ve all been using web browsers for 20 years or more. We know how the internet works. 
 

when you click a link it may be taking you to a new site. That’s the way the “world wide web” was designed. 
 

I don’t need your annoying pop up to educate me of this fact EVERY TIME. 
 

 

Edited June 16, 2023 by HoochDog

[+barefootjeff]

On 1/29/2022 at 6:01 PM, Bl4ckH4wkGER said:

This functionality has long been around for links in logs and in the Message Center. There was now reason to expand it to the the Cache Details Pages, too.

 

To the best of my knowledge, I've never come across an external URL in a log or a message. Putting URLs in logs or messages isn't a common thing to do, at least around here, but using embedded links in images on cache pages is a whole different matter since every checker uses that functionality. All cache pages already have a yellow disclaimer box at the top:

 

 

Couldn't the warning about external links not being reviewed have been included in that, or even just in the terms and conditions it refers to? Are COs or checker providers putting malicious links in images such a widespread problem that it needs this sledgehammer response? I guess it must be.

 

On 1/29/2022 at 6:01 PM, Bl4ckH4wkGER said:

Your image from a technical standpoint is hosted on a different domain - see the URL.

 

The URL I put into the cache page source is https://img.geocaching.com/cache/525b4663-f218-4f62-98ff-b046eab7418f.jpg which is clearly part of the geocaching.com domain, and that's the URL that appears at the bottom of my browser while the Hey wait! message is being displayed. The fact that you've decided to redirect such links to amazonaws.com is beyond my control and couldn't be used for any malicious intent even if I wanted to, and furthermore how is anyone who's contemplating whether to click OK or Cancel when the Hey wait! box comes up supposed to know that it'll land there?

 

In recent years we've seen a steady clamping down on image usage in cache pages, from the transcoding of all uploaded images to progressive jpeg while removing any metadata content or even the abiltity to encode coordinates into RGB values in PNG or GIF images, the restrictions on third party image hosting and now this. Yet at the same time the advertising boxes on the right side of cache pages have grown bigger and more intrusive, often with language or innuendos that aren't particularly family-friendly like this one that just appeared on my cache page:

 

 

Not only that, the ads are now being dynamically changed every few seconds, soon it'll be "we interrupt this ad stream for some geocaching". I haven't tried it, because sure as hell if I do I'll be flooded with targeted marketing from the advertiser for the next month, but I'd be willing to wager that if I clicked on that ad there wouldn't be a Hey wait! popup warning me not to. Web security my eye! it's pretty clear where HQ's interests lie and it's not in encouraging imaginative cache design.

Edited January 30, 2022 by barefootjeff

[+Max and 99]

On 1/29/2022 at 1:01 AM, Bl4ckH4wkGER said:

This functionality has long been around for links in logs and in the Message Center.

I've been thinking about this since your post. I really cannot think of any time that I've gotten this warning on a log or in the message center. Maybe I'm just misunderstanding what you stated.

Edited January 30, 2022 by Max and 99

[+Bl4ckH4wkGER]

Thank you for the additional feedback over the weekend.

We have reopened the conversation with our Legal and Engineering department in an effort to find a solution that meets both, liability concerns and player pain points.

We will keep you posted as we learn more.

[Team_Rhoeny]

Hello, as a big HTML fan I also have a solution:

 

You could use a normal hyperlink:

<a href="https://www.geocaching.com">text</a>

You can use the target variant, but it can't be used here. But you can use a window.open via Javascript. This looks like this:

<a onclick="window.open('https://www.w3schools.com')">text</a>

 

Hope I could help ;-)

 

[+barefootjeff]

On 1/31/2022 at 9:25 AM, barefootjeff said:

I haven't tried it, because sure as hell if I do I'll be flooded with targeted marketing from the advertiser for the next month, but I'd be willing to wager that if I clicked on that ad there wouldn't be a Hey wait! popup warning me not to.

 

For completeness, I used a sacrificial PC to try clicking on the advertising image on the right side of a cache page. As expected, there was no Hey wait! popup, it just went straight to the external page (in this case, the website of a real estate business in Wollongong).

[+mustakorppi]

My solution was to create a simple userscript that overrides the event listener that does the click hijacking, and adds the target="_blank" attribute to every link in user-provided cache content. No more need to worry about where the link is going to open.

 

The latter part will be useful even when this current silliness goes away.

[+capoaira]

17 hours ago, Rhoeny said:

But you can use a window.open via Javascript. This looks like this:

<a onclick="window.open('https://www.w3schools.com')">text</a>

I hope, that this is not working. Otherwise you can insert any js. That shouldn't be possible!

[+baer2006]

On 1/31/2022 at 6:23 PM, Bl4ckH4wkGER said:

We have reopened the conversation with our Legal and Engineering department in an effort to find a solution that meets both, liability concerns and player pain points.

So it's "lawyers' demands" vs. "user friendliness"? I have a hunch how that will end ...

[+niraD]

3 hours ago, baer2006 said:

So it's "lawyers' demands" vs. "user friendliness"? I have a hunch how that will end ...

This forum really needs a "Sad" response.

[+thebruce0]

2 hours ago, niraD said:

forum really needs a "Sad" response.

 

Hey niraD, your signature links in the forum take me to external websites and there's no disclaimer, and they popup in a new tab!  Just sayin'... that I don't mind ;P

[+niraD]

4 hours ago, thebruce0 said:

Hey niraD, your signature links in the forum take me to external websites and there's no disclaimer, and they popup in a new tab! 

Huh... Now that I'm no longer in the Bay Area, I should probably update my signature...

[+Mars Express]

On 2/2/2022 at 7:41 AM, mustakorppi said:

My solution was to create a simple userscript that overrides the event listener that does the click hijacking, and adds the target="_blank" attribute to every link in user-provided cache content. No more need to worry about where the link is going to open.

 

The latter part will be useful even when this current silliness goes away.

 

please share this script!

Edited February 3, 2022 by Mars Express