materialize: [Bug]: Toast html/unsafeHtml not work
Before submitting…
- I have searched for duplicate or closed issues.
- I have read the CONTRIBUTING document and my issue is following the guidelines.
- I have read the template completely before filling it in.
Context
Hello, I made migration to alpha on my project and I need to rework so much code that permit to find a bug with html/unsafeHtml not work
Current Behavior
Toast displayed but without content
Expected behavior
toast should show the unsafeHtml in
Possible Solutions or Causes
I just check all about html inject is commented why ?
Steps to reproduce
Just use M.toast({unsafeHtml: '<span>I am toast content</span>'});
its not work even on documentation
Your Environment
last mozilla and chrome last ubuntu
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 17 (2 by maintainers)
I have a PR with an alternative, simple solution: allow to specify some element as tooltip content. A new property data-tooltip-id will allow specify an element as tooltip content instead of text.
Hello sorry for hijacking but since the ticket is still open and I have problem with no content showing if I add classes to the toast. Also I’m using “text” and not “unsafeHtml” like the Author I write the toast like this:
M.toast({ text: 'Invalid Email', classes: 'error' })
I was expecting the toast to show up with the content. Instead I got an empty box
I believe that we are in the same page when it come to terms of XSS attack prevention: raw HTML/script injection should be avoided whenever possible.
However, I also believe that we should standardize this behaviour for v2.x giving the possibility to the developer of “customizing” the generated element either through a “render/creation” function or through an
unsafe
option as we did before.On the one hand, in the first option we would give flexibility of “customization” of the rendered toast to the developers: every single modification would be up to them (sanitization, DOM manipulation etc.).
On the other hand, the second option would make it simpler to provide raw HTML content, but the MaterializeCSS framework itself would have to inject it (it would still be up to the developer to make the proper sanitization).
To sum up, considering the context of attack prevention, I’d opt by the first option, since it would also make it easier to create custom components by inheritance, while giving the oppotunity of element customization natively (without having to perform direct HTML injection).
PS.: There is also the necessity of “normalization” of support to “custom HTML”, since its support used to have different name for each component. The affected ones would be:
allowUnsafeHTML
;unsafeHTML
;unsafeHTML
.