I believe I was wrong about the PHP version, it's 7.4, and I've attached a screenshot of the activated and available extensions. I posted this same issue on the LimeSurvey Forums and a partner there suggested this was an environment issue. Can anyone help me with this?

I've created a phpinfo() file here - https://cupe1978.com/survey/info.php - confirming PHP 7.4.8 and providing information about the environment.

as for bug 16121 I can confirm that this bug doesn't show on PHP 7.3, but on the same installation of LimeSurvey will occur for PHP 7.4.

For now downgrading will fix this (7.3 is still stable and supported) - but will need to be resolved

@adamzammit and @TomBenj , thanks for reporting it. Does it occur on LS3 as well? Or is it only LS4 with php 7.4?

Hi @cdorin - Yes it does occur on LS3 too.

Adam

Ok, assigned it to @gabrieljenik and increased its priority since more and more users will move to php7.4

I don't think this is related to PHP version.
Seems to be something very related to browser.

Maybe it is because the using the autocomplete on safari maybe doesnt trigger the change event?

One thing we could try is to add a small snippet in the survey as to don't allow autocomplete.
If errors can't be reproduced then, we will then know better where to look and how to solve it.

This is very hard to reproduce. Can you please tell me a specific browser version to test with?
Also, this happens only when using the autofill, right?
If user types in, no error appears, right?

I can suggest the following: On the test survey created, we intrduce a snippet that can record screen, JS errors and others as browser versions. That will give us a little bit more of information.

It seems to be on any Safari based browser.

From my testing so far, it appears that Safari is reloading the page for the first few requests, which is then resetting the LEMpostKey variable in the session to a new random value. This is causing the alert to occur. It is only occurring on PHP 7.4 not on PHP 7.3.

I did a HTML diff of the code produced by the PHP 7.4 version and the PHP 7.3 version and the only difference (besides the obvious cookie / session variables) was that the favicon href was missing in the PHP 7.4 version.

When I hacked the imageSrc function in core/LS_Twig_Extension.php to always give a valid image URL, Safari didn't request the main page twice and the bug disappeared.

So then I looked at the ValidateImage function in core/LSYii_ImageValidator.php

and the built in favicon.ico in the template was returning an error in validation:

53 (
54 [debug] => image/vnd.microsoft.icon
55 [uploadresult] => This file is not a supported image - please only upload JPG,PNG,GIF or SVG type images.
56 [check] =>
57 )

So adding "image/vnd.microsoft.icon" to that file did the trick. This gave a valid path to the :

<link rel="shortcut icon" href="/tmp/assets/e02d29a2/favicon.ico" />

instead of :

<link rel="shortcut icon" href="" />

Which stopped Safari from reloading the page, which avoided LEMpostKey being reset and the error showing.

Fix committed to 3.x-LTS branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=30653

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=30654

@adamzammit : thanks for this grat fix.

Else, seems there are an issue in theme too
<link rel="shortcut icon" href="" /> is invalid we must add a checker before , no ?.

{% if(imageSrc('./files/favicon.ico')) %}
    <link rel="shortcut icon" href="{{ imageSrc('./files/favicon.ico') }}" />
{% endif %}

Else : it due to the 404 error in fact …

Which stopped Safari from reloading the page, which avoided LEMpostKey being reset and the error showing.

Did a simple broken image do the same ? <img src="">

Now that you mention it, it happened to me in onther platforms that a 404 ended in a redirect to the index and made the session to reset. Nice finding.

Still, if that's the case, why it only applies to text questions and not to others?
Where does the autofill fit in here?

Did a simple broken image do the same ? <img src="">
@DenisChenu: I don't think that's a simple broken image, is a broken image that is pointing to the same page. Very specific.
So, yes, a broken image like that, may lead to the same behaviour. Still, not very usual broken image type :)

Yet, I have some loose tails on the whole thing.

Will wait to Addam's reply.

@gabrieljenik : src='' => broken image to the current url :) then can be example.org/1234 for example

Since imageSrc return false if empty : < img src='imageSrc('./files/mybeautifullandinvalidlogo.jpg')' > can (maybe) do the same issue :)

@DenisChenu - I agree there should be a checker in the theme as you suggested as imageSrc can return false - do you want to add that in?

I have not checked the behaviour for just a broken image - but I think if imageSrc is called, and can return false, then something should happen to the img tag - either it should be removed as you have suggested for the link tag, or a placeholder should be put in so invalid HTML is not produced.

@gabrieljenik I observed the behaviour on all types of questions not just text questions. I didn't see the connection with "autofill"

I have not checked the behaviour for just a broken image - but I think if imageSrc is called, and can return false, then something should happen to the img tag - either it should be removed as you have suggested for the link tag, or a placeholder should be put in so invalid HTML is not produced.

There are a image function than do the image , theme editor can use it :).

I report and fix the other issue with invalid ico file

Fixed in Release 4.3.23+201026