Firefox Default Value Bug? The Work Around


We recently encountered a strange bug while working with Firefox in our MacOS development environment. This environment runs Apache 2.4.54, PHP 8.1.8, and MariaDB 10.8.3. The tested browsers are:

  • Firefox 102.0.1
  • Safari 15.6
  • Chrome 103.0.5060.134
  • Firefox Developer Edition 103.0b9

Here's the issue:

While working on a new product release, we modified a form that was first created on August 30, 2021. The form has been working beautifully but needed a modification to support post content types, i.e., Block vs. Legacy.

To implement this feature, we added a new radio to the form using Formidable 5.4.2. A default value was set for this radio button, after we tried a toggle field with a default value set. Firefox did not display the default value for either of these new fields. The default values worked as they always have on the fields that were already on the form. It just didn't work for the new fields.

What makes this behavior suggestive of a Firefox bug is the fact that the new field default value works in all the other tested browsers. There are no errors being generated anywhere.

To troubleshoot this we first examined the field data in wp_frm_fields to compare old radio button configuration data to the new and the result is that nothing has changed in the data assembly and storage.

Next we tried Firefox in troubleshoot mode. Same problem. Last came a full refresh of Firefox. Same problem. Firefox is not setting the default values on new fields for old forms and we can't figure out why. It also won't display new default values for old fields.

Since we couldn't determine the root cause for this problem, we opened bug reports with both Mozilla and Strategy 11, although we sincerely doubt that the issue lies within the Formidable form, which works in every other tested browser. We wanted to make sure Strategy 11 received a heads-up in case others users start experiencing this issue.

Mozilla provided Firefox 103 Beta to test. Installing the Beta and running triggered an immediate update to 103.0 with the Beta designation removed. It fixed the radio button default value issue, but not other fields.

The first image is Firefox Developer Edition that displays default values correctly. This is the same result as Safari and Chrome. The second image is the same form in Firefox 103.0.

Image of form as displayed by Firefox Developer Edition
Firefox Developer Edition 103.0b9
Image of form as displayed by Firefox Version 103
Firefox 103.0

The function is an old field where a default value has been added. The radio buttons are fixed. The toggle button is a new field. It does not show "Block" as active even though "Block" is the default value. Formidable's generated code is correct in every case.

Work Around

This jQuery snippet is the workaround we developed for the radio buttons. It can be modified to work with other field types.

Latest Updates

The form works fine in Firefox when first migrated into a new instance WordPress instance the Formidable's Export/Import process. Even after import, adding new fields to the imported form fails to work in Firefox.

Display Range Slider as Currency


This snippet is an updated version of the example found on the Formidable Knowledge Base JavaScript examples page:

The KB example works for one slider at a time. This version works for multiple sliders on a single page. It also uses the JavaScript standard built-in Intl.NumberFormat object. This object enables language-sensitive number formatting.

To use this snippet, follow the same directions as found in the KB article with a couple of exceptions. The HTML needs to be modified to use the [key] shortcode to make the code generic, and the CSS needs to be modified to apply to multiple sliders.

For the custom HTML in Step 1, drop the following span into each slider on the page as instructed in the KB article directly after the [input] shortcode:

<span id="field_[key]_display" class="frm_range_value_currency">$50</span>

Demo Form

Multiple Range Slider Currency Demo
Min: 0 | Max: 100 | Incr: 1
Min: $1,000 | Max: $10,000 | Incr: $500
Min: $10,000 | Max: $100,000 | Incr: $1,000


Here's the jQuery code that should be placed in the form's After Fields section on the Customize HTML page:

Final tips:

  • don't forget to add the multiple slider ids to the recommended CSS from the KB article. (Step 2)
  • the field descriptions for the demo sliders are moved to a position above the [input] shortcode on the form's Customize HTML page


Here's the modified CSS:

Customize HTML

Here's the modified HTML for the formatted sliders used in the demo form:

Disable Copying Email Address into Email Confirmation Field

Roberto Alverez asked this question in the Formidable Community forum:

How I can disable pasting into the email confirmation field? I need to prevent the users from copying and pasting the confirmation email if it contains errors.

Roberto Alverez—Formidable Community Forum

This is a common requirement and one that needs to be satisfied with JavaScript. Of course, there's nothing that can prevent any user from purposefully entering a fake email address into either the email or email confirmation field. However, if the email address is spelled wrong in the email field, copying and pasting it into confirmation exacerbates the problem.

To make this as bullet proof as possible, this JavaScript snippet not only prevents copying and pasting, but also disables drag and drop and the browser's autocomplete function when targeted at the email confirmation field.

To use this snippet, change "field_conf_29yf4d2" to the input id of your email confirmation field and copy the script into the After Fields area on your form's Customize HTML page.

Strip Non-numeric Characters from Phone Numbers

Whenever you capture a phone number on a form, wouldn't be nice to also capture a version of the number that can be used in a tel: link on a view?

Here's a jQuery snippet that will do just that and store the value stripped of non-numeric characters in a hidden field with the exception of the plus sign as used in a country code.

As an example, +1 123-456-7890 becomes +11234567890.

Taming E2PDF Saves

This Mastermind tip is contributed by Rob Levine (@RobL) from the Formidable Slack Community. Thank you Rob!


I am using e2PDF to create a PDF of a submitted Formidable Form. The difference for me is that I both want to save it to the server and do it without the user knowing (or caring) that it’s happening. While the e2PDF documentation has excellent shortcode descriptions, it falls very short of telling you where to use the shortcodes in the Formidable Forms or Views. Formidable suggests using it as part of the Submit message.  In my case that didn’t work because I would need to redirect to a landing page to be able to use the shortcode or use an unnecessarily complex AJAX solution.


The solution is to use Formidable’s frm_after_create_entry and frm_after_update_entry hooks and, using WordPress’ do_shortcode function, execute the e2pdf-save shortcode. That sounds a little easier than it is because I needed to fill in several e2pdf parameters that differed based on which form was being submitted. Here is the example code I used with my specifics stripped out.