WordPress.org

Ready to get started?Download WordPress

Forums

Jetpack by WordPress.com
Jetpack Contact Form: strange corruption in dropdown field list values (11 posts)

  1. paulzee
    Member
    Posted 1 year ago #

    I have been finding a few problems with JetPack Contact Forms. The latest one is a strange and seemingly intermittent corruption of the text in the list of items in a dropdown field. Here's an example:
    http://www.flickr.com/photos/paulszym/8789906357/

    And here's the problematic contact form:
    ` [contact-form][contact-field label='Primary Contact Name' type='name' required='1'/][contact-field label='How would you like to support the event?' type='textarea' required='1'/][contact-field label='Email' type='email' required='1'/][contact-field label='Do you have a Website where we can learn more about you?' type='url'/][contact-field label='If you have additional Contact Information%26#x002c; you can share it here' type='textarea'/][contact-field label='What primary type of support would you like to discuss? ' type='select' options='Volunteer,Sponsor - Donation,Sponsor - Exhibiting,Other'/][contact-field label='Do you have any questions for us?' type='textarea'/][/contact-form]
    `

    This only appears to affect the display, as actually selecting the values returns the correct entry for display. I'm mostly working in Chrome v 26.0.1410.64 m on Win Vista SP2. If I start up Safari in parallel, I don't see the problem, but if I toggle back to Chrome, it appears. In a later session in Chrome, it will appear fine. Refreshing the tab/ page in the current session once it appears doesn't clear it; switching into admin and back doesn't, and neither does opening a new browser tab and opening the page fresh. However, I'm seeing chrome sessions where the problem doesn't appear.

    Given the apparently intermittent nature of the problem, I'm at a bit of a loss as to what the source is.

    and here's the problematic page: http://euriskomelbourne.com/support

    http://wordpress.org/extend/plugins/jetpack/

  2. Jeremy Herve
    Happiness Engineer
    Plugin Author

    Posted 1 year ago #

    I had a look at your site in Chrome, Safari, and Firefox, and the dropdown seems to be displayed properly on all 3 browsers. Have you managed to solve the issue by yourself?

    If you still experience issues, you might want to clear your browser cache, and maybe clear your site's cache if you use a caching plugin.

  3. paulzee
    Member
    Posted 1 year ago #

    Thanks Jeremy.

    Actually, yes: I think I have just gotten to the source of the problem.

    I'm glad its rendering OK for you. It's certainly annoying that I can reproduce it pretty consistently on my primary machine & browser.

    Just for reference, are you running Windows at all? I'm wondering if it's only appearing under Chrome on Windows (which is where I'm seeing it). Certainly for me on Win Vista, Safari and IE are fine. Another thought I'd had was that it might in some way be resource related: I have a lower-spec'd machine with *lots* of browser tabs open, so available memory might be low.

    In any case, it seems to be an artifact of using @font-face.

    I am using liberation-sans throughout the site, with the files uploaded and hosted on our WP site. It's pretty much the only font I'm using, and I've overridden all the CSS that I can in my child theme to make it consistently appear everywhere.

    I had overridden the Contact-form default styles, and also the base CSS styles for input fields: input>, <textarea>, <submit>, <select>, <label>, etc.

    I changed the CSS style for the <select> element to use a different, default font, and the problem was fixed.

    However, I really want the displayed selected element itself to be in the liberation-sans font.

    Unfortunately, the <option> elements don't appear to accept a font or font-family override, so what I've done is hack the grunion-contact-form.php to introduce an <optgroup> element wrapper for the options, and styled that.

    $r .= "\t\t<optgroup label='Choose one of the following:'>\n";
    	foreach ( $this->get_attribute( 'options' ) as $option ) {
    		$option = Grunion_Contact_Form_Plugin::strip_tags( $option );
    		$r .= "\t\t\t<option" . selected( $option, $field_value, false ) . ">" . esc_html( $option ) . "</option>\n";
    	}
    	$r .= "\t\t</optgroup>\n";

    and the CSS addition:

    .contact-form select optgroup {
    font-family: 'Droid Sans', 'Helvetica Neue', Helvetica, Geneva, Sans-serif;
    font-size: 14px;
    font-style: inherit;
    font-variant: inherit;
    font-weight: inherit;
    }

    This patches the problem, however the downside is a) I've had to change the plugin file directly, and b) the optgroup obviously introduces an unselectable first row in the drop-down list: either blank or with a label (as above). I had tried to force the line-height to be 0 in an effort to hide the first row, which didn't work and would have affected all rows anyway.

    I'm not certain whether the actual problem is a side-effect of using smaller sized @font-face font files (they exclude some non-english characters etc, that the drop-down rendering might have been trying to use), or whether it's an aspect/ side effect of using a custom font.

    If it's the former, I guess the fix is to regenerate the font files including whatever is currently missing. However, I'm not quite sure where to begin with figuring that out.

    If it's the latter, then maybe introducing the option group as a contact form option would provide a workaround?

    Suggestions?

  4. Jeremy Herve
    Happiness Engineer
    Plugin Author

    Posted 1 year ago #

    Just for reference, are you running Windows at all? I'm wondering if it's only appearing under Chrome on Windows (which is where I'm seeing it).

    I use a Mac, so the problem might indeed be OS-depended, which would make sense since it's related to fonts.

    What happens when you remove your hacks to the contact form file, and try to customize the look of the form with another font, either with font-face or with a web safe font? Do you experience similar issues?

  5. paulzee
    Member
    Posted 1 year ago #

    What happens when you remove your hacks to the contact form file, and try to customize the look of the form with another font, either with font-face or with a web safe font? Do you experience similar issues?

    I don't know how to customise the form directly when editing a Page in WordPress admin (I'm assuming that's not possible using the shortcode format the form uses?)

    As I noted earlier, when I suspected it might be the @font-face font, I started by overriding the font for the <select>:

    <select name="g135-whatprimarytypeofsupportwouldyouliketodiscuss" id="g135-whatprimarytypeofsupportwouldyouliketodiscuss" class="select">

    by modifying the stylesheet.css to remove liberation-sans

    .contact-form select {
    	font: 12px <del>liberation-sans,</del> 'Droid Sans', 'Helvetica Neue',
    	 	    Helvetica, Geneva, Sans-serif;
    }

    and that highlighted where the problem was, and a path to a workaround.

    The problem is that changing the CSS for .contact-form select modifies the whole block that is wrappered by the select: the selected entry as well as the options list.

    The options themselves won't accept a font styling directly. To fix the options, but not effect the select itself, I introduced the <optgroup> wrapper as an intermediate styling hook.

    <select name="g135-whatprimarytypeofsupportwouldyouliketodiscuss" id="g135-whatprimarytypeofsupportwouldyouliketodiscuss" class="select">
    		<optgroup label="Choose one of the following:">
    			<option>(no option selected)</option>
    			<option>Volunteer</option>
    			<option>Sponsor - Donation</option>
    			<option>Sponsor - Exhibiting</option>
    			<option>Other</option>
    		</optgroup>
    	</select>

    For the project I'm working on, I want to use an open font, not just a web safe font. Ideally, I want to use @font-face to offer the most flexibility.

    So:
    - customising the select and setting an alternative web safe font ('Droid Sans') resolves the display corruption, and doesn't require the hack. However, it leaves the displayed select field and its chosen value "orphaned" from the rest of the form in a different font.
    - To just fix the corrupted dropdown display of the options requires the optgroup element wrapper to be introduced. I don't believe the option element can be font styled directly.
    - I could investigate whether there is a problem with my font-face files, however I'm not certain where to start. Should I just regenerate them, e.g. using font squirrel?

  6. Jeremy Herve
    Happiness Engineer
    Plugin Author

    Posted 1 year ago #

    customising the select and setting an alternative web safe font ('Droid Sans') resolves the display corruption, and doesn't require the hack.

    I could investigate whether there is a problem with my font-face files, however I'm not certain where to start.

    When happens when you use Droid Sans through @font-face, instead of just using the Google-hosted version? Do you experience similar issues?
    I would like to know if the problem is caused by @font-face, or by the font you use.

  7. paulzee
    Member
    Posted 1 year ago #

    Hi @Jeremy!

    Apologies for the delay in replying. I generated some Font Face files for Droid-Sans (just Regular & Bold) using Font Squirrel a couple of days ago, and have finally found time to upload the files, create the font face CSS entries, and test them.

    If I update the option group CSS declaration I added to use the @font-face supplied 'droidsans' font instead of teh Google supplied font, the problem reappears.

    So, I'm thinking:

    - Given that I believe the problem only appears in Chrome on Windows, perhaps Chrome on Windows is the culprit, and that it isn't correctly honoring the FontFace rendering?

    - one possibility is that I'm choosing some problematic option (or not choosing an option I need to) when I generate the font files using Font Squirrel, but unlikely given it works OK under other browser/ OS options.

    - I guess another is that Font Squirrel has an error in the way it generates the files that is causing the issue, but again unlikely due to no problems on other browser/ OS setups.

  8. Jeremy Herve
    Happiness Engineer
    Plugin Author

    Posted 1 year ago #

    - Given that I believe the problem only appears in Chrome on Windows, perhaps Chrome on Windows is the culprit, and that it isn't correctly honoring the FontFace rendering?

    That would be my guess as well. We know that the problem is not linked to a specific font, and we know that the problem is not caused by Font Squirrel (since the issue is browser-specific).

    You managed to work around the problem with the optgroup tag, but we can't include that tag into Jetpack Contact Forms without creating a new option to specify different option groups when using dropdowns in the form.

    I opened #1770-plugins, and we'll consider adding optgroup in a future Jetpack release.

    Thanks for your feedback!

  9. annanicotera
    Member
    Posted 11 months ago #

    Thanks, this worked for us too. We are using Contact Form 7 plugin, and on Chrome the dropdown selections are garbled (I was blaming PHP). But as mentioned above, the selection is correct and is being sent correctly. So overrode the font for the select class. Example:

    select {
        font-size: 12px;
        font-family: Helvetica, Arial, sans-serif;
    }

    And this fixed the issue.

  10. annanicotera
    Member
    Posted 11 months ago #

    By the way for us the problematic font for Windows and Chrome combination for the select dropdown was font face of "Lato."

  11. paulzee
    Member
    Posted 11 months ago #

    @annanictorea great to hear this helped you out! :)

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic