Since the release of the security patches in August 2021 that prevents Cross-Site Scripting via Rich-Text Content I noticed that the output of HTML Content Elements suddenly changed in our projects. Some tag attributes and tags got removed by the newly introduced HTML Sanitizer (when the template is modified so that t3:// style TypoLinks get rendered).
So simply overriding the default Html.html Fluid Template, changing the <f:format.raw> to <f:format.html> and adding a html decoding like in the following example is no longer sufficient.
<f:section name="Main">
<f:comment> We use this to render links and other stuff in html elements </f:comment>
<f:format.htmlentitiesDecode>
<f:format.html parseFuncTSPath="lib.parseFunc">
{data.bodytext}
</f:format.html>
</f:format.htmlentitiesDecode>
</f:section>
The easiest way to prevent changes in your html codes output provided by HTML Content Elements is to disable the sanitizer globally by adding lib.parseFunc.htmlSanitize = 0 to your TypoScript config, what is not ideal.
How can I disable the parseFunc.htmlSanitize only for this purpose?
Or is there an other solution to render TypoLinks within HTML Content Elements?
Note: You don't need to disable the HTML Sanitizer if you do not override the Html.html template!
Simply make a copy of lib.parseFunc and disable the sanitizer in this copy.
lib.parseHtmlFunc < lib.parseFunc
lib.parseHtmlFunc.htmlSanitize = 0
Then use this lib in your Html.html template.
<f:section name="Main">
<f:comment> We use this to render links and other stuff in html elements </f:comment>
<f:format.htmlentitiesDecode>
<f:format.html parseFuncTSPath="lib.parseHtmlFunc">
{data.bodytext}
</f:format.html>
</f:format.htmlentitiesDecode>
</f:section>
Thanks to #OliverHader for bringing me to the right track.
I use a php script that inserts data into the jos_content table in order to create an article. In the article content is a textarea with the attribute required.
<textarea name="comment" required></textarea>
But, when I open my article manager and find this created article, there is no required attribute anymore -- everything else is fine. The same thing happens with maxlength.
I use JCE, so I am assuming that it is responsible for killing these attributes somehow.
How can I prevent these attributes from being stripped from my textarea element within my articles?
Have you tried to change the settings of JCE editor. Go to the Editor Global Configuration > Cleanup and Output and set the HTML Validation to NO.
This will affect your code, but it will keep the attributes of textareas in the articles. Of course, you have to set the attribute to have value: required="required".
Or, just use another editor: Tiny etc...
I faced to the same issue. The problem is that JCE will remove all element which do not have any content inside.
In other words, this will be removed:
<textarea name="comment" required></textarea>
And this will not:
<textarea name="comment" required> </textarea>
I'm implementing my own autocompletion on an <input> field inside a UIWebView, and the built-in keyboard autocompletion interferes with the user experience. Is there a way to use HTML or Javascript to signal to iOS that it shouldn't try to autocomplete?
In my comments I mentioned using the html attribute autocomplete but I tested it, and it doesn't address your issue. However, there is an attribute specific to Mobile Safari which may help. You could try turning off autocorrect like so:
<input type="text" id="your-field" autocorrect="off" />
This question already has answers here:
How do I style the HTML form validation error messages with CSS?
(4 answers)
Closed 4 days ago.
Say you have some HTML like this:
<form>
<input placeholder="Some text!" required>
<input type="email" placeholder="An Email!" required>
<input type="submit" value="A Button!">
</form>
Because of the required attributes, newer Webkits and Firefoxes show a validation message next to the field if you leave it blank.
They respond to being styled by a rule such as:
div {
font: Helvetica;
}
But I can't find a more specific selector for them. Does anyone know what selector is used, or will be used, or even a bug report for webkit/gecko relating to this?
( JSFiddle showing that they can be styled with a div selector: http://jsfiddle.net/p7kK5/ )
Chrome does not allow styling form validation bubbles anymore: https://code.google.com/p/chromium/issues/detail?id=259050
Additionally, Firefox has support for the element attribute x-moz-errormessage which enables you to change the text of the error message, which is something you could do in Chrome using CSS to and -webkit-validation-bubble-message. See more about x-moz-errormessage on the MDN Docs page.
As of yet, Firefox has no way to style the error bubbles.
You'll need to use more specific selectors for everything else I'm afraid.. body > div etc.
I have a problem that in IE8 the enter does not work to submit a form. I have generated a test page to expose this problem. It seems that displaying the form in the onLoad function disables results that the enter button does not trigger a submit anymore. Is this a bug in IE8 or is it some security issue?
The code to reproduce this is:
onload = function() {
document.getElementById('test').style.display = 'block';
}
#test {
display: none;
}
<form id="test" method="get" action="javascript:alert('woei!')">
<input type="text" name="user" value="">
<input type="password" name="pw" value="">
<input type="submit" value="submit" id="submit">
</form>
I have found a proper solution and wanted it to share with u guys.
Instead of using <input type="submit...>, use <button type="submit"...>.
This will do exactly the same in the other browsers (IE6-7, FF3) AND works in IE8. :)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<style type="text/css">
#test {
display: none;
}
</style>
<script type="text/javascript">
onload = function() {
document.getElementById('test').style.display = 'block';
};
</script>
</head>
<body>
<form id="test" method="get" action="javascript:alert('woei!')">
<input type="text" name="user" value="" />
<input type="password" name="pw" value="" />
<button type="submit" value="submit" id="submit"></button>
</form>
</body>
</html>
$("form input").keypress(function (e) {
if(e.which === 13) {
$("form").submit();
}
});
Above is a proper fix. Ref: IE Not submitting my form on enter press of enter key?
I think everthing is much more complicated than you think...
when a form's display value is set to none with a css class or just with a style attribute on page inital, hitting the enter key in a text field does not work only if you have more than one input field with text type... if you have one text field it works fine.. if you have more than one, it does not fire form submission...
Here i made a demo...
Works Fine (Normal Form)
http://yasinergul.com/stackoverflow/ie8-enter-key-bug/one.html
Works Fine (Form hidden & set back visible but it's with one text input)
http://yasinergul.com/stackoverflow/ie8-enter-key-bug/two.html
Does Not Work (Form hidden & set back visible but it's with two text input)
http://yasinergul.com/stackoverflow/ie8-enter-key-bug/three.html
i think the best approach is to give a .hidden class to the object but not setting display:none for this css selector. you can make it hidden with jquery like
$(".hidden").hide();
as the page loads the form is shown for miliseconds but gets hidden after jquery works...
I can't say if it is a bug exactly, but I can confirm that the behavior you report has changed in IE 8... and I imagine it is probably a bug, not an deliberate change.
If the form is set with CSS display:none the default submit button behavior doesn't work.
Other browsers, including IE 7 (or even IE 8 using IE 7 standard compatibility mode) do not have problems.
I've worked around the problem myself by just using height:0px; in the CSS, then having javascript set the appropriate height when I want to show the form. Using height instead, the default enter key submit behavior seems to work normally.
Old ticket, but I'd like to add what I think is the explanation:
IE8 does the following peculiar thing: the Enter key will submit the form, but any
<input type="submit" name="MySubmitButton" value="I hope I detect THIS VALUE in POST" />
won't be sent in the POST.
IE9 changes the behavior and sends the value. Chrome has always sent the value, as far as my tests have shown.
I hope this helps...
For any future users stumbling upon this question:
What worked for me was adding a DOCTYPE:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
A fix to what #Jitendra Pancholi suggested- now it submits only the form we want, not all of them
$("form input").keypress(function (e) {
if(e.which === 13) {
$(this.form).submit();
}
});
I tried it in IE8 and it works for me. You have to make sure that part of the form has focus though.
Javascript has a focus function that you can use to set the focus if that's what you need.
var textbox = document.getElementById("whatever name input box's id will be");
if(textbox) textbox.focus();
You may want to add a onkeyup event to your input boxes so that if you hit an enter in the input box then it will also submit.
As CodePartizan mentioned, you need the focus on the button otherwise, so if you tab over to the button, or click on it, it seems to work for me also.
I believe Yasin has got the point.
I just had the same problem: multiple text fields within a form whose visibility is "hidden".
My workaround (to prevent the form from flashing) is to set the form opacity to 0 in the css, and then customise its style settings with jQuery on document ready.
I believe this is not something to fix with JS.
Yeah, I was bitten by this bug too today. I found this workaround, though (diff from the OP):
<script type="text/javascript">
onload = function() {
document.getElementById('test').style.display = 'block';
+ document.getElementById('test').innerHTML =
+ document.getElementById('test').innerHTML;
}
</script>
</head>
Simply recreate the contents of the form from the contents of itself. Yikes. But it works. (Famous last words...)
This works for me in IE8. I had this problem when using only one input field.
Read more: http://www.rachaelarnold.com/dev/archive/enter-key-form-submission-bug#ixzz2Y5Zwgj2k
I had the same issue with ie and none of the solutions helped until I read this:
http://www.rachaelarnold.com/dev/archive/enter-key-form-submission-bug#ixzz2Y5Zwgj2k
my form only had one input field....duh! :)
Found a working solution.
Make the submit button invisible instead of using display:none;
input#submit {
color: transparent;
background: transparent;
border: 0px;
}