Let’s see what others think, but in the meantime there’s no reason to not fix the bug. There are other html setters which already set innerHTML.
Harbs > On Oct 18, 2022, at 11:29 PM, Hugo Ferreira <hferreira...@gmail.com> wrote: > > Yes, I saw that helper (I searched for it name) :) > Yes, it's exactly what I mean: put this in one of the limites of the > workflow and never in the middle. > That's my opinion. > > > > Harbs <harbs.li...@gmail.com> escreveu no dia terça, 18/10/2022 à(s) 08:06: > >> There’s a sanitizeHTML helper function that’s relatively new. >> >> I don’t have a strong opinion on whether it should be sanitized by default >> or that should be the application developer’s responsibility. >> >> As far as PAYG is concerned, it’s better to put the responsibility on the >> app developer. >> >> As far as security is concerned, it would be better to sanitize in the >> framework. >> >> I personally would give precedence to PAYG because the threat of a XSS >> attack using innerHTML is a bit of a stretch in Royale. >> >> We should come up with a policy, document it, and stick to it across the >> framework. >> >> If we do sanitize in the components, it should probably happen in the >> model setter. >> >> What do others think? >> >>> On Oct 18, 2022, at 2:32 AM, Hugo Ferreira <hferreira...@gmail.com> >> wrote: >>> >>> Thank you very much. >>> I see the bug. >>> I hope that the Label (html property) that FormHeading that depends on, >>> doesn't have the same issue :) >>> >>> About the sanitize: >>> Should this be really a reponsibility of FormHeadingView !? >>> Shouldn't the responsibility on one of the edges (the limit of html >>> property core or on the end application) ? >>> In the middle, we could ending "sanitizing" too much just to be ensure. >>> >>> >>> >>> Harbs <harbs.li...@gmail.com> escreveu no dia segunda, 17/10/2022 à(s) >>> 19:25: >>> >>>> I assume this is Jewel. I don’t use Jewel, but I just looked at >>>> FormHeadingView and textChangeHandler is used for both textChange and >>>> htmlChange. In both cases it sets the text rather than html in the >>>> htmlChange case. That seems to be broken. >>>> >>>> If you fix this, make sure the html is sanitized when applied. >>>> >>>> Harbs >>>> >>>>> On Oct 16, 2022, at 5:17 PM, Hugo Ferreira <hferreira...@gmail.com> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm using FormHeading when I have a lot of fields and want to create a >>>>> vertical separation (group of data). >>>>> It's OK, however I needed now to use in the FormHeading texto some HTML >>>>> (basic stuff like strong and br), however the property "text" of >>>>> FormHeading it's for simple real strings and not HTML. >>>>> I saw the html property, however this property does nothing. >>>>> It's something that it's not already implemented in the core or I'm >>>> missing >>>>> something ? >>>>> >>>>> I saw tht I can workaround, using a pure html:Div with innerHTML but I >>>> have >>>>> read in the past that I should avoid it. >>>> >>>> >> >>
