EXT-944 EXT-1026: cleaning up my quick fix for these issues.

I've now added an explicit LLUrlRegistry::findUrl() method
for LLWStrings. This deals with correcting the start/end
range for the url appropriately. Now the API can be used
without worrying about utf8/utf32 character offset issues.

Internal JIRAs: DEV-40127 DEV-39966.

1 files changed, 28 insertions, 0 deletions

diff --git a/indra/llui/llurlregistry.cpp b/indra/llui/llurlregistry.cpp
index f2d340deb7..6f5c694b1b 100644
--- a/indra/llui/llurlregistry.cpp
+++ b/indra/llui/llurlregistry.cpp
@@ -162,3 +162,31 @@ bool LLUrlRegistry::findUrl(const std::string &text, LLUrlMatch &match, const LL
 
 	return false;
 }
+
+bool LLUrlRegistry::findUrl(const LLWString &text, LLUrlMatch &match, const LLUrlLabelCallback &cb)
+{
+	// boost::regex_search() only works on char or wchar_t
+	// types, but wchar_t is only 2-bytes on Win32 (not 4).
+	// So we use UTF-8 to make this work the same everywhere.
+	std::string utf8_text = wstring_to_utf8str(text);
+	if (findUrl(utf8_text, match, cb))
+	{
+		// we cannot blindly return the start/end offsets from
+		// the UTF-8 string because it is a variable-length
+		// character encoding, so we need to update the start
+		// and end values to be correct for the wide string.
+		LLWString wurl = utf8str_to_wstring(match.getUrl());
+		S32 start = text.find(wurl);
+		if (start == std::string::npos)
+		{
+			return false;
+		}
+		S32 end = start + wurl.size() - 1;
+
+		match.setValues(start, end, match.getUrl(), match.getLabel(),
+						match.getTooltip(), match.getIcon(),
+						match.getMenuName(), match.getLocation());
+		return true;
+	}
+	return false;
+}