I want to override the default behavior of an input control.
I use <input type="datetime-local"> and it works almost fine for the user, with a pretty calendar and all. But for automated tests it's a nightmare.
Is it possible to patch the browser such that type="datetime-local" act as a type="text"? I would enable this mode during tests and solve all my problems.
I think I need this to be on the browser level because such tags are generated dynamically all the time via vue.js so a one-time attribute replacement won't work. I use the latest chrome version.
Update
I need to bypass the fancy data-editing that is almost-locale-dependant. If I can set the value of the control to 2018-06-12T19:30 I will be happy. This is actually the fallback behavior on browsers that don't support datetime-local.
This cannot be javascript based on a control by control basis, since the page is accessed via browser-driver and selenium.
Try to put this in JS
var d = document.getElementById("date").value;
var n = d.toString();
And then use n
Related
I need to remove the browser's autofill/suggestion feature.
This autofill is disabled using autocomplete="off" in Textfield component. once I do that this brings browser's auto fill feature
In Edge, If I turn off the "Save and fill the personal info" option in "Settings/Profile/Personal info" the above suggestion is not shown. Is there any way without turning off that setting I can remove the autofill feature using Material UI TextField property or CSS property "input:-webkit-autofill"
If autocomplete fails to work, most likely it's a bug or for some reason, react is preventing the attribute from being modified.
However, I know a simple way to bypass by changing the type attribute to something random, where the browser can't understand what it should ask from the user and therefore, the browser can't prompt an autofill.
For example on a standard HTML input tag:
<input type="inputText"/>
This will still treat it as an input field, however, it will not attempt to autofill.
Its browser functionality which you cant handle from code level. If you want to prevent it than you have to made setting changes in browser
Turning Off Autofill in Chrome
Click the Chrome menu icon. (Three dots at top right of screen.)
Click on Settings.
In the "Autofill" section, expand the area for which you wish to disable Autofill.
Toggle the setting OFF if it is on. The system will automatically save your settings.
More details found here => https://support.iclasspro.com/hc/en-us/articles/218569268-How-Do-I-Disable-or-Clear-AutoFill-AutoComplete-Information-
So for html you can simply put autocomplete="new-password" in your
Auto-complete="off" can also be used nut it has some drawbacks.
Banks and other security institutes turn auto complete off .Problem is user change frequently their passwords and fields and use simple passwords to remeber.So auto complete is good feature in these cases.
But you can try this solution if you want .I hope it will work fine
<input type="password" autocomplete="new-password">
you can add autocomplete="off" to your form or input but many modern browsers do not support autocomplete="off" for login fields
but you can prevent it using autocomplete="new-password"
Preventing autofilling with autocomplete="new-password"
for more information check this link
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#the_autocomplete_attribute_and_login_fields
Its most likely a bug, the solution I've found works best is to have auto-complete have a hard coded random value which will prevent a user from using auto-complete...
Try this:
<input type='password' name='pass' autocomplete='password' />
In terms of the auto-complete value you can have anything you want there.
New edit:
<script>
// Execute this code when page is
// totally loaded
$(document).ready(function () {
/* Setting the autocomplete of
input field to off to make
autofill to disable */
$("#name").prop("autocomplete", "off");
});
</script>
We have an existing web application with hundreds of input fields through different applications that has been installed at several sites. At this most recent site, however, we have started having an issue with the back button automatically filling in input fields. This is an issue because the only time we allow the back button is if an error occurred in processing. So the flow is as follows:
1) ask user to scan a barcode
2) an error occurs on the back-end and it directs them to an error page with only a back button
3) the user hits back and is directed to the input page, input form is now filled with the previously inputted data.
I know this is some form of caching or browser issue because when I hit the web app from my personal pc, it doesn't do it. But when they use their android scanning devices and if we load it up on the application server, it does.
I have fixed this on a couple of pages with autocomplete="off" on the input fields, but it just isn't feasible for us to change this on each of hundreds of input fields if we can avoid it. I'm looking for some browser or windows function to turn off to disable this.
I have tried turning off all of the chrome autocomplete fields, and I have tried disabling the cache in dev tools with no luck. Is there another way to disable this without using that autocomplete tag?
If inputs are inside form you can put it on form.
If not you've only one option to use a global script to add attribute on each input something like below but it'll put it on every input and I'm not sure if it'll have any side effects for your case:
field.setAttribute( "autocomplete", "new-password" );
Hope it helps.
I'm working with a contenteditable iframe that is being using for basic WYSIWYG editing. I've noticed a strange difference in the way that a Tab keypress event is handled between Chrome and Firefox.
When the document of the iframe has been configured using designMode = 'On', a tab pressed inside the document will skip to the next control in Firefox (expected) but create the following pre white-spaced span in Chrome
<span class="Apple-tab-span" style="white-space:pre"> </span>
Here's an example.
Interestingly, when the body of the iframe is setup instead using body.setAttribute("contenteditable", "true"), which I assumed was the same approach done in a different way, both browsers work as i would expect; moving the focus to the next tab index.
Can anyone explain why?
I'm afraid that the only answer is "just because". Don't expect that there's a reason behind how something works in contenteditable. I experienced hundreds of times that no one really cared or had time to care about that. When you've got bugs like https://code.google.com/p/chromium/issues/detail?id=226941 which make contenteditable totally irritating for users on Chrome & Opera and which hasn't been even confirmed by developers throughout entire year, then a small difference in Tab's behaviour is a detail which you have to fix and forget ;).
Use:
document.designMode = 'on';
Insted of
body.setAttribute("contenteditable", "true")
A recurring problem with modern web design can be summed up as "too much sh** all over the place". There're two problems with this: one, it takes up memory and takes longer to load, and two, it visually clutters the webpage.
If I just wanted to solve the second problem, I wouldn't need help. JavaScript can delete DOM nodes and CSS can hide them, so there're already a few visible ways to simply hide parts of a webpage. What I want to do is solve the first problem - make a webpage load faster by not loading certain elements.
I'm pretty sure it's impossible to selectively download certain parts of an HTML file. But once the source is downloaded, the browser doesn't have to actually parse and display all of it, does it?
Of course, if this is done after it's already been parsed and displayed, it would be pointless. So I need a way to tell Chrome what to do before it begins parsing the HTML. Is this possible, and do you think it would significantly reduce load time/memory usage?
Yeah, unfortunately Ive never seen a way of changing the html before Chrome renders it.
But as far as blocking things that that page gets to display then Id recommend just using AdBlock https://chrome.google.com/webstore/detail/gighmmpiobklfepjocnamgkkbiglidom
AdBlock can be used to stop resources (js,images,css,xmlhttprequest) from ever being downloaded (it blocks them in the background using the webRequest api) and can also hide elements using css...its rather effective (just remember to select advanced options in its option page and then when you click the AdBlock button you get "Show the resource list"). Also installing Flashblock can help...or disable plugins in Chromes settings, doing this will make them not load but will still show on the page and then you can make them load.
Totally possible! Meet the newest Chrome API: webRequest, finalized in the current version of Chrome - 17.
Docs for webRequest: http://code.google.com/chrome/extensions/webRequest.html#event-onBeforeRequest
I'm trying to think of a solid way to do this... one suggestion I have is using the 'sub_frame' filter, and watching if it's a like/tweet/social button url
You could also block known analytics stuff... and the list goes on! Have fun! Do you have an email list I can sub to for when you launch? If not, get one and drop me a comment!
(From the comments, here is how a innerHTML hack could work)
//This modLoop constantly peers into and modifies the innerHTML in attempt to modify the html before it's fully processed.
var modLoop = function modLoop(){
var html = document.documentElement.innerHTML
//modify the page html before it's processed!
//like: html = html.replace('//google'sCDN.com/jquery/1.7.1/', chrome.extension.getURL('localjQuery.1.7.1.js'));
//I just pulled that ^ out of nowhere, you'll want to put careful thought into it.
//Then, mod the innerHTML:
document.documentElement.innerHTML = html;
setTimeout(modLoop, 1);
};
var starter = function starter(){
if (document.documentElement.innerHTML && document.documentElement.innerHTML.lengh > 0) {
modLoop();
} else {
setTimeout(starter, 1);
}
};
starter();
I've been asked to fix a few bugs on a website, and one of them is throwing me for a loop. Due to the style layout of this particular site, when a user selects and copies text from a specified area, they copy rich text data which if pasted into a rich text editor, results in a large black text on black-background blob.
Ideally, I would like to strip all style data, or somehow enable plain text copying on a particular set of data.
Is this possible? Or would I have to resort to something like a a Flash applet like what GitHub uses for Git URLs?
If you're happy with using JavaScript to solve the problem you can capture the "oncopy" events (credit to #FirstZero) on the elements you wish to restyle, and then restyle the element using JavaScript and style it back again after a timeout.
If you are okay using jQuery you can use JavaScript similar to the following:
$('p').bind(
'copy',
function(e) {
var copyElem= $(e.target);
var defaultColor = copyElem.css('color');
copyElem.css('color', 'pink'); // Change the color to pink for copy
window.setTimeout(
function() {copyElem.css('color', defaultColor);}, // Change it back
1
);
}
);
(Try it out in jsFiddle)
Note that this would be neater if there existed an onaftercopy event, but unfortunately there doesn't seem to.
I've only tested the above solution in Chrome, but it should work in Firefox (since 3.0), latest versions of Chrome and Safari, and in Internet Explorer. It will probably not work in Opera.
Many many years ago, I made a custom form that replicated the look of a menu on a video game. At the time, Firefox didn't allow many form UI widgets (Firefox 2.something?) to be styled with CSS. Apparently in the last few years that has changed.
What I wound up doing to resolve this problem was creating a very large input text-box with the content passed in via the value="" attribute. (<input type="text", not <textarea)
Despite the ability to style input boxes and their content, this information is not retained when copying the text itself. So I completely side-stepped the issue, and the fixes are live!
It was quite a bit simpler too, absolutely no-JS required.