There's several section of our site where the user needs to enter some information, and Firefox's auto fill takes over when the page loads - mostly incorrectly!
For example, there's a "Fax Number" field that for some users Firefox keeps filling in with their email address. If they don't see this and they go to submit the form out validators complain to them that it isn't a valid number format.
This really has our sales guys worried because when they go to look at a customers page, they sometimes see it filled in with their own personal info.
Is there any way to prevent Firefox from doing this?
Add autocomplete="off" to your form tag, as documented in the Mozilla document How to Turn Off Form Autocompletion
<form name="form1" id="form1" method="post" autocomplete="off"
action="http://www.example.com/form.cgi">
[...]
</form>
Do read the section on exceptions and workarounds though - the browser will ignore the autocomplete attribute if you have a Name or Address field in the form!
If you don't care about validation, you can use autocomplete="off"
BTW here's a great article from Mozilla themselves about autocompletion
Firefox usually autocompletes based on the field names, so it sounds to me like you might have some underlying confusion with what your fields are called.
I ran into the same problem on Firefox with forms having a 'username' and 'password' field. In this case autocomplete="off" doesn't seem to work, as stated here: https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion (bottom of page).
The only way I found right know to have en empty fields when opening the page is to empty them in javascript. jQuery code example:
setTimeout(function(){
$('input[name="username"],input[name="password"]').val("");
}, 0);
I know it's ugly (especially the setTimeout but I couldn't figure another way. Even putting this in $(window).load() doesn't seem to work.
Try to use dynamic input names.
If autocomplete="off" in the form fails, try using autocomplete="off" in the input field directly and hit Ctrl + F5.
Actually, since a few weeks I've noticed Firefox started mixing autofill values, dropdownlists show entries even from different sites. They probably broke something in their recent builds. Now some personal entries can be seen by people just asking to check mails on your pc. Desire to block this feature is now very understandable.
Related
I'm trying to interact with a widget on a webpage, enter data into a form element. But I'm getting an error saying the elements isn't currently visible so cannot be interacted with. When manually interacting with the page, the text box asks you to enter something, then that text goes away when you click on the box and accepts input. I've tried having watir click the box first but that isn't working for me either. Here is the raw html:
<input class="symbol-search ui-autocomplete-input x-defaulttext-ghost" autocomplete="off" role="textbox" aria-autocomplete="list" aria-haspopup="true">`
after I click on the box in my browser that changes to this:
<input class="symbol-search ui-autocomplete-input" autocomplete="off" role="textbox" aria-autocomplete="list" aria-haspopup="true">`
Suggestions? Not possible?
One potential problem is that the input element in your code lacks a 'type' attribute, which is what watir uses to distinguish things like text_field from checkbox (since they are all input elements, but act differently)
Without that type attribute (role doesn't really cut it, it's not even a standard element for an input field, not even in html5, not as far as I can tell
Lacking a type attribute, you won't be able to use most of the standard input types supported by watir, which means you won't have access to a .set method You are likely going to have to address this with the basic 'element' class, and then use something like .send_keys once it has been clicked in order to fire keystrokes at it.
Who's widget is this anyway? do they have a demo page that shows an example of it? that would make it easier for people to discover potential ways to work with the control.
This worked for me:
b.text_field(:class => /autocomplete/).set 'hello'
I have validation on all areas of a form, and within the inputs I have hints which are set in the input's Value.
However, the problem I have is that CodeIgniter see's the input as being filled in so a Validation error doesn't occur.
I know I can create a callback_function for each input, but with around 10 forms and 100 inputs I was hoping to avoid this and possibly create a generic function or rule?
Any help is greatly appreciated
You seem to be setting default values for your inputs when what you really want is a placeholder
So instead of this:
<input value="Enter your email" />
You want this:
<input placeholder="Enter your email" />
Depending on how you are setting up your input data, a single callback function could suffice if you really needed it, but really: Don't start hacking up Codeigniter for this. Just use placeholder as it was intended (see javascript solutions for older browsers).
Read more about it here:
http://diveintohtml5.ep.io/forms.html#placeholder
I am assuming what you mean is this:
Ghosted Values http://img864.imageshack.us/img864/8124/ghosted.png
Where the value in there is never meant to be the actual value?
The easy solution is to have a class on the <input> that indicates that it's using a stock input (and also it can grey the text out). When the user clicks in the field javascript can clear the initial value out for you (and remove the marker class).
You can then on the submit button click event go through the form and clear the values of anything with the marker class before you actually submit the form.
I ran into a bug in Firefox involving some out-of-sync information on my form when using the reload button after some form data had been modified (through AJAX).
In IE (7), refreshing always seems to re-submit the originally submitted data. So, if I load a form which is then modified through JS/AJAX and refresh, I see what I saw on the first load.
In Firefox (4), I tend (at least in this case) to see the newer data. However, because I neglected to update certain form elements, the form seems to get re-submitted with partially incorrect data, in this case potentially bringing about serious confusion.
My question is, what exactly is the difference between the way Firefox and IE handle re-posting? Is it documented anywhere? Is either way more standard? And what about other browsers?
Edit: It might be worth noting that Firefox also seems to re-render only certain elements (in my case a label's class changes, but not an input's disabled status). Does Firefox have special rules for how it updates the DOM when refreshing and re-POSTing?
I checked the return from the (re)POST in FF, and confirmed that it has some unusual behavior. In the source of the return I get this bit:
<label id="delSheetContainer"
title="Estimate Sheets with Schedule Activities in the past may not be deleted."
class="">
<input id="delSheet" name="delSheet"
type="checkbox"
tabindex="3"
value="false"
//Inserted note: this is where the disabled value would have been
onclick="this.value=(this.value && 1); bSave=true; setBtn(this.checked);"
/>Delete Sheet
</label>
But in the browser (and Firebug), I see a still-disabled checkbox. The label, however, has been properly updated. Can anybody detail this behavior as well? (references appreciated!)
Edit: As Boris explained, Firefox maintains "form state" across refreshes. My problem is actually being caused by this fact; the server is returning the right stuff, but Firefox maintains the form state anyway.
It's hard to say for sure which effect you're seeing here based on the description, but when you do a reload (not a force-reload) Firefox will keep the values of modified form inputs at whatever value they were before the reload.
So if you have a page with this markup:
<input name="x">
and the user types in "foo" into the textbox and then reloads, the input after the reload will still contain the string "foo".
This applies to hidden inputs whose values are modified via JavaScript as well, which may well account for the behavior you observe.
There is no standard covering reload behavior, really.
The newer versions of Firefox have a new 'feature' that remembers the stuff that was filled out in a form and repopulates the form with these values on refresh (maybe in other situations as well?).
The problem is we have a quite complicated web application which uses a fair bit of ajax and hidden form fields which are never filled out by the user, but by javascript.
Because of this new 'Feature' we get a lot of errors when refreshing form because these fields are suddenly populated with invalid values.
So i'm looking for a way to turn this 'feature' off without disabling auto-completion. (because that IS useful on the fields our customers fill in)
if i put
autocomplete='off'
in my html, the effect is disabled, but this loses auto-completion (obviously).
the problem is in fields getting filled in after a refresh without any user action.
While the password manager will populate a username and password if there is exactly one match, autocomplete itself doesn't automatically populate fields. But I'm guessing you're thinking about the sort of refresh you get, say, if you reload the page. In this case the field values are restored by session history, but you might be able to turn that off by marking your page as uncacheable.
Well you should set the value of these fields to nothing or or whatever default value they have using javascript right before you start your other javascript/ajax tasks.
It is a browser feature - without going into the settings of each client browser you can't disable this.
I suggest more robust validation - client and server side.
After the page is loaded, but before you do any other logic, you should force the value to be empty:
inputElem.value = '';
Here is a jQuery solution I put together.
It doesn't disable the autofill, rather it overrides the fields after the browser has done it's thing.
I was trying to fight Chromes autofill when I made this. Just using .val('') on it's own didn't work since it triggered before chromes autofill functionality kicked it.
var noFiller = $('input[type="text"]');
noFiller.val(' ');
var t=setTimeout(function(){
noFiller.val('');
},60);//keep increasing this number until it works
The Javascript solution (setting field values to empty when the page loads or updates via Ajax) has already been mentioned.
Another option might be to generate the ids of your fields with random numbers attached to them so that the browser can't match them to cached values, but this may screw up other things.
Autocomplete isn't a new thing. Every browser has it. See this http://www.w3.org/Submission/web-forms2/#the-autocomplete
Autofill? Are you sure? Check your input's value attribute with Firebug (Firefox addon). Check you post and response in your ajax. Maybe your ajax is filling it behind scenes.
BTW: remenber to disable any external toolbar. There are some toolbars for Firefox/IE/Chrome/etc that autofill data for the user. Warning with this.
the problem I have is that I have two sets of values in a drop down list. If type 'A' is selected I want a text box to be populated with a value from the database and be read only. If Type 'B' is selected the box is to be empty and editable.
My original code is written in jsp/struts and I have sort of achieved this by using
onchange="javascript:submit()" to reload the page, but this has the obvious drawback of saving any changes you have made which means you can't really cancel.
I also have other problems with the serverside validation due to this method.
Is there a way of making a jsp page reload on change, that way I could write javascript to change the way the page looks according to the values held in the session. That way the save/submit function will only be called when the page has properly been filled out and the server side validation will work as designed.
I know that this is something that AJAX is good at doing but I am trying to avoid it if possible.
AJAX is your only other option my friend, unless on the original page load you load all the other possible values of the Text Box so you don't need to go back to the database. Well, you could try putting the text box in an IFRAME, but you will probably run into more problems with that approach than just going with AJAX.
Without AJAX what you are asking is going to be difficult. Another option (which is ugly) is to write out all possible values for the second list box into a data structure like an array or dictionary.
Then write some javascript to get the values from the data structure when the user selects from the first list box. The amount of javascript you will have to write to get this done and to do it correctly in a cross browser way will be much more difficult than simply using AJAX.
Not sure why you'd try to avoid AJAX in today's world, the JS libraries out there today make it so simple it's crazy not to try it out.
I just had to replace a page that was written as Vincent pointed out. I assume at the time it made sense for the app, given the relative size of the data 4 years ago. Now that the app has scaled though, the page was taking upwards of 30 seconds to parse the data structures repeatedly (poorly written JS? maybe).
I replaced all the logic with a very simple AJAX call to a servlet that simply returns a JSON response of values for the 2nd drop down based on what was passed to it and the response is basically instant.
Good luck to ya.
One way is to change the form's action so that you submit the form to a different url than the "save" url. This lets you reload certain aspects of the form and return to the form itself, instead of committing the data.
<script>
function reload() {
document.forms[0].action="reloadFormData.jsp";
document.forms[0].submit();
}
</script>
<form action="saveData.jsp" method="post">
<select id="A" name="B" onchange="reload()"><!-- blah --></select>
<select id="B" name="B"><!-- blah B --></select>
<input type="submit">
</form>
If I understand you correctly, that you want either a dropdown (<select>) or a textfield (<input type="text">) depending on a choice (typically a checkbox or radiobuttons) somewhere above in a form?
I that case you may need to handle the two types of input differently on the server anyway, so why not have both the selectbox and textfield in the area of the form with different names and id and one of them hidden (display = none). Then toggle visibility when the choice changes. On the server you pick eiter the selectbox or textarea input (wich will both be present unless you disable (disabled="disabled") them too, wich I think is uneccesary) depending on the choice input.
Of course if you expect that the user usually just need the text-input, and a few times only, needing a massive list; it would be better to use ajax to retrieve the list. But if it's the other way around (you need the text-field only occationally), as I assumed above, it will be faster to have both present in the initial form.
If the drop down only contain easily generateable data, like years from now to houndreds of years back it could even be much faster (requiring less bandwidth on the server) to generate the data client side using a for loop in Javascript.
I know a taglib that can fit to your problem:
AjaxTags.
I use this taglib in my J2EE projects and it is very simple to integrate it into web applications.
This taglib give you several tags designed to execute AJAX request in your jsp files.
Here is the description of each tags: http://ajaxtags.sourceforge.net/usage.html
The tag which will help you is the ajax:select tag. It allows you to populate a select tag which depends on an other field without reloading the entire jsp page.
If you more informations about it, ask me and i'll try to answer quicky.
Along the lines of what Strindhaug said, but if you need dynamic data:
Could you have the backend write JS into the page, and then the JS would change the form as required? The backend could propagate some variables for descriptions and such, and then the JS could change/update the form accordingly. If you aren't familiar with this, libs like jQuery make things like this easier and more cross-browser than rolling-your-own (at least in my experience).
Aside:
If you're not using AJAX because it was hard to code (as I didn't for a while because my first experience was from scratch and wasn't pretty), as others have said, libs like MooTools and such make it really easy now. Also, there is not shame in using AJAX properly. It has a bad rap because people do stupid things with it, but if you can't simply write premade values into the form or you have to do live look ups, this is one of AJAX's proper uses.