Cgeo: Log posting with max text length fails

[Lineflyer]

Detailed steps causing the problem:

• Compose a log for a gc.com cache
• Enter as much text as possible as log text (until no further characters are accepted)
• Try to send the log online

Actual behavior after performing these steps:

Logging immediately fails with the corresponding c:geo failure window.
No long posted online.

Expected behavior after performing these steps:

Max characters allowed for log in c:geo seems not to match what gc.com supports (I assume).
As soon as I reduce the log text by four characters the logging works smooth.

Version of c:geo used:

2019.03.17-RC (current release branch)

Is the problem reproducible for you?

Yes

System information:

Android 5.0.1, Samsung Galaxy S4

Other comments and remarks:

Seems not related to recent logging change #7388

[bekuno]

The log website(s) old/new check both for 4000 signs.
The text field in c:geo is limited to 4000 signs, with minLines 5.
Maybe the line breaks below your text were the problem?
Did you sent the log with max chars from c:geo, so that we can check the result?

[Lineflyer]

Still reproducible with 2020.09.22-NB, Samsung S20, Android 10:

09-23 15:08:18.128 31593 13621 E cgeo    : [AsyncTask #7] Error posting log
09-23 15:08:18.128 31593 13621 E cgeo    : java.lang.RuntimeException: java.io.IOException: request was not successful
09-23 15:08:18.128 31593 13621 E cgeo    :  at io.reactivex.rxjava3.internal.util.ExceptionHelper.wrapOrThrow(ExceptionHelper.java:46)
09-23 15:08:18.128 31593 13621 E cgeo    :  at io.reactivex.rxjava3.internal.observers.BlockingMultiObserver.blockingGet(BlockingMultiObserver.java:94)
09-23 15:08:18.128 31593 13621 E cgeo    :  at io.reactivex.rxjava3.core.Single.blockingGet(Single.java:3645)
09-23 15:08:18.128 31593 13621 E cgeo    :  at cgeo.geocaching.connector.gc.GCWebAPI.postLog(GCWebAPI.java:459)
09-23 15:08:18.128 31593 13621 E cgeo    :  at cgeo.geocaching.connector.gc.GCLoggingManager.postLog(GCLoggingManager.java:137)
09-23 15:08:18.128 31593 13621 E cgeo    :  at cgeo.geocaching.log.LogCacheActivity$Poster.doInBackgroundInternal(LogCacheActivity.java:881)
09-23 15:08:18.128 31593 13621 E cgeo    :  at cgeo.geocaching.log.LogCacheActivity$Poster.doInBackgroundInternal(LogCacheActivity.java:865)
09-23 15:08:18.128 31593 13621 E cgeo    :  at cgeo.geocaching.utils.AbstractAsyncTaskWithProgress.doInBackground(AbstractAsyncTaskWithProgress.java:134)
09-23 15:08:18.128 31593 13621 E cgeo    :  at android.os.AsyncTask$3.call(AsyncTask.java:378)
09-23 15:08:18.128 31593 13621 E cgeo    :  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
09-23 15:08:18.128 31593 13621 E cgeo    :  at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:289)
09-23 15:08:18.128 31593 13621 E cgeo    :  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
09-23 15:08:18.128 31593 13621 E cgeo    :  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
09-23 15:08:18.128 31593 13621 E cgeo    :  at java.lang.Thread.run(Thread.java:919)
09-23 15:08:18.128 31593 13621 E cgeo    : Caused by: java.io.IOException: request was not successful
09-23 15:08:18.128 31593 13621 E cgeo    :  at cgeo.geocaching.network.Network.lambda$static$6(Network.java:621)
09-23 15:08:18.128 31593 13621 E cgeo    :  at cgeo.geocaching.network.-$$Lambda$Network$S1n6XPPgWcknnAjXJlYG-giT7W4.apply(Unknown Source:2)
09-23 15:08:18.128 31593 13621 E cgeo    :  at io.reactivex.rxjava3.internal.operators.single.SingleFlatMap$SingleFlatMapCallback.onSuccess(SingleFlatMap.java:77)
09-23 15:08:18.128 31593 13621 E cgeo    :  at io.reactivex.rxjava3.internal.operators.single.SingleCreate$Emitter.onSuccess(SingleCreate.java:68)
09-23 15:08:18.128 31593 13621 E cgeo    :  at cgeo.geocaching.utils.RxOkHttpUtils$1.onResponse(RxOkHttpUtils.java:48)
09-23 15:08:18.128 31593 13621 E cgeo    :  at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
09-23 15:08:18.128 31593 13621 E cgeo    :  ... 3 more

[fm-sys]

I had to remove 6 characters to upload the log (and my log also contained 6 line breaks). It looks like line breaks are counted as two characters at geocaching.com.

[Lomanic]

As Groundspeak is an ASP.net/Windows shop, maybe they internally encode the logs as CRLF, that could explain that it takes two characters.

[fm-sys]

We have 4 options how to handle it:

• just ignore this bug (99% will ever write such a long log)
• set character limit to 3950 (the quick and dirty way - and hope that the user will not enter more than 50 new lines)
• change character limit dynamically (reduce it by one with every newline which gets inserted)
• Leave it like it is, but display how many characters left counted \n two times like GC does (permanently or maybe as of 3000 characters)

[moving-bits]

_IF_ you want to tackle this issue, I would prefer the last one as it is the most user-friendly IMHO.

[Lomanic]

FYI here is how characters are counted client-side.

In webpack:///./src/behaviors/character-count.js? at https://www.geocaching.com/play/geocache/gc28/log

     /*
      * Calculate the number of allowed characters remaining based on input length.
      * Uses the normalized string length function in StringTransforms
      * to calculate textarea text length with CRLF counted as 2 chars.
      * @param inputString {String} the text to check
      * @return {Number} The remaining number of allowed characters
      */
  _getRemainingCharacters: function _getRemainingCharacters(inputString) {
    var input = inputString.trim(); // Clean up any whitespace

    return this._max - _strings["default"].normalizedStringLength(input);
  }

And in webpack:///./src/utilities/strings.js?

/**
 * Calculates the length of a string by taking into account the presence of line breaks, 
 * which count as two characters (CRLF) in a textarea. Required to keep input length calculations
 * consistent between client and server.
 * @param {string} string   The string to test
 * @return {number}         The normalized length
 */


Util.normalizedStringLength = function (string) {
  var newLines = string.match(/(\r\n|\n|\r)/g);
  return newLines ? string.length + newLines.length : string.length;
};

So to properly count remaining characters, cgeo should

1. trim the string
2. add to the trimmed string length the number of times this trimmed string matches the /(\r\n|\n|\r)/g regex

Is cgeo already displaying the remaining characters count when writing a log or not? If not this would nice for verbose users (or even users with big signatures, like textual art). Similarly as in the website, it could prevent submission if the log is too long (with a visual hint like on the website or a Toast).