Running chrome 58.0.3029.110 under Linux similar issue reported under windows.
Data List dynamic (provided through websocket).
When attempting to hit a page with multiple dataLists none of the dataLists fill in.
At the time I found local solution was to simply switch from person 1 to person 2.
Whilst this appears to fix the issue for me this isn't exactly advice I can start handing out to users who so wish to use my site.
I have spent a good few hours trying to locate where the issue is and have found if i have only 1 instance of datalist on that page and under the broken profile . (aka Person 1) the data list appears to work absolutely fine:
<input name="something" list="someresults"/>
<datalist id="someresults"></datalist>
Working fine, I can change above to any of the datalists on the page and all works correctly.
The moment I start using a second dataList on the same page:
<input name="something" list="someresults"/>
<datalist id="someresults"></datalist>
<input name="something2" list="someresults2"/>
<datalist id="someresults2"></datalist>
Neither of them will load the content, the arrow fills up to say content, having a look within html the DOM has been updated with the user input matching results.
Just scratching my head as to what on earth can cause this its obviously not the code since as i say by changing chrome profiles the issue goes away.
Any insight / fix information will be much appreciated
PS process is rather complex if required I can create a few demo pages on the live site to show the problem at hand since I think the actual workings too complex to post all on here
In this case it turned out to be due to two things, maybe my own summary helped narrow it down a lot quicker.
Disable the main form : (if used in main form remove it)
autocomplete="off"
Disable the same tag used in any dataList inputs: (remove tag)
autocomplete="off"
Please note with single dataList and autocomplete="off" on a given field was workng fine.
(really strange)
Related
I am working on a project which involves setting up a bunch of dashboards around the office. The plan is to use Screenly on Raspberry Pi 3s, as it seems to fit our needs for the most part at a very low cost. The problem is, some of the webpages that need to be displayed are locked behind a login. Screenly doesn't have a way to get past this, other than passing the login information and the page redirect through the URL itself. I am aware of the potential security issues this could bring, which is why the account we crated for this use can only view (and not edit) very specific pages.
I want to pass login information through a URL in order to login to a website and directly access a specific page on that website. I have had success passing login information in the form of:
https://website.com/dologin.action?username=CapnCrunch&password=Fr00tl00ps&login=Log+in&os_destination=%2Fpages%2Fviewpage.action%3FpageId%58008
This works nicely when the username and password attribute names are always the same, but not when they change on every refresh. Instead of the HTML attributes for the username box remaining the same every time the login page is accessed, they change slightly every time.
For example, these are the HTML attributes for the username upon loading the page for the first time:
<input name="ct100$phUser$txtUser8193" type"text" id="txtUser8193"
class="login_user border-box" placeholder="My Username">
But when I refresh the page, this same bit of HTML code changes to:
<input name="ct100$phUser$txtUser5516" type"text" id="txtUser5516"
class="login_user border-box" placeholder="My Username">
I would love to pass the URL arguments in the form of:
dologin.action?ct100$phUser$txtUserXxXx=CapnCrunch
Where XxXx is just whatever number the page decided to use at that time.
All the solutions I have found online include using external scripts of some kind. The problem is, Screenly only accepts URLs. Using a script would involve either editing Screenly's source code, or using a proxy webpage.
Is there any way to get around the changing attribute name without using external scripts?
Thanks in advance
I have many websites like Facebook where we write a email address and we just click a button, from this a list of email address's rolls down.
Can anyone tell me how this is achieved? Can it be done with just HTML or do i need to learn any other language?
This is accomplished using Javascript or AJAX requests to query the databases "live" and the return a data set. If I understand you correctly like on Facebook where you type in a Friends name and it will pull back a full list of names which may be your friends.
Jquery, Ajax, Javascript, PHP and Mysql would be some good researching points.
It would be worth searching for "How to create a PHP Ajax request to auto populate HTML fields"
If you are referring to Auto Complete within a browser this is a local setting which is controlled by the end user or their administrator and from what I am aware from HTML alone you can not manipulate this.
I fully agree with Steve's answer. In addition you might want to check out the following:
http://ajaxdump.com/2010/08/11/10-cool-auto-complete-scripts-using-ajaxjquerymootoolsprototype/
http://www.freshdesignweb.com/jquery-ajax-autocomplete-plugins.html
Hope it will help you
Well i go on and search a lot and then i found this is very simple!!
you just need is to type autocomplete = "on" and give it a name and then make a submit button
the code goes here:
<input type="text" name="Name" autocomplete="on" />
<input type="submit" />
I've researched it and cannot find a standard, dependable way to make a browser prevent autofill and not remember the password in a standard login form.
This is important to me as I'm working on a mobile web app, so if the user clicks logout and someone else gets hold of their phone, the browser shouldn't help them out by just handing them the password!
The only solution I can come up with is to make the password field type="text".
Sure, this would mean people can 'shoulder surf' and see what the user is typing in, but that same person could almost as easily just watch the user's fingers to see what password they're typing in...
I don't think spyware is a real issue here either, as I don't think a type="password" character mask is going to stop a malicious keylogger, etc. from doing its stuff.
So, I'm wondering if there are any other security concerns that I may have missed for using type="text" for a password field?
Maybe if I combined this idea with a dynamic/random 'name' attribute for the input, could I be onto a winner?
NB - The solution needs to be compliant with XHTML Mobile Profile.
Also, please refrain from advising me on what is semantically correct here. My priority is security, not semantics. :)
Bad idea - The browser will remember text fields, it just wont enter them automatically as it does with passwords. Instead it will suggest the password as an autocomplete for all to see. I also think reading a password over someones shoulder is much easier than reading their keystrokes.
The reason some browsers dont respect the autocomplete option for passwords is probably because passwords are handled by a separate (in theory more secure) method for handling/storing password data - obviously by using a text field you are bypassing this system with whatever risks that entails.
I dont think there is a definitive solution that doesnt involve js, since at the end of the day you have no real control over what their browser remembers. You can only provide hints and suggestions. Which will be handled in different ways by different browsers. Your best bet is to start by adding :
autocomplete="off"
to your form and input. Works in most browsers - but not all.
The above would go in your form tag and your password input tag, something like:
<form id="form1_randomstring" name="form1" method="post" action="process.php" autocomplete="off">
<input name="password_randomstring" type="password" value="">
As you said in your question, randomizing the form and input names will also trick some browsers into thinking it is dealing with a different form
Also, browser will be extra conservative about what they remember if you use ssl. So this may help.
Finally, as another layer of protection you could have a little onload jquery to clear the form field manually on docready:
$("input[type='password']").val('');
Obviously no help if not running js.
The Definitive solution (maybe?)
You could go a step further and inject the form field using an ajax call (plus generating the random form names + autocomplete and serving the page through ssl). Meaning js would be a requirement for logon but you could then make sure the field was clear and generate the form after page load. I would challenge any browser to complete it then.
If you went for that option both the outer page and the ajax loaded page would have to run through ssl - If you didnt want this an alternative might be to load the ssl form through an iframe (again trade-offs -user base would need to be considered.)
Depending on your requirements and userbase, this could present the most guaranteed option.
NOTE
Autocomplete="off" may not pass strict XHTML validation. An option then may be to add the autocomplete attribute after page load with jquery (again, obviously this wont work without js enabled):
$('#form1').attr('autocomplete', 'off');
As an added point, The simplest way to prevent a key logger would be to provide a select option drop down box and ask them to enter a letter/number from their password. Practically speaking you would have to limit passwords to alphanumeric and ask the user to enter at least three letters/numbers from their password in a series of drop downs.
Summary
No perfect solution but lots of options, you'll have to consider what is right for you. I would maybe go for the ajax call as the main method. You could initially load a link to the form and dynamically replace it with the ajax content so that there is still an option for non js users (less users compromised by autocomplete)
I've got a new site we're working that uses HTML5. Everything validates except for the LESS stylesheets and the Facebook tags. However, Chrome will not autofill properly. If I type 'chr' in the first name field, I get the standard Autofill drop down beneath it, but highlighting, clicking, or otherwise selecting the autofill option does not complete the form as it should. The autofill dropdown merely goes away.
I'm guessing there's something in my HTML that is confusing the autofill code, but I can't seem to find any information on the web about Chrome's autofill implementation and things to look for when it doesn't work.
Edit: I know Autofill is working properly because it works on other sites, even other sites we've developed. It's got to be something specific to the HTML on this site.
Chrome will not save password or autocomplete data if a form is submitted asynchronously. For example, if you submit the following form, Chrome will prompt you to save the password:
<form action="/signin">
<input type="text" name="email" />
<input type="password" name="password" />
<button type="submit">Sign In</button>
</form>
However, if you bind to the submit event and override the default behavior, there will be no prompt and the autocomplete data won't be saved:
$(function(){
$('form').submit(function(e){
e.preventDefault();
$.post($(this).attr('action'), $(this).serialize());
});
});
Tested in 20.0
It seems that Chrome only enables the autofill for forms with a POST method. This may have been a security update on a recent version.
Autofill will work if you do:
<form id="myForm" action="?go" method="post">
It won't work if you omit the method or it's set to get:
<form id="myForm" action="?go" method="get">
<form id="myForm" action="?go">
The only way I know of in HTML to block it is setting: autocomplete="off" on the inputs.
I know drop downs don't work sometimes with autofill, but not text boxes.
I have just fighted with this issue for a while, I found out that a "name" attribute with
a dash like "email-2" would cause Chrome not to autocomplete the field.
In my case I have changed it to email2 and now it works.
It only affects the "name" attribute, while the "id" attribute does not make any difference.
I hope this help someone to save time with such a silly bug.
Greetings from Argentina!
Sorry I can't give you a definitive answer, but I would start with removing everything from the page except that input field. If it works then I would start "binary search" - remove half of the original layout and see if it works, if it isn't - remove another half of what's left and so on, until problem line is found.
Same could be applied to css, js, etc. It is a pretty effective way of searching for errors (for 1024 lines of code you will find exact problem line in just 10 steps).
Only Those elements which require autofill should be there inside the form.otherwise the autofill wont work.Bring only those textboxes under a form.if u already have form involving other elements,separate them and put new form tag around the textboxes which require autofill and nothing else inside it.
I have a problem with a project that I have been working on for a while now. When I open an entry, the inputs all have data in them. However when I go to actually print the entry (using the print-mode, CTRL+P), I notice that the select, and textarea fields are missing the selected or input text on paper. What's going on here? I have googled for hours and can't come up with anything relevant... help! Thanks!
Link to Project (Click "Demo" to create a session - required)
Link to Entry (Click this after you click the 1st link)
Update : Before now I have just been using Google Chrome to test printing. However, when I tried FireFox, it printed alright, is there anything special I need to do to get Chrome to work??...
RESOLUTION : I am using jQuery and I found that by removing the ui-corner-all class from the inputs before printing, I could then print. Thanks anyways!
If you're using Internet Explorer, then this discussion thread may help you (summary: IE can get confused when printing malformed docs). Check your doctype tag matches your output (the w3c markup validator is very useful)
Edit - I see you're using chrome, but I suggest you still check your page is well formed :)
RESOLUTION: I'm using jQuery and I found that by removing the ui-corner-all class from the inputs before printing, I could then print. Thanks anyways!