Pro 4.0.11 and previous versions / inline text editing

Beta
#1

Generally speaking I am finding the inline text editing quite buggy.

I mostly use Firefox and am on the latest release.

Often if I attempt to edit headlines or sub-headlines inline the inline editing stops working and the display does not update.

I need to then edit the text in the text editor of either the headline or sub-headline and at that time the text doesn’t update in the preview.

Sometimes clicking another header and editing it inline and then going back to the headline with the issue will also resolve the problem but it is really annoying.

Alternatively I need to refresh the builder.

1 Like
#2

I’ve been having the same problem too. In Safari.

#3

Same here. Chrome on Windows.

#4

Thanks! I saw this mentioned in support recently although I’ve not been able to reproduce it in Chrome, Safari, or Firefox on OSX. Next time it pops up would you mind checking the browser’s dev tools and let me know if you see any errors in there.

Let me know if there’s anything else that feels similar like using toolbar buttons or whatever is happening when it fails.

Would really like to get to the bottom of this and iron it out.

#5

I think I mentioned it previously in another thread but thought it deserved its own post.

I am working on a PC if that helps. I can check if I can replicate it on my mac but I don’t really use it for dev work.

I did look in my dev tools but there weren’t any errors. I will look again as perhaps I missed something. It happens fairly often when working in the inline editor. Mostly with headlines. I will check if it is something specific like when sub-headlines or graphics also being active but at the moment I think that sort of thing doesn’t matter.

Another odd thing that I have occasionally is that with things like widths. The default is set to none. If I set a width it then defaults to px however the actual width often doesn’t take effect and I need to switch from px to any other option and then switch back before the width takes effect.

#6

Haven’t read through all of the above just yet but seems to be what I’ve been encountering for awhile now. If inline editing and clicking from element to element too quickly all mouse actions disappear as does inline editing. Can still use the builder workspace / outline pane to edit.

MacOS11 + Chrome latest + Pro 4.0.11

#7

Thanks for all the additional info here!

In Pro 4.1 we fixed an issue where inline editing wouldn’t work with dynamic content items. I was able to finally reproduce the issue where it didn’t truly update the markup when you stopped editing. Now it’s back to the original behavior where you see the DC tags while inline editing and they’re regenerated when you stop. I believe this has all been corrected now, but let me know if you still see any thing peculiar. Thanks!

#8

I’m still finding this to be an issue. This happens a lot when doing inline editing.

I’ll often either copy and paste a headline or duplicate it multiple times.

Afterwards I will go and edit the text for all the headlines inline. As soon as I start doing this the headlines become unresponsive at some point. Possible if I move to quickly from one headline to the next one.

If I refresh the page or wait a bit and then click another heading the issue resolves but then happens again pretty quickly.

Pro 4.1.5 / Windows 10 / Firefox.

#9

Thanks @urchindesign,

We’ll take another look at it.

#10

No problem. I think it may happen when the initial headline that I’ve just edited hasn’t 100% updated yet and I move onto the next one or move the focus away from the element too quickly.

#11

Just had this happen again today. Seems pretty regular when duplicating / working with multiple elements inline. Snapped a screenshot of console but not sure any of this is helpful. See below:

Screen Shot 2021-02-15 at 1.56.43 PM
Screen Shot 2021-02-15 at 1.56.43 PM928×328 72.6 KB

#12

I’m also getting a weird one when sometimes if I open a text element and go the WYSIWYG editor then everything crashes with a bunch of errors. I’ll try and get the errors next time it happens but seems to happen quite a lot.

#13

Happened again. Similar errors.

Screen Shot 2021-02-17 at 12.54.18 PM
Screen Shot 2021-02-17 at 12.54.18 PM946×1002 228 KB

#14

Thanks for the extra info on this. I’m putting with some notes I have going but still haven’t deciphered why this is happening yet.

#15

Following up here with a bit more info. I have a habit of using the shortcut ⌘ + A to select all text in an element. I’ve noticed that if I go to edit text via the inline editor, and hit ⌘ + A too soon (before the inline editor has fully appeared) it selects all elements on the page and then stalls out causing the issues noted above. This isn’t 100% of the issue but it does fairly consistently aid in causing the issue to surface. Hope this helps :slight_smile:

#16

I’m not doing that at all and the issue still persists frequently.

#17

Thanks! Unfortunately this still isn’t an area we’ve prioritized. For a bit of extra context, we’re using the WordPress version of TinyMCE to handle inline editing. We do this because it gives the best approximation of what the final front end will look like after WordPress filters are run. However, it happens to be very finicky and is not designed to work in environments where the editor can be turned on/off repeatedly (at least it’s not optimized for it). Usually these fixes take a long time to iron out and involve introducing peculiar hacks and workarounds.

Put more simply, it’s as if we are tightening our grip around that particular feature - and doing that it increases the chance of it breaking when we change other live preview code. Until responsive styling is finished, there’s still a bunch in flux and changes we may need to make to the live preview rendering systems. We’ll be able to revisit it when we stop having to move things around.

Thank you all for your patience with this one. We definitely want to get it sorted out but we’re not quite at the best place to dig in any further on the issue.

#18

Just want to upvote this issue. It’s currently my #1 issue in my workflow - results in me having to refresh the editor window. Hope you guys get the time to replace TinyMCE, it’s a bit of a dinosaur now lol

1 Like
#19

I also find this annoying but normally you don’t actually need a refresh. If you just put the focus onto another element for a second or so things work again. I normally select another header and then come back to the one I was on. Not ideal but at least you don’t need to refresh.

#20

@urchindesign thanks for the tip on that!

@mjshelley Unfortunately it would be challenging to replace. The main reason is that the WordPress version of TinyMCE runs analogs for the types of formatting they do on the front end. That’s not really something we want to develop or maintain ourselves since it opens up new liabilities.