Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color tray going outside the screen #443

Open
CaptainHypertext opened this issue Apr 25, 2018 · 3 comments
Open

Color tray going outside the screen #443

CaptainHypertext opened this issue Apr 25, 2018 · 3 comments

Comments

@CaptainHypertext
Copy link

CaptainHypertext commented Apr 25, 2018

I had someone complain about this, the color tray goes off the screen if it's too close to the bottom:
Screenshot of color tray going off the screen

Then I looked at the demo on mosaico.io and noticed the color option isn't even available:
Mosaico color menu is different than what I have

I just updated Mosaico today, how come color is in the Formats menu in the demo but in the menu bar in my version?

@bago
Copy link
Member

bago commented Apr 30, 2018

Mosaico.io demo uses custom configuration for tinymce.
The popup you talk about is a TinyMCE popup. I don't know if there is a configuration to let the popup open upside when there is no space downside, like we do with our own colorpicker.

Contributions are welcome.

@CaptainHypertext
Copy link
Author

It looks like the current version of TinyMCE does this, at least the demo on their site does:

tinymce color

I'll have to look into it more when I have time. If I figure it out, I'll send it in.

@bago
Copy link
Member

bago commented May 2, 2018

We use tinymce in "inline mode": the demo of the screenshot is not from the inline mode. Inline mode doesn't even care about making sure the toolbar itself is visible, so I don't expect they deal with colorpicker positions, but I didn't test this on the latest version because it didn't work fine (we had to stick to 4.5.x because 4.7 have bugs that we reported and have not been fixed, e.g: #429).

bago added a commit that referenced this issue May 10, 2022
We found that most browser/tinymce bugs related to contenteditable are about editing non-DIV elements, so we try to change the template converter to always create an utility DIV and make it editable (Fix #429 and #362).

This should still work with 4.5.x (currently the last version supported by mosaico) and by updated releases.

Mosaico now supports multiple editing styles: the legacy styles are named "singleline" and "multiline" and they are automatically applied depending on the data-ko-editable element (td & div use "multiline", the other ones "singleline") but a data-ko-editor-style="newstyle" can be used to force the use of a different tinymce options set. This set will inherit ko.bindingHandlers.wysiwyg.standardOptions, ko.bindingHandlers.wysiwyg.fullOptions and then ko.bindingHandlers.wysiwyg.extendedOptions. (Fix #244)

This changeset also remove the support for ko.bindingHandlers.wysiwyg.getContentOptions and replaces it with a new option "_use_raw_format" that defines wether to use "raw" format when getting/setting the content from tinymce. The new default is to use "raw" format for the singleline style and non raw format for everything else (the raw in singleline is required in order to prevent tinymce from trimming contents). Note that previously mosaico used raw format for every style, so if you want to preserve the previous behaviour you need to set ko.bindingHandlers.wysiwyg.fullOptions._use_raw_format to true. (should fix #446)

Another breaking change is the default  "extended_valid_elements" option that changed from "strong/b,em/i,*[*]" to "strong/b,em/i" so to enable content filtering and strip unwanted tags (like scripts). You can revert it by setting that option to the old value but beware XSS vulnerabilities.

This changeset enable to upgrade of tinymce to newer 4.x (4.7.x, 4.9.x) and latest 5.x (Fix #593). For 5.x and 6.x we also had to update the scrollfix binding so that the toolbar is correclty moved when the edit area is scrolled.

TinyMCE 6.x compatibility requires more changes because they removed support for "forced_root_block = false" or "forced_root_block = ''" that is needed for the singleline editing. You can trick tinymce by usign "forced_root_block = 'unknownelementname'" but it will prevent use of "ENTER" to insert <br/>.

Issues #596 and #443 may be fixed by this changeset.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants