Fixed Unfurling URL's

It seems iOS is converting the URLs to links automatically, but can't reproduce that on macOS.
I don't know if this is related, but when you right click -> "Copy link" in Safari, it will copy the link and text as rich text, rather than simply giving you the link itself like in every other browser.

It would make sense for this behaviour to be consistent on Safari on macOS and iOS, so that could be what you're seeing here.


Fillip
 
It seems iOS is converting the URLs to links automatically, but can't reproduce that on macOS. But that could be one factor towards it appearing to be sporadic.

I'd like to say this is a new behaviour but I'm not certain. I'll have to test it on an older XF version. If anyone gets a chance, the demo system is still using the XF 2.0.10 version of Froala (the new version is in 2.0.11 and 2.1.0) so seeing if URLs are auto linked there would be interesting.
Turns out that this has actually been a behaviour in iOS since iOS 11. Not sure why I never noticed before. Not only that, but this isn't Froala specific. It's related to contenteditable elements generally.
 
I don't know if this is related, but when you right click -> "Copy link" in Safari, it will copy the link and text as rich text, rather than simply giving you the link itself like in every other browser.

It would make sense for this behaviour to be consistent on Safari on macOS and iOS, so that could be what you're seeing here.


Fillip
It applies to copying plain text links too, I think. Hmm. I better check that...

https://xenforo.com/community/posts/1295934/report

Ok, then, maybe not quite.

It seems to be links copied from the address bar and links copied from HTML.
 
Thank you for reporting this issue. The issue is now resolved.

Change log:
Attempt to workaround an inconsistent iOS behaviour which means that text URLs are pasted as HTML links and therefore bypasses unfurling. Given that we autolink (or unfurl) URLs anyway, I don't think this is a significant change of behaviour.
Any changes made as a result of this issue being resolved may not be rolled out here until later.
 
Not seeing the change. I posted the #26 link to post above.
 
Not seeing the change. I posted the #26 link to post above.
 
One question, not sure if it is related to this bug or not.

When trying to unfurl fiverr, it says "access to this page has been blocked". Is this normal?

 
Last edited:
That is indeed what they return when our HTTP client tries to fetch the page. So, yes, normal from that point of view. Fairly unusual for a site to do that. They may only load the page for recognised user agents, i.e. those that look like a real browser.

It seems to be attempting to load a CAPTCHA. The worst thing about it is that they are returning a 200 successful response, so as far as the unfurling system knows, that is the expected content of the page.

It might be something you want to report to Fiverr as a bug on their forums. Seems a little "unfriendly" to not even return some basic info. At the very least they should be sending a different response. Unless it's 200, we count it as an error and ignore it.

In fact, they could continue to serve that, but if the title tag just contained the word Fiverr on its own that would be an infinite improvement.
 
I'll see to report it to fiverr.

One question, the text Access to This Page Has Been Blocked, is it a phrase from XF or a response from their side? Can we change that phrase to a less scary warning?
 
Last edited:
Reported:
 
I'll see to report it to fiverr.

One question, the text Access to This Page Has Been Blocked, is it a phrase from XF or a response from their side? Can we change that phrase to a less scary warning?
It's a response from their side. It's the actual content of the title tag on the page they are serving. That's what I meant by it wouldn't be so bad if the title tag simply said "Fiverr" instead of the scary warning.
 
Top Bottom