Skip to main content

Hi - the rich text field on one of our pages is not giving rich text options anymore. I rebuilt the page and omitted the chatter component, which seemed to make the rich text field work again. Once i added the chatter component back to the page the rich text field broke again. 

By ‘broke’ i mean i click into the field and it behaves like a regular text field instead of showing the formatting options. 

Any ideas?

I am seeing this issue also. RTE is working on a field editor, but not working within a pop up.


Pop Up RTE:


Not in a Pop Up RTE


I’m seeing the same behavior in both Firefox and Chrome.


Within my visualforce page settings I changed the skuid version to a higher version and that seemed to do the trick.


Hi Kaede, would you mind providing some more information about the changes that you made? I.e. where you made them, what they were, and what their old values were (if you can remember)? I’m not able to reproduce the issue in my dev org on Brooklyn 9.3.1. 


I tried that in my sandbox and it didn’t fix it for me.  I changed it to version 9.3.

af2f9b4d1c2b830bee85ed62417f47cf6bb9d2c0.png


I upgraded to 9.3 as well. Maybe something else fixed it and it was just a coincidence


I can’t remember what the previous values were for the version numbers.


running into this problem again on another page… 

Removing the chatter component makes the rich text fields work properly, but that isn’t an actual solution. Changing the page versions does not help. I have upgraded to the most recent version of Skuid. 


I really need help here. Updated my skuid version. My users keep having this issue and I don’t know how to fix it myself. 


Kaede,

There is currently an issue where the chatter component and rich text fields don’t play nice together (if both are on a page the rich text palette doesn’t show up). We’ll let you know once a future release fixes this, but in the meantime, the best workaround is to show the Chatter component in an iframe in a template component. You can see an example of how to do that on this post.

Sorry for the inconvenience!


I have experienced this issue but it isn’t chatter component related. I have a page that opens a pop up. On that pop up page, there is a button that opens another pop up. In that second, topmost popup, there is a rich field editor that is not working. As a work around I reconfigured and got rid of the second pop up , so I am fine, but thought I should report it.


I’m sure you’ve mentioned it elsewhere, but can I ask which Skuid version you’re using?


In the latest release, Brooklyn Update 1, Iteration 5, I’m not able to reproduce the behavior you’re describing. There may be more relevant details in your scenario, but setting up 2 nested popups with 2 different rich text fields (both built on the same model and object) allows me to see the Rich Text toolbar in both popups. This is in Chrome, by the way.


I’m on 9.5.5. I was using chrome at the time. … strange…


Has the most recent release resolved this issue?


Any chance this is resolved yet or will be resolved soon? The workaround is not very elegant. 


Has the issue been resolved that would allow for rich text fields and the standard chatter component to exist on the same page?


Hi Kaede,

The issue is still unresolved as of today. We have not forgotten about this, but a satisfactory resolution is much more involved than it may seem, and will likely be part of a larger group of related improvements on our roadmap. We appreciate your patience, and apologize for the inconvenience. 


Approx. timing?


bump. such a frustrating issue to help users with. iframing the chatter component in makes scrolling wonky, so increasing the height of the iframe to fix the wonky scrolling seems like a good fix, but then image preview component from files posted in chatter shows up halfway down the page and out of view unless the user scrolls way down past all the grayed out stuff. and if the user clicks on the title of the image instead of trying to preview it (because preview doesn’t seem to work unless they know the trick to scroll wayyyy down) it just clears the entire iframe component and they are left with a blank chatter feed and no way to see the image they were trying to get a better view of. :( 


This is still causing us issues and I do not have a workaround. Using the iframed in chatter component does not allow for our users to upload files from salesforce on a chatter feed. This has been a known issue for a year now. What’s up? 

Here’s what’s happening: https://cl.ly/0r2t3H1z3w1P


Hi Kaede,


I’m sorry you’ve had continued frustrations on this issue. I am testing a similar configuration Skuid version 11.1.18 to what you’re reporting in Skuid version 11.1.18. In Skuid classic, the two components together in a Skuid page are still causing the issue you reported.


However, in your video, I saw that you’re running in Lightning now. When I test the same page in Lightning with the Skuid page running natively (meaning, deployed via the Skuid Page Lightning component), the Chatter feed and rich text field in edit mode are cooperating as expected. You’re seeing the classic Chatter feed in your video, that would be because you’ve got an iframe in the mix, which makes Skuid think it’s not operating in Lightning, so it doesn’t load the Lightning Chatter.


Are you able to test the scenario out in Lightning? I’ll share the XML for my page below, but it’s got a custom rich text field that you’d want to replace with a rich text field you can test with. If you’re on an older version of Skuid, this might not work correctly, but it looks promising in Lightning + Skuid 11.1.18 so far.


<skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="true" useviewportmeta="true" showheader="true">
<models>
<model id="acc" limit="1" query="true" createrowifnonefound="false" datasource="salesforce" sobject="Account">
<fields>
<field id="RecordTypeId"/>
<field id="Name"/>
<field id="Id"/>
<field id="RichTextExperiment__c"/>
</fields>
<conditions/>
<actions/>
</model>
</models>
<components>
<social model="acc" uniqueid="sk-2pyU-249">
<actions/>
</social>
<basicfieldeditor showheader="true" showsavecancel="true" showerrorsinline="true" model="acc" uniqueid="sk-2pyU-344" mode="read">
<columns>
<column width="50%">
<sections>
<section title="Section A">
<fields>
<field uniqueid="sk-2pyU-345" id="RecordTypeId"/>
<field uniqueid="sk-2pyU-346" id="Name"/>
<field uniqueid="sk-2pyU-347" id="Id"/>
</fields>
</section>
</sections>
</column>
<column width="50%">
<sections>
<section title="Section B" collapsible="no">
<fields>
<field uniqueid="sk-2pyU-348" id="RichTextExperiment__c"/>
</fields>
</section>
</sections>
</column>
</columns>
</basicfieldeditor>
</components>
<resources>
<labels/>
<javascript/>
<css/>
<actionsequences uniqueid="sk-2pyU-218"/>
</resources>
<styles>
<styleitem type="background" bgtype="none"/>
</styles>
</skuidpage>

Thanks so much.

Some users are on lightning, some are not. Does this work for classic and lightning?


Hi Kaede. The limitation still exists in Classic in the most recent versions of Skuid. I am checking in with our engineering team on any updates to the issue. As I alluded to before, lifting this limitation requires a fundamental change to the backend of how Skuid is enabling rich text editing in Classic Salesforce. Lightning-deployed Skuid pages are able to use Lightning’s own (newer) rich text editor so that’s why the same pages behave differently between Lightning and Classic Salesforce.


bump


I still have issues with this in Lightning. Using the workaround causes other problems for the user - like double scroll bars and weird issues when trying to upload/view/preview files. 


https://cl.ly/18636cc154f4


https://cl.ly/87c9adf6ceb3


Hi Kaede, I have a couple follow-up questions:
Which release of Skuid are you using currently?
Are you deploying the pictured Skuid page via Visualforce, or iframe? 

My understanding is that the issue is resolved in Lightning now that Skuid doesn’t use CKEditor in Lightning any more, but remains a limitation in Classic. In your videos, it looks like you’ve got the Classic version of Chatter, instead of the Lightning version. Skuid tries to detect which environment it’s in, and load the corresponding version of Chatter. If Skuid isn’t inside the Lightning Component, it’ll load the Classic Chatter feed like you’re seeing here. Have you tried deploying your Skuid page natively with the Skuid Page Lightning component


Reply