Hey @joe5,
The default font is now set in the element properties:
I’ll look into adding the placeholder font color in the next update 
Happy to make it more useful for the community. Appreciate your suggestions. Keep them coming 
I also noticed when I paste images (especially screenshots) it makes them really big. It may be better if images were scaled down to a % width of the input by default? So the user can decide to make it bigger later, instead of it being too big in the first place.
Also, images cause a problem when you do paste or drag/drop something in. If the user doesn’t know to hit enter afterwards, the input doesn’t resize automatically to fit the height.
@gaurav Is it possible to add more fonts manually? Since I use the font “Overpass” this would be really useful. Many texts are sent to me in other fonts, so I can no longer set them to the standard font in the editor.
Thanks 
Hey @j.hennersdorf,
It should work with any font you add to bubble (refer bubble’s documentation on adding fonts). Just set the element to that font in the bubble editor like you would for an usual element and you’re good to go
@gaurav - the rich text posts on our site seem to load extremely slow if it’s a really long post. Any way to lazy load some of the content until after they’ve hit the page?
Hey @joe5 actually the content shouldn’t be causing increased load times.
My hunch is you’re using mentions / hashtags etc. and providing a huge list (e.g. do a search for all users as input list) and bubble probably tried to load all that data. Try disabling the @, # and / tags etc. and try once if the load time changes
Can you PM me the setup and I can take a look?
I have a related performance Q:
The process of saving rich text inputs to the database is very slow when they contains images. When text only they are fine. Also the process of deleting these entries seems to take a long time.
Even just accessing my database when I’m using the builder takes forever when I have a rich text entry with images saved in there. Bubble warns me some entries are larger than 10mb and causing performance issues.
I’m saving / displaying as HTML.
So the saving / reading of the data from database is pretty much upto bubble. My guess is they made some behind the scenes changes which causes long ‘text’ type of data stored in the database to be read slowly. Not really much I can do about that.
Do make sure you’re on the latest version of plugin though, so that the images are actually uploaded to the bubble server. If the entire image is being stored as base64 text within the fields that would be a big performance drag.
Hey Joe, have you found any work around for this? I want to users to upload images + text but the data is just way too slow to load.
Hey I have not unfortunately! This post with rich text is still running pretty slow (https://www.nucode.co/post/building-a-social-platform-without-writing-a-single-line-of-code-1572319560023x684791671096344600), so I’m hoping to figure this out. I’ve submitted a bug report about container issues within bubble, and will submit another for this issue 
1 Like
Hi Gaurav!
As far as I can tell, copy and pasting an image from the clipboard will result in the image being uploaded (both in rich text and html format settings).
Drag and drop and uploading from the toolbar will result in images being placed in the text as base64 which quickly leads to huge text files that break the app.
We now have to disable drag an drop and image in the toolbar to keep things running. But it’s not an ideal workflow. On windows pasting only seems to work when you have an image on the clipboard (for example from a screenshot) but it doesnt work when you copy an image file from the explorer. However, on Mac this does work…
Are you planning to do the S3 upload also for the drag and drop and image toolbar options? Much appreciated!
edit
another little issue with the editor we uncovered; when you paste text the editor scrolls to the top of the page. This was tested on a blank page (but in an app with additional plugins) so I’m not sure if it is because of a conflict or if you can reproduce it in your end…
Update
So images can be added 3 ways:
- Paste from clipboard
- Select from toolbar
- Drag-n-drop
Only case 1 was being handled until now to create the image file in your bubble app database and then insert only the link in rich text. For case 2 & 3, adding images would result in addition inside the rich text of the image file contents, resulting to huge strings.
I built & added custom handler for case 2 as well just now. I’ve pushed an update 
In the new version selecting image files from toolbar will also upload to your bubble database (also preserves filename) and then insert only the resulting link in the rich content (fixing that long string problem).
case 3 (i.e. drag-n-drop) is still pending for custom handling.
2 Likes
Integrated bubble s3 upload for the toolbar option
Haven’t been able to reproduce on my end so could likely be a result of some external plugin messing with headers
1 Like
My man, night and day difference. Thank you.
And ty @vincent56 for being able to articulate the problem.
Amazing work! Thanks!
Will run some tests to see if there is a script interfering.
We debugged with all the plugins in the app but the problem persisted. Ended up creating a new blank app with just the editor plugin and the behavior is the same.
https://bdktexteditor.bubbleapps.io/version-test/bdkeditor
username/password
Whenever you scroll the viewport and you paste anything into the editor, the viewport scrolls to the top. If you type, it is ok but if you paste anything this will happen.
@vincent56
I tried on the demo page and can replicate this behavior only on demo 1 and not demo 2 or 3. My guess is it works fine on demo 2 because the text editor’s parent is a group and not the main page.
Can you try putting the editor inside a group and let me know if that fixes it. That would imply it scrolls to the top of parent container of the text editor.
Thanks for checking. Putting it in a group doesn’t change. And in your demo, the issue is also on demo 2. But you need to be scrolled just below the editor before pasting. We see two behaviors:
When the top of the editor is not in the viewport, but only slightly after pasting, the viewport scrolls up to the top of the element.
When you scroll slightly further down making more of the editor not in view, after pasting the viewport scolls up beyond the editor (but not completely to the top of the page)
It seems this behaviour should operate the other way around exactly. After pasting, the viewport should scroll to the end of the pasted text.
Apparently this is an open issue with the library itself. I’m gonna try a couple of potential solutions and see if any fixes it.
@gaurav This is not just a copy/paste result. I have the same problem when I add a hyperlink.
Thanks