Fields values do not update while changing the values on URL parameters if autofill is enabled.

  • Profile Image
    Asked on July 17, 2019 at 03:26 PM

    We've got a short form (91372090131144) that gets used in many place: For example, on every day of a five-day workshop.

    The form contains an input table question that should only appear in certain circumstances: For example, only on the last day of that five-day workshop.

    We set form variables via URL parameters to tell these circumstances apart.  Here's a sample URL:

    We recently noticed that we were receiving answers to the input table in circumstances where it should not appear at all (for example, on day 2 of the workshop).  So we started trying to view the form with different parameters.  What we're seeing is that the input table question does not consistently hide when we'd expect it to.

    Here are the conditions for showing that question:


    I find it's easier to parse this logic if I invert it, so the question should show if and only if (day == 5 || workshopSubject != "5-day Summer" || workshopCourse == "CS Fundamentals")

    However, I'm seeing the input table question appear no matter what parameters I pass.  Here's a situation (using the above link) where I'd expect the question to hide, but it is visible:

    1563390822Screenshot from 2019-07-17 12-

    That's a Chrome 75.0.3770.100 Incognito window on Ubuntu 18.04.2, with the developer tools open prior to reload so you can see that no JavaScript errors have appeared.

    This behavior repros for me in and out of incognito mode, and also on Firefox 68.0.

    So far, I always get the failure mode that the input table will not hide.  I've got reliable reports internally that sometimes the reverse problem occurs: The input table is hidden correctly on day 2 but then will not show when the day 5 parameters are passed, as if there's some caching error.

    My only theory is that the URL params simply aren't being populated into the form on load.  In this view you can see the relevant hidden fields on the form without values:

    1563391462Screenshot from 2019-07-17 12-

    But I'm not sure exactly what the mechanism is that you're using to populate these values - they are present in the DOM in this script tag:

    1563391533Screenshot from 2019-07-17 12-

    Will you help us check whether we've misconfigured anything, or confirm whether we've actually found a bug in your system?

    Thank you,

    Brad Buchanan Engineering

  • Profile Image
    Answered on July 17, 2019 at 04:59 PM

    Some new information: We did an impact assessment of the issues with this particular form, and found that bad submissions started at scale mid-Monday, when we enabled an experiment to redirect users to your form URL (with the query params) instead of embedding the form in our own site.

    1563397099Screenshot from 2019-07-17 13-

    We've disabled the experiment and will monitor to see if the issue goes away with forms embedded in our own site again.  I'll report back tomorrow on this.

    Perhaps there's something different in the way query params are handled for purposes of showing/hiding fields specifically in the embed case? Other query params (the facilitator name and our submit redirect, for instance) are working fine in both cases.

  • Profile Image
    Answered on July 17, 2019 at 05:41 PM

    I've located some potentially relevant threads on your forum from 2011

    - How do I get a value passed to a hidden field?
    - Is there a way I can use hidden fields to show certain questions?

    In those posts, your team asserts that hide/show conditions can only be triggered by user-initiated actions, not by pre-populated hidden fields. Is this still true? If so, any idea why this works for us when we embed the form in our own site?

  • Profile Image
    Answered on July 17, 2019 at 09:46 PM

    We are sorry for the inconvenience this may have caused. I think the issue is in the hide/show conditional logic for your form. I cloned your form and it works as expected.

    You can check my demo form (clone version) here:

    I have now elevated this issue to the next level support so that they can investigate the problem. We will notify you here and on your email at once when a status update is available.

    Thank you for your understanding

  • Profile Image
    Answered on July 17, 2019 at 11:30 PM

    That's weird. I'm sure my clone works fine earlier. Thanks for letting me know.

    Anyway, this issue has been forwarded to our backend team for further checking so we'll have to wait for their update regarding this problem.

    Thank you for your patience.

  • Profile Image
    Answered on July 18, 2019 at 08:40 PM

    Hi there,

    Any news? Also, it looks like one of my replies went missing from this thread.

    Brad Buchanan Engineering

  • Profile Image
    Answered on July 18, 2019 at 10:03 PM

    We haven't heard anything yet from our developers regarding the issue being reported in this thread and we would like to apologize for any inconvenience. Although we cannot provide any timeframe for when the issue will be fixed, please be assured that once there is an update we will notify you in this thread the soonest.

  • Profile Image
    Answered on July 22, 2019 at 08:50 PM

    Hi there! Any news?

    I continued experimenting with cloned form you linked to, and still see the surprising behavior as of today.  I've identified some more details about the odd behavior:

    - Some fields (workshopId and facilitatorName) always update to match the query parameters.

    - Others (day, workshopCourse, workshopSubject) are stuck with whatever value they were set to on the first visit to the form during the session.

    Looking at these five fields, I don't yet understand why some will change and others will not.

    - I re-examined these fields in our form.  They are configured near-identically.

    - Both workshopId and day receive values that can be interpreted as integers, but one updates and the other does not.  I can't find any logic telling Jotform to treat one as a number and the other as a string.

    - I've tried re-ordering the query parameters in case there was some sort of parsing bug only reading the first or last queryparam, but order doesn't seem to matter.

    - Our values for workshopCourse and workshopSubject often contain a space (encoded %20) but values without the space exhibit the same behavior.

  • Profile Image
    Answered on July 22, 2019 at 11:31 PM

    Unfortunately, we have not received any updates on the issue about the conditional logic not triggering with fields filled through the URL, I have tested the cloned form my colleague provided on the ticket and noticed the same issue happens, I will ask for updates and will let you know via this thread as soon as we get anything from our second level. 

    Now, regarding your last response, that seems a different issue which is not related to conditions and instead to fields retaining its value and not changing as you change the value on the form URL, may you please confirm this? 

    If this is a different issue, we will need to move it to another thread in order to further investigate it. 

    Looking forward to your response. 

  • Profile Image
    Answered on July 23, 2019 at 12:50 PM

    In fact, now that I think about it, that's one thing about the fields exhibiting the bad "save" behavior sets them apart: They are all used in a form condition.

    I have no idea why that would cause the save behavior in question, but it might be a theory to check.

    I just tested the `submitRedirect` field on the example form, and it does not exhibit the bad behavior.  It's part of a form condition, but the condition is currently broken/disabled (referencing a deleted field) so it might not apply.  I'll make another test form to attempt a repro.

    I also just noticed that this "Continue Forms Later" advanced setting is enabled on the particular form we're working with.  This doesn't seem necessary on a short form like this one.  I'll try disabling it on a clone and see if it works around the problem.

    1563900616Screenshot from 2019-07-23 09-


  • Profile Image
    Answered on July 23, 2019 at 02:25 PM

    Ok, after further testing it seems like disabling the continue forms later feature works as the fields values update as you change them in the form URL. For example, this URL works: 

    While this one will not work: 

    I think the issue is about the continue forms later option which does not allow the fields to update through the form URL so I'm adding this to our ticket in order to have our developers informed about this, we will be updating you as soon as we get anything from them.


  • Profile Image
    Answered on July 23, 2019 at 02:49 PM

    Awesome, thank you for testing that!  I'll investigate whether disabling "Continue Forms Later" is a feasible workaround for all of our forms - it seems promising.

    Has the autofill "Continue Forms Later" feature been enabled by default for a long time?  For some reason our team was under the impression that our forms didn't have the behavior, but it seems like most of them are using it.

  • Profile Image
    Answered on July 23, 2019 at 04:18 PM

    No, the "continue forms later" is not enabled by default. Also, your form is not using that before. When I checked my clone version of your form, I see that it isn't using the "Continue forms later".

    Anyway, my colleague is right. When the "continue forms later" is enabled, it is not allowing URL parameters to update the data in form fields.

    As soon as we receive an update on this, we will inform you right away.

  • Profile Image
    Answered on July 25, 2019 at 04:28 PM

    We do apologize for the inconvenience.

    Unfortunately, updates are still not available as of the moment.

    However, the ticket has been updated by my colleague and is being investigated by our back-end team.

    Once updates are available, you will be notified via this thread.

    Thank you for your patience and understanding.

  • Profile Image
    Answered on July 30, 2019 at 02:10 PM

    No new information on our end since July 25th.  Has your team had any new insights on this issue?  This is high-impact for us - it's blocking a fix for another issue.


  • Profile Image
    Answered on July 30, 2019 at 02:34 PM

    Hello Brad - We haven't heard anything yet from our developers regarding the issue being reported in this thread and we would like to apologize for any inconvenience. 

    I will add a comment/message the developer assigned to this ticket and request an update. Although we cannot provide any timeframe for when the issue will be fixed. please be assured that once there is an update we will notify you in this thread the soonest.

  • Profile Image
    Answered on August 08, 2019 at 06:26 PM

    Hi there!  Any news?  We still haven't found a usable workaround for this issue, and it's actively causing us problems.


  • Profile Image
    Answered on August 08, 2019 at 07:02 PM

    The ticket is still open, but there are no updates as of this time. Currently, the escalated ticket is related to the enabled 'Continue Forms Later' option.

    If the issue is also happening when the 'Continue Forms Later' option is disabled. Please kindly provide us with an example, so we will be able to escalate an additional ticket if necessary.