So, I have a very simple form:
<form action="AJAXemail.php" id='email_form' method="POST" target="_blank" enctype="application/x-www-form-urlencoded">
<p>
<label for="email_from">From:</label>
<input type="text" id="email_from" name="From" size="42" value=
"User Name<user#example.com>" /><br />
<label for="email_body">Message Body</label><br />
<textarea id="email_body" name="Body" rows="10" style="width: 100%"></textarea>
<input type="button" value="Submit" onClick="$('email_form').submit(); bringForth(email_div,false);"/>
</form>
It does what it is supposed to do, submits the body of the text is e-mailed to me. The problem is who it comes from. All I get is "User Name" Then entire "<user#example.com>" is being stripped off. Therefore, I am unable to reply. Using print_r($_REQUEST) shows that the browser is stripping this off before posting.
I'm sure there is a simple reason for this, as well as a simple solution, but for the life of me I can't find it. I've tried changing the enctype but to no avail.
Thanks in advance,
Dave
Try escaping your < and > symbols - "User Name < user#example.com >
Try escaping the angled brackets surrounding the email address: %lt;user#examples.com%gt;
<user#example.com> is considered to be a tag. Try using htmlspecialchars() and htmlspecialchars_decode() on server side
Thanks for the help everyone, but as it turns out these aren't the issue. The $header string needed a space between the "From:" and the POSTed string. So, perhaps this was really an Apple Mail bug all along. I created a fixed header string, and it worked like a charm, and the only difference was that space.
--Dave
Related
I have a site with a checkout page that has always worked beautifully.
Recently, any customer that uses autofill to fill out his info, gets his email address dumped into the company field.
There are no changes that we did that could affect that.
What other tools can I use to get to the bottom of this?
The OP's problem may have been solved (or may have come back again in recent updates!) but as of early 2019, you can diagnose some of these problems by setting the show-autofill-type-predictions flag in chrome://flags, restarting Chrome, then looking at the title (tooltip text) for the input in question. It will tell you what information is being used to guess the "type" of field, and what kind of saved data should be used to populate it.
We still don't know what caused the issue, but for anyone seeing this we ended up making the field readonly so that auto-fill doesn't fill it. We then wrote some JS that on focus, it becomes active and the user can manually fill it in.
<input type="text" name="company" readonly="" onfocus="this.removeAttribute('readonly');">
Found myself in a similar problem, and the autocomplete property is what to be used in this situations
<input type="text" name="fooBar" autocomplete="organization" >
exhaustive list of autocomplete/autofill tags for html form inputs
I encountered a similar problem, having a "company" field placed under a "name" field. That company field was auto-filled with a birth year.
It came from another form on the same site that was displaying a "birthdate" field group just below the "name" field. So chrome stored its auto-fill values in that order.
I ended up with changing my second form field order (sadly it was the best I could do).
You need to add name to the input tag. Browsers use name to identify what info is supposed to go into the field. You can also use the same for ID and for placeholder if you like.
Try this:
<input type="text" name="company" id="company" placeholder="company">
If that still does not work, you might consider turning off autofill for that particular field*:
<input type="text" name="company" id="company" placeholder="company" autocomplete="off">
*you can also turn off autofill for the whole form using the same autocomplete property and off value.
We recently started having an issue like this with our shopping cart page when it was viewed from chrome and you had a saved user name and password for the site. Chrome would inexplicably put the user name value into the quantity box. After much hair-pulling, we realized that there were a hidden user name and password field on the page. These auto-filled correctly when visible. When hidden chrome would auto-fill the quantity input box. By setting autocomplete="username" and autocomplete="current-password" on these controls the issue went away.
The Almost Invisible Input Proxy Trick
I just encountered the same issue with the Chrome 72... It just wanted to fill any kind of field (select or input) as long it was not readonly (with complete no respect for name, autocomplete, etc attributes), with any kind of value it may have stored previously.
You may want to avoid the field to be populated because you listen on the change event or there are some validation on input that may trigger error message just because of bad autofill.
You just want the autofill value to be discarded and not even show (even before javascript execution).
You just provide another field for the browser to fill and you make it almost impossible to see by hiding it under the other field.
<input type="text" id="autofill-if-you-dare" style="position: absolute; z-index: -1; top: 20px; width: 0; height:0" />
Note: You can still hide or remove it by javascript afterwards but you should not hide it before autofilling has been completed, because Chrome will populate only visible fields. And as other answers have stated, it doesn't trigger any event, so you must rely on polling to do so.
I had the problem that chrome will fill in my email in all fields in one of my forms. The other form works correctly.
I found the problem is that the word Name must be before the name input. Or the word email must be before input for email. I had it afterwards. Also using <label for="email">Your email</label> after the email input worked.
**Incorrect autocomplete:**
<input type="text" name="name"/> Your name
<input type="email" name="email"/> Your email
**Correct autocomplete:**
Your name <input type="text" name="name"/>
Your email <input type="email" name="email"/>
or
<label for="name">Your name</label> <input type="text" name="name"/>
<label for="email">Your email</label> <input type="email" name="email"/>
or
<input type="text" name="name"/> <label for="name">Your name</label>
<input type="email" name="email"/> <label for="email">Your email</label>
I solved this problem by making sure the section I was adding was actually wrapped in a <form> tag. The site's global "search" field was being considered part of the page's form because neither had a <form> tag.
Since you can have inputs outside of forms, and this isn't really a big problem for a single-page-app (maybe not the best practice though!), this might be a worthwhile thing to check.
February 2021:
autocomplete="__away" worked for me src.
autocomplete="new-password" also worked src.
Still hacky but it worked for me in Chrome and MS Edge both 88.0.7.
Related(Duplicate?) questions:
Autocomplete Off is completely Ignored
Disabling Chrome Autofill
Autocomplete off vs false?
I have been encountering this issue lately, specifically with chrome. It seems that
autocomplete="off"
isnt being picked up anymore by Chrome. I found the following sources helpful :
Chromium (which i believe is what a lot of Chrome is based on) has the following code that shows the regex that is used when finding fields to populate with Chrome's autocomplete:
https://cs.chromium.org/chromium/src/components/autofill/core/common/autofill_regex_constants.cc?sq=package:chromium&g=0&l=262
I feel like they only other work around that I have found is to follow these conventions :
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete
Or at least make sure that you give an attribute that's disimilar enough from the above list so it that wont get picked up by autocomplete features.
Suppose there are three fields, One with wrong autocomplete.
<input type="text" name="field1"/>
<input type="password" name="field2"/>
<input type="text" name="wrongAutocompleteField3"/>
Now make display of wrongAutocompleteField3 as none:
<style>
.d-none{
display:none;
}
</style>
....
<input type="text" name="wrongAutocompleteField3" class="d-none"/>
On page load remove this .d-none class:
<script>
$(function(){
$('[name="wrongAutocompleteField3"]').removeClass('d-none');
});
</script>
In Chrome, add this on the top of the page:
<input id="" class="" name="" type="password" style="display: none;">
You need to add form tag
<form action="#" method="GET">
<input type="text" name="text"/>
</form>
Welcome to episode 32,342,343 of "Why does Internet Explorer Suck So Much?"...
I've seen lots of reports that IE9 does a crappy job uploading files. Apparently it has lots of caveats about when it will or won't work (If someone has a definitive list I'd love to see it). However, most of the problems/solutions I see have found are related to javascript, usually the jQuery form plugin or something similar.
My form is not submitted via AJAX and the the file input field is not hidden or obscured with css. Yet, I get several support tickets per day from users on IE9 trying to submit the form and "nothing happens" (=the form submits. No errors, but the file is not uploaded.) I haven't gotten a single complaint with a different browser, and IE8 even seems to work (as well as it ever does).
Here's the top of my form. Am I missing something?
<form action="http://mysite.dev/account-settings/?open=resume" method="post" class="wpjb-form" enctype="multipart/form-data">
<input type="hidden" name="resume_form" value="resume_form" />
<fieldset class="wpjb-fieldset-default">
<input id="firstname" name="firstname" type="hidden" class="regular-text " value="John" />
<input id="lastname" name="lastname" type="hidden" class="regular-text " value="Henry" />
<input id="email" name="email" type="hidden" class="regular-text " value="john.henry#johnhenry.com" />
<div class="wpjb-element-input-checkbox wpjb-element-name-is_active">
<label class="wpjb-label">Show resume? </label>
<div class="wpjb-field">
<label for="is_active_1"><input type="checkbox" class="" name="is_active" id="is_active_1" value="1" checked="checked" /> Yes <small style="display:inline;">(Uncheck to hide your resume)</small></label>
</div>
</div>
<div class="wpjb-element-input-select-one wpjb-element-name-file">
<label class="wpjb-label">Upload a <i>new</i> resume file</label>
<div class="wpjb-field">
<input style="line-height:1em;" id="file" name="file" type="file" class="regular-text " />
<small class="wpjb-hint">Accepted file types: doc, docx, odf, pdf, rtf</small>
</div>
</div>
</fieldset>
...
It goes on like this with a couple more <fieldset>s then ends like this:
....
<p class="submit">
<input type="submit" name="Submit" id="wpjb_submit" value="Save Changes" />
</p>
</form>
Update
I'm happy for everyone who has never experienced this problem but it's not just me:
http://answers.microsoft.com/en-us/ie/forum/ie9-windows_vista/cannot-upload-files-using-internet-explorer-9/5724d921-ae71-e011-8dfc-68b599b31bf5
Update2
I'm seeing a lot of suggestions to add a meta tag to force the user agent to IE8...
<meta http-equiv="X-UA-Compatible" content="IE=8" />
I don't want to do this because although I do support IE8, many of the elements on my site render differently in IE8 vs. IE9. This would create a rather sloppy user experience as any IE users would experience I temporary "time warp" back to IE8 on that specific page.
I was able to fix this nightmare of a problem by wrapping a jQuery form submit in a setTimeout:
$('#complete_profile input[type="submit"]').click(function(){
setTimeout(function() {
$('#complete_profile form').submit();
}, 0);
});
This may cause duplicate submission when the form DOES submit, however, so be careful.
As Graham does, I think that this might more be a server issue - also I have never had issues with fileuploads in IE9 (or newer) - I guess you don't want to post the code of the PHP Script that handles the upload?
if any data is not being sent, You could check the post data by your hidden input on your server side script. For example if you're using php it would be something like
<? if($_POST['resume_form']=='resume_form'){
//Do something
} ?>
Or you could also use meta compatible tags for IE to render the page like IE8
<meta http-equiv="X-UA-Compatible" content="IE=8" />
I suggest setting the X-UA-Compatible meta tag value and seeing whether that makes any difference.
See this question for possible values: What does <meta http-equiv="X-UA-Compatible" content="IE=edge"> do?
It may also be that the page is triggering a non-standards mode in IE9. I suggest opening the page in IE9, opening the developer tools, and seeing which browser/document modes are selected. That may give you a clue. Note that the "enctype" form attribute was not supported prior to IE8, so if the browser is using an older doc mode, that attribute is not being recognized.
OK I'd rather leave a comment not an answer but I don't have the points for that yet!
Are the users in quirks mode? Most IE users are unaware of the quirks mode and may have accidentally clicked it when trying to refresh the page (instead of pressing F5). If it is intermittent this could be the reason why.
following on from above.. On the server side how are you checking for empty fields? I'm more on the lines of JS here where you often look for "", null and undefined I'm just thinking that perhaps the quirks mode is sending some fuzzy data that your server side error checking is missing because you aren't looking for it and hence reports all is OK.
I have form, which I use for users to login to the site. It works in Chrome, but for some reason not in IE 9.
Here is the form:
<cfform name="loginform" action="login.cfm" method="post">
<div class="span12">
<div class="span2">
User Name:
</div>
<div class="span2">
<cfinput type="text" name="username" required="yes">
</div>
</div>
<div class="span12">
<div class="span2">
Password:
</div>
<div class="span2">
<cfinput type="password" name="password" required="yes">
</div>
</div>
<div class="span12">
<div class="span2">
<cfinput name="submit" class="btn btn-primary" value="login" type="submit">
</div>
</div>
</cfform>
I am normally accessing the variable as #form.username#, but it is empty if being used in IE.
The simplified use here:
<cfif isdefined("FORM.submit")>
username: #form.username#
</cfif>
I can't see anything wrong with your code above when I run it I have the username field available to me in the form scope correctly. What version of Internet Explorer are you using?
To better debug this I would suggest the following:
Look at the source of the first page and see if there is anything
strange there.
Install Fiddler2 (http://www.fiddler2.com/) then use this to see
exactly what is being posted to login.cfm.
Other things to look at:
Are you using a javascript or CF framework that might be interfering with things?
I don't see anything overtly wrong with your code either. Did you try this in Firefox as well? Sometimes you can get better debugging information there. Possibly an actual error message with it. Both IE and Chrome can do a bit too "good" of a job of obscuring errors on the page.
My suggestion would also be to use plain form tags. Don't use cfform tags. There's not much need for them here. They aren't really helping you much. You could do your own validation on those fields and know exactly what it is that you are validating. You could also test your field that way. Simply change that cfinput to an input and see if that field becomes available in your post. That would pretty quickly let you know that there's an issue with your implementation of the CFFORM tags.
And it's getting a little OT, don't forget to trim the input and wrap it in XMLFormat() and add cfqueryparams to your SQL lookups to minimize scripting and injection attacks. You can also use CF's scriptProtect or rewriting URLs in IIS to help. Allowing free-form entry to FORMs or URLs without any validation is VERY dangerous.
I am trying to build an facebook-iframe application, where you can select friends to send them some information.
So i build a form method="post", put in some input fields, and a friend selector.
The fb:friend input field is renderd .. works fine.. but it doesn't pass over the selected friends.
Do i have to fix it by javascript?
Is there a simpler solution?
thx sven
Code:
<form action="http://xxx.net/index.php" method="post" target="_top">
<input id="sometext" name="sometext" type="text" size="30" maxlength="30">
<br/>
<fb:serverFbml>
<script type="text/fbml">
<fb:fbml>
<fb:friend-selector uid="$user" name="$user" idname="friendselector"/>
</fb:fbml>
</script>
</fb:serverFbml><input type="submit" name="submit" value="Send">
</form>
Actually, to my knowledge you can't fix it with Javascript.
I need more details (!), but it sounds like you may be attempting to use the FBML implementation of fb-friend-selector, without fb-request-form.
If so, try this: https://developers.facebook.com/docs/reference/fbml/request-form/
(!) Can you post your HTML code here? It's likely an implementation issue that we can figure out through your code.
Ok, i am not alone, so here is an other way to cope with it.
Facebook-like styled Multifriendselector.
http://mike.brevoort.com/2010/08/10/introducing-the-jquery-facebook-multi-friend-selector-plugin/
I've a servlet running on Tomcat 5.5.27 and 5.5.26 and have a web form with POST method.
If I use Safari 3.2.1 I see from the logs that Tomcat receives a POST followed immediately/contemporarily by GET and it fails.
If I use Firefox 3.0.5 I see that it sends only POST and everything works.
Trying to debug with Eclipse I see that when using Safari it is the doGet() method that is called while when using Firefox is doPost().
Practically it seems that Safari fires both POST and then immediately GET, while Firefox fires only POST (as it should according to the HTML form).
Is there somebody else who as experienced this ? In this case is there a solution ?
Here is a snippet of the HTML form:
<form action="/vidisearch/Search" method="post" name="SearchForm" id="SearchForm">
<div class="input required">
<label for="Concepts">Concepts, comma separated<br />
ex. (remove quotes) "man-made object, cemetery, graphic event, atmospheric event, tool event"</label>
<input name="concepts" type="text" value="" id="concepts" />
</div>
<div class="input required">
<label for="Operators">Operators, comma separated<br />
ex. (remove quotes) "NOT, AND, OR, AND, AND"</label>
<input type="text" name="operators" value="" id="operators" />
</div>
<div class="input required">
<label for="Specializations">Specializations, comma separated<br />
ex. (remove quotes) "true, false, false, true, false"</label>
<input type="text" name="specializations" value="" id="specializations" />
</div>
<div class="input required">
<label for="Results">Various parameters</label>
<table width="100%" border="0" style="border: 0;">
<tr>
<td>Ontology ID<br />
<input name="ontologyID" type="text" id="ontologyID" value="" /></td>
<td>Result page<br />
<input name="page" type="text" id="page" value="0" /></td>
<td>Shots per page<br />
<input name="shotsPerPage" type="text" id="shotsPerPage" value="20" /></td>
<td>New search<br />
<input name="newSearch" type="text" id="newSearch" value="true" /></td></tr>
</table>
</div>
<div class="submit"><input type="submit" value="Search" /></div>
</form>
I think you have an image tag that has an empty src.
It's hard to say without seeing your HTML for the form, but perhaps your submit button is a wrapped with a link, and Safari is both POSTing the form and following the link (via GET).
I'm not sure what's happening but what I do know is that you need to provide more information.
Maybe it's sending a GET for associated resources (like images) whereas Firefox keeps them in the cache, or you have the form submit button inside an <a> tag, for instance.
Another alternative is a Javascript incompatibility, in case you are submitting something via Javascript.
Sniff the traffic (check out Fiddler or Wireshark) and see what is Safari trying to GET and what's it is POSTing
I'm quite puzzled by the behaviour of Safari since I remind that sometime ago it worked. I'm fearing that one of the latest upgrades has broken something.
Using HTTPScoop I've seen that apparently Safari fires POST followed by GET when it gets the response. I think however that it actually fires both requests at the same time since the date+time of the two responses is the same for both POST and GET.
The response is a RSS feed and has the HTTP/1.1 200 OK code. The second GET asks for the same request URL (http://127.0.0.1:8180/vidisearch/Search) of the POST but the body is 0 bytes, it has of course no GET parameters and the answer is wrong because of the missing parameters.
Firefox instead fires only the POST and gets the correct answer.