How to enable textarea tags in HTMLPurifier?
I tried with:
$config->set('HTML.Allowed', 'textarea');
But it doesnt work. How to solve this problem?
textarea is not supported unless you load the Forms module. This module gets loaded if you turn on %HTML.Trusted, but this directive also turns on JavaScript and should only be used for trusted users.
Related
I have a small web app which has <a href="> tag which renders the only runtime I mean it does not appear in HTML page it appears only in chrome developers tools. How to eliminate such kind a tag and override or edit it.
I tried editing code via its script when I inspected for long it split document.querySelector("#m360CrA483349594983") but when I search entire project there's no sign of it!
demos written can be eliminated for sure!
Even I tried to Enable Local Overrides on but nothing seems to work that mysterious tag is kept coming saying
"demos written can be eliminated for sure!"
once the dom is ready you can access the element
<script>
(function() {
// the DOM will be available here
document.getElementById("m360CrA483349594983");
})();
</script>
Add body onload event listener in order to search for tag appearing at runtime.
Also, pay attention to tag ID value, it seems it is generated every time, so, you won't be able to find it by static ID
I want to remove the default autocomplete from all input fields of my web application using CSS only. I will put that CSS in the header of my web application to get the effect of that css on all web pages. I can't put autocomplete=off in all input fields individually. as there are more than 200 input in the application.
It is not possible since autocomplete=off is not a css attribute, but a html5 one.
Maybe you want to do it with js by setting element's attr, or just find and replace those 200 entries once and for all.
More info on autocomplete=off can be found in MDN.
It's not possible in CSS. You can achieve it by using JS.
I have a page in XPages that I use to open and edit a document. There are two ways to open a document in edit-mode: first in read-mode then click a button to put it in edit-mode, or open it directly in edit-mode. Both work in all browsers, yet IE seems to handle both cases differently. We found this out when working with the SWING API.
Opening directly in edit-mode in IE (8/9/10) works, via read-mode to edit-mode doesn't. What we found is that the internal representation of a textarea field differs: when opened in edit-mode, there are more properties, but most importantly, the return+linefeeds are correctly set in both the value and the innerText property.
The button just contains a simple Change Mode action.
Has anyone heard of this anomaly? And does someone know what we did wrong?
PS I'll try to build a simple XPage that shows this behaviour more clearly tomorrow.
For IE switching from read to edit mode, you need a full page refresh
I've noticed that browsers don't recognize my password field as a potential auto-complete target. I'm assuming this has something to do with the fact that the password field isn't in the original HTML - it's created by my GWT script after the page has loaded.
Is there a way to tell a browser, "hey, here's this form, treat it like usual?" How can I let browsers hook into my app for autofill?
There are some workarounds to get the browser to auto-complete your login like the one described here.
After struggling some time with it I strongly suggest you simply wrap an existing form of your host page (do not generate the inputs with GWT), do a form.submit() on it and have a servlet listen to the request.
I believe that password fields ( tags with type="password") are not auto-filled for fairly obvious security reasons. It doesn't matter that the field is added after page load by your GWT script.
Try mimicking the field in regular HTML and compare that to how your GWT app creates the DOM structure. Perhaps your GWT app is putting the page together differently?
I am trying to create a file upload field that has a little bit of style to it, but I seem to be having problems finding examples of this. I know part of the reason is that the field itself varies from browser to browser.
Any ideas how to do this? Or is there a way to do this without using a file element of a form that can be styled?
If what you mean is the text field for the file names, you can use the input[type=file] selector in the css files. For example :
input[type=file] { background-color: red; }
If what you mean is the file selection dialog box, I think it's browser/OS dependent and there's little (if any) you can do about it.
I have come up on this problem before. Unfortunately, file uploads are nearly impossible to style consistently across browsers. As of CSS 2, I think, the W3C standard specifically leaves behavior undefined--think of how many ways it would need to be implemented on different platforms. Firefox, for example, generates anonymous button and input elements inside the file upload element which only inherit some of the properties that you set on the upload element itself.
You can get some to work using, for example, Furuno's method, but know that the behavior will be spotty and differ widely across platforms/browsers.
Here's some links I found:
QuirksMode Article
One Extra Pixel Article (look for the file input styling section)
This would fit for your requirement.
If you are using jQuery, have a look at this plugin - https://github.com/ajaxray/bootstrap-file-field
This tiny plugin will display the file input field as a bootstrap button (with configurable classes) and will show selected file names (or selection errors) beautifully.
Additionally you can set various restrictions using simple data-attributes or JS settings.
e,g, data-file-types="image/jpeg,image/png" will restrict selecting file types except jpg and png images.