Bugs to Report

Support
#1

Some of these are not new in 4.x but I’m kind of tired of them lingering unfixed…

  1. If you activate the graphic option for the Headline element, it inserts a 0.5em margin to the right. But never removes this when you choose Column stacking instead of Row. This bug has existed for 2 years.

  2. If you insert a font awesome shortcode into a text/headline element, you must now always edit the text using the code editor, because double clicking or otherwise trying to edit it in Rich text turns the entire text -including the shortcode(s) into plain text.

Eg code: Test text whatever can go here [x_icon type="star" style="font-size:80%"][x_icon type="star" style="font-size:80%"][x_icon type="star" style="font-size:80%"][x_icon type="star" style="font-size:80%"][x_icon type="star-half" style="font-size:80%"]

  1. New in 4.x if you double click an element to edit it, you cannot then click elsewhere in the element to move the cursor. Doing so deactivates inline editing. This violates the expected behavior of every inline text editor in existence.

  2. Right clicking on Chrome in the editor has sometimes produced the Chrome menu instead of the Pro menu but with 4.x it’s much worse. Any plans to change this mechanism so it’s more reliable?

REQUEST

  1. When you deactivate options in the left sidebar, it still leaves a big margin between that option and those above and below it. This prevents more in-use options from being shown in the sidebar at a time w/o scrolling, leading to a poorer experience. I can’t see why the spacing can’t be tightened up.
#2

Hey Greg,

Thanks for reaching out about all this.

  1. This one is kind of a tradeoff. It’s not really a bug, just a side effect of how the element works. The graphic margin always exists with a 0.5em default. It’s only applied when the graphic is enabled. Because Row is the default orientation, we opted to add this margin so it looks decent when you first enable the feature (not all crammed together). The problem is, when you toggle to Column, we don’t know if you already changed the margin. We don’t really want to get into situations where changing one control alters the value of another control that could have already been manipulated. I know it can

  2. I’ve tried this out in 4.0. I’ve tested this with both the Text and Headline elements, and editing with both Rich Text and Inline Editing. In all cases I’m able to change the icons and content. The only difference I’m seeing is that when you start inline editing it will make the shortcodes appear inline. This is needed since we can’t edit the generated HTML directly.

  3. Tried this out as well and I can move the cursor, create selections, and use the toolbar buttons to manipulate those selections.

  4. If you’re holding cmd/ctrl it will disable the built in context menu. Been trying to reproduce this one also and it is consistently working.

I’m using a pretty vanilla development site with WordPress 5.6. Perhaps what you’ve been experiencing with the editors/tinymce is a side effect of something that tries to extend TinyMCE (used in both cases). If there’s a site you have that I could login to (login credentials can be added to a secure note) I can test everything on my end again and see if there’s any conflict.

Another thought is it might be a browser extension altering behavior. If an extension caused the window to lose focus, even momentarily, I could see how the inline editing issue would happen.

As for the sidebar spacing, I’ll mention it to our designers in case they want to consider it. Something you can do is go into the Dev Console (enable from preferences) and use the UI CSS feature. Try adding this:

.tco-control-group.is-off {
  padding-bottom: 0;
}

That will reduce the spacing. The UI CSS feature is handy way (per user account) to alter the app itself to your liking.

#3

  1. I’d eliminate the automatic 0.5em right margin then. First off, it’s too small in most cases, and second this is the only instance I am aware of where you add artificial margin/padding in by default to an element. Just keeping it consistent and clean is a better approach.

  2. When you inline edit, yes it shows the shortcodes and that’s expected, but clicking off the element - as in “I’m done editing” - does not restore it to its pre plain-text appearance.

  3. This seems to be another case of Pro causing memory leaks in Chrome that result in odd behavior, especially with 15+ tabs open or busy pages with many elements. Similarly, there are all sorts of issues (and this existed prior to 4.x) with inline editing where double clicks and even some single clicks result in the element moving to another row/column, the entire page being selected (as if you hit CTRL-A), etc. All can be chalked up to how Pro’s javascript works in Chrome. I’m not a dev so I couldn’t tell you, but this observation has been reliable for a year.

  4. I’m not holding CTRL, obviously. This is another one that is very reliable to reproduce on Windows 10 Chrome. I’m starting to get the idea that Pro devs use neither Windows 10 nor Chrome and that’s why this stuff gets through. But absolutely an issue and easily reproducible.

In the past some of these issues were looked at and the dev admitted the issue was present, and that the next release would rework how [the mechanism] worked, so each major release I bring these up, and it’s the same story every time. You guys should create a few substantial packed to the nines website examples to see how Pro works on busy sites - way different from plain vanilla sites. I would imagine issues do not typically crop up on lean, vanilla dev sites.

I can rule out browser extensions, because when this odd TinyMCE related behavior first was noticed beginning after the 3.x update, we tested using Firefox (brand new w/no cache or extensions) and got the same result on the same sites. Oddly, when we used OBS to screen record this happening, the issue occurred far less, making it a PITA to show you, and I’m not devy enough to know how that could be related. But that’s what I see.

#4

Hey Greg,

Thank you for your feedback. I’ll pass your points to Alex. I believe he is working on improving the builders’ performance.

I’d just comment on the Context Menu part since I’m using Windows 10 and Chrome and I couldn’t replicate what you described. The Builder’s Context Menu always popup. You just need to ensure you’re right-clicking on the builder and not outside areas like in the video below.

Thanks.

#5

What I’m finding is that these issues seem to occur on real, developed sites with a good number of elements. We’re seeing more and more examples of Pro being slow to respond (eg. Chrome’s context sensitive menu comes up first, overriding Pro’s. Also edits to existing text being delayed by several seconds, typing itself out as the user did, just several seconds later. That last bug is new to 4.x.

I will say we’re probably in the top 1% of Pro users in terms of pushing the editor to its limits and so we’re able to discover all these bugs and glitches pretty quickly, whereas lightweight-devs and non-dev users never encounter them because they are barely scratching the surface. We routinely experience likely memory leak issues where Pro simply stops displaying active changes at all, requiring a reload of the page. All of it is related in that Pro doesn’t respond in time to commands, and in some cases at all, after a period of use on healthy-sized websites.

I’ll also add we use Windows 10 Chrome exclusively, do not run any extensions, nor do we have any other top-layer software running while we use the editor. We typically have 10-15 tabs open in Chrome.

#6

Hey Greg,

Thank you for your tests. I’ve forwarded this thread to our development team.

#7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.