Inline Editing Problematic After 3.x Update

[co50]

Since the Pro 3.x update, inline editing, especially the double-click to enter inline editing has been quite problematic. These sentiments are echo’d by my entire team to remove any possibility that my PC setup changed at the same time Pro 3.x was released.

Double clicking tends to produce a random result 25% of the time in our tests, after experiencing this annoyance in production for the past 2 weeks. Most times double clicking enters inline edit mode as it should. Other times, it’s a disaster. The element will have the light green box around it for a brief second and then it reverts back to “selected” mode. Often the dev doesn’t notice this right away and begins typing only to be greeted by popups asking if they really want to leave the page (?). Presumably, a keyboard shortcut was triggered. So you guys have a clear issue where your interceptor - whatever it is that’s grabbing those mouse clicks and telling javascript to “enter inline edit mode” - is not functioning at 100%. More like 75%. And that’s bad.

Other issues with this include little to no tolerance for tiny mouse movements. If one double clicks and the mouse moves even a couple of pixels during the double click sequence, as is common, inline editing won’t start. It’s treated as two single clicks.

Lastly, sometimes the mouse click interceptor gets very confused and will enter inline edit mode, immediately exit it (element remains selected), and then flash the page. OR it will highlight the line or paragraph. This means the click interceptor has failed to take proper control and the OS or browser is preempting your interceptor.

In a nutshell, this 3.x release has been a giant regression for devs who work quickly and efficiently. Our team moves at the speed of light - we use every keyboard shortcut, time-saving practice, etc. Pro 3.x as it is right this moment is not compatible with fast development. There are too many stop points, broken functions, etc. 2.x was superior in every possible way in this aspect. So much so that we’d gladly revert back to 2.x if it were possible.

Please do better on this. I realize many of your users, beta team, and dev team work slower than us and may never encounter these issues. But they certainly persist and after 2 weeks of dealing with them, gathering feedback, and testing the scenarios, we have to speak up about it.

We all use Chrome (latest) on Win 7.

[albrecht]

Hi @co50,

Thanks for writing. We tried using inline editing in headlines and text elements with haste but was unable to replicate the issue.

Have you already tried clearing or purging cache? If yes, then could you be able to create a login credential for us for the site in a secure note that is having this issue? So that we can investigate further.

@Themeco1

###Secure Notes

It is very common to need to share sensitive information with our staff such as login or FTP information. In order to keep this private, be sure to use the Secure Note button that you will find at the bottom of each reply.

Thanks!

[co50]

A couple of things at play here that make your ability to reproduce it harder than us:

1. The pages this occurs on are well-built out, sometimes with 50+ text and/or headline elements. These pages are very memory intensive and demanding on the browser as evidenced that it takes 4-5 seconds to load the page in Pro editor - and this is on a 4.5Ghz jacked up PC with all the fixin’s.

2. Your typical customers don’t routinely edit sites they build. It’s usually 1) build it, 2) give to client, and then 3) see you later. Maybe some edits down the road, but nothing crazy. With some of our clients, we are constantly editing their pages (i.e. events where things change rapidly) and these bugs flesh out very quickly when doing this. Every major release cycle, we’re able to find and report 1/3 to 1/2 of all bugs fixed in your point updates - within an hour of using the new release. Go look at our Support posts and you’ll see them all.

3. Most of you guys use Macs + Safari. So you’re using a different browser on a different OS. Many devs use Macs. Others Win10. So people on Win7 experience bugs with your software that nobody on other Oses is experiencing. I’m not saying that this is the reason in this case, but it sure seems like it could be - since this bug is glaring and easily repeatable on our end, but impossible on yours. For this reason, giving you Admin access may not be fruitful.

Here’s a video of the problem: https://co50.com/ThemecoSupport.mp4

I need to stress that this bug did not occur in the prior version of Pro (2.6?). We edit our pages the exact same way and have not changed anything with the way we work. They only thing that changed is the version of Pro we use.

[rad]

Hi @co50,

I think it’s because of server, internet, and device’s response time versus with the editing speed or action a user been doing. I can reproduce it sometimes but not all the time.

On my end, it usually happens when the builder is on the process of generating a preview then I put consecutive changes which makes the preview inaccurate. There is no such near-zero response time that’s why any other consecutive action could be affected by what you’re currently doing. That’s why I only prefer inline editing for short content. I also experienced the popup when I typed, not just on our builder but on other builders too. And that’s when the whole thing freezes but you continue typing like you press R and browser acknowledge it as the page reloads. Like other builders and web apps, key shortcuts are browser feature and they are also just utilizing it. Your app could freeze, delay or stop, but it doesn’t mean the browser will also stop executing any command it perceives.

The number of cores doesn’t always improve speed especially if it’s not just about the device, but also the internet, server and browser capability.

The inline editing uses the browser feature such as https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content as a sample. It’s limited to browser capability if it’s buggy then any app that uses it will be buggy as well.

And You’ll notice that other online code and content editing doesn’t prefer using that, instead, the process is edit-save-run, instead of edit-while-run, because it’s quite buggy. I have tried that before on my previous projects making content editable (live editing) and it has random/varying results.

Though I’m not saying we’ll stop there we’re of course open to any improvement. We’ll see what we can do to make it more user-responsive. Is there a way you could set up two staging sites where it’s working and not? It’s best if we can investigate it that way, I’m not saying there is nothing wrong, but maybe you’re correct and we’re not just seeing it on our end. Then please provide the login credentials of those two in the secure note.

Thanks!

[co50]

This is unrelated to Internet speed, server, or any other 3rd party nonsense. We have the fastest equipment on the planet. The fastest PCs, the fastest servers, and a 1Gb connection. Trust me, it ain’t that. Besides, you know how Javascript works - the whole point is that it runs in the browser. If we’re gonna call back to the server why not just use AJAX or PHP? So we know it’s your JavaScript, right?

And we know it’s your code, specific to inline editing text/headline elements, because inline editing of ANYTHING in the left sidebar works flawlessly 100% of the time no matter how fast or which parts you edit. Double clicking on a column name, element name, section name, etc. works flawlessly with no hesitation whatsoever. One of my guys pointed this out and I tested myself. You can inline edit anything in the left sidebar as much as you want and it’s on point. In the same session on the same page, inline editing of text/headline elements is the disaster I’ve talked about in this thread. So you’ve got the same exact function, which works flawlessly in one place and can’t handle it in another section.

As I’ve eluded to in my past posts here, based on the changes you made in 3.0, it’s evident that very few of your customers routinely edit sites they’ve already built, edit large complicated sites with lots of text/headline elements, and also use Win7 w/Chrome. Which is why it’s not coming up as this major issue.

Upon further testing today, using the exact same browser on the same machine we edited one of the sites that this issue occurs on frequently which is quite large and has 50+ text/headline elements. We then conducted the same tests on a site with only 18 text/headline elements. Inline editing worked flawlessly. No issues. Other sites with the same or fewer elements produced the same results. Here’s a page that reliably causes the inline editing problem: https://dgevents.com/medcomm-3-east-2019/

So we’re very confident now that this issue is the result of a complication related to x number of elements being present. After it reaches that threshold, it becomes problematic. And again, it’s not us. These sites have a 256MB memory limit (which is really well beyond what they need) and our dev machines have 16GB of RAM - and are only running Chrome at the time. It’s not a memory thing on our end. We run apps far more complicated than Pro on these and they blaze through them.

[rad]

Hi @co50,

I have only provided input about any possible cause of delays and it could be from multiple different causes, that’s why I said it’s not just about how many cores. And since we’re now comparing the internet and server too, let’s go to the faster one, the intranet, even with 150gb speed, transferring data and files wouldn’t be instant either because there are many contributing factors, I think I have average of 20mbps on my intranet even though it’s stated as 150gb. How much more for internet. That’s why I only said, there is no near-zero response time unless it’s only processing a bit of data for mathematical processing. But please let’s skip that

And yes, it’s running on the browser and through that, there are many limitations as well. Please note that a preview is not just rendered, it’s also processed by the server, a shortcode is a Wordpress function and can only be executed through the server, and we all know that those builder elements are also shortcodes. It’s only rendered when a response from the server is received by the browser through AJAX. It’s already using AJAX and using PHP to generate output :). That’s why I said if you’re doing some changes too fast the preview processing may not able to keep up then there will be delays displaying the preview for specific elements. And a server could also limit of how many connections it could accept before it throttles it, hence if you’re doing editing so fast, then it could be worst and it’s something a javascript or any code can control, nor internet speed.

Builder previews are not just type-in and view, because the entire builder app is not just written in HTML (which browser can render instantly), but also PHP and other stuff. Hence, the delay and waiting for preview. You can confirm that by opening your browser developer tools and made some changes, it will issue an AJAX request to the server and the browser will wait.

And there is no inline editing in the left sidebar, that’s just a standard editor where you add the HTML content (the code), which then you can switch to visual tab for actual rendering of the content manually. Where in inline editing, you’re editing the live content while it generates the preview automatically, then the browser needs to process it back in forth to make sense the HTML code it needs to render as you typed in. And since it’s automatic, the browser has no idea or don’t care if there is some Ajax processing on the background. It will render as it pleases, because it will be annoying if it will stop you from typing in or disable content-editable feature while it waits the last changes you made (waiting for AJAX). So yes, a bit slow for inline edititng

There would be a speed difference between the two. And for that, I recommend not utilizing the inline editing if you prefer the speed of the standard text editor.

Please note that a web application is not the same as a desktop application where codes are compiled. That’s why even a device with so much processing power could still be slower when it comes to the amount of the content you’re adding and it processed. RAM only increases the storage of the data that can be processed, the number of threads or core is another thing, the browser rendering engine is also another thing.

Another example that I could provide is (not related to Pro, just my previous project), I created a content editable app just with raw javascript, and it can switch between edit mode and render mode (similar to inline editing), then I enabled editing mode by double-clicking, then I copied a Word document (a long one) and pasted to editable area, took some time for the browser to accept the input, then I deactivated the edit mode by clicking outside, it’s too took sometime since it’s a large content and the browser has to generate the actual HTML content with styling based on pasted content. Not that too long, but I considered it laggy and I was on 8GB RAM. Now, add more like an AJAX-based processing, it would be slower. I’m not really arguing, it’s just based on my experience and nothing is instant even with high spec device. Even just pasting a long content to notepad isn’t instant. But I’ll continue checking and see what else we can improve, but yes, speed is relatively related to the amount of the content, and the amount of executing codes.

Thanks!

[co50]

Rad,

Appreciate your help on this and thoroughness, but I take a pragmatic approach to what causes this…

1. We know it’s not server speed. It’s not anything related to the server, the Internet, or any 3rd party. And we know this because of several reasons:

a) The issue occurs on pages with lots of elements no matter how slow you enter inline edit mode, and the element you edit makes no difference. Whether it’s one word or a whole paragraph, it breaks either way.

b) No preview rendering is taking place. There is nothing to preview. We’re simply double clicking to enter inline edit mode…not clicking out of it. Once you click out, then the preview is saved. Yes, sometimes this take a few seconds to work - not the issue we are talking about.

c) On sites with less busy pages, on the exact same server with the exact same WP/PHP settings, inline editing works flawless with no delays at any point. None. Zero. If it were a server issue, the same delay would exist regardless of the site.

d) On the exact same busy pages that inline editing is problematic on now, it worked perfectly in the prior version of Pro. Our server hardware and config did not change. Our pages did not change. The only thing that changed is the version of Pro we’re using. So how did the Pro upgrade suddenly introduce all sorts of server slowdowns? Answer: it did not.

e) We just performed our tests again - this time with the network cable disconnected. So there was no network connection at all. We did this to prove what we already knew - that Pro does not need to contact the server to enter inline editing mode. With the network cable disconnected, Pro inline editing exhibited the exact same buggy symptoms as it did with the network cable connected.

2. We know it’s not simply the way Pro works now, because sites with less elements do not exhibit this inline editing problem.

It comes down to Pro 3.x choking on pages that have “too many” elements. Whatever changes were made with 3.x introduced a larger resource footprint that causes the issues explained in this thread. I realize you’re trying to still explain the behavior but with all due respect, Rad, we’re ahead of you. We have the symptoms and cause pretty much locked down. We just need you guys to help fix it.

[rad]

Hi @co50,

1. Yes, it’s not just server speed. What I was saying is, the server could also influence it since the server could throttle the number of connections depending on the amount or limit, and or the consecutive speed of the requests, hence, possible spam. I know, every server could have that feature especially there are UDP and TCP spammers out there, even some router has that. Perhaps the editing speed could trigger it too similar to Visual Composer issue when it renders the builder, it issues too many connections that server temporary throttle it or completely blocks it. I’m not saying that’s the same on your end, I just set a sample that it’s one of many possible reasons why there is no near-zero response time when it comes to browser-server communications.

a) Yes, that was what I’m saying, the speed is related to the amount of content or code it needs to execute. It’s not about the speed you typed it in too, it’s the speed of the entire process or waiting time, like a lifecycle process of inputting-processing-viewing. And even if you edit a single word but there are too many on a single builder preview, it would be slower since that graphical rendering is maintained by the browser itself.

b) Now, with the confusion about the preview. There is a builder preview, and there is a browser render view. The builder preview is also a browser rendering, no doubt about that. But I was referring to browser render view as general while referring to inline editing.

As a sample, when you viewed your live page outside the builder, that’s a rendered view of the HTML code of your site. It shows what you need to see instantly based on HTML code. And you’re editing what’s the browser is already rendering in content-edit mode, which it could be slow once it’s active even if you’re not changing anything. It’s also related to graphics rendering. https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480

In the standard editor, it’s much faster since the default content type is code which doesn’t require immediate rendering and could still wait for ajax request compared to live to edit. I agree, it’s too slow and I don’t use it when there is a long content. Even without using inline editing, the browser will freeze given with how much content in it, completely avoiding it means falling back to the hard coding of HTML.

c) Again, I’m not saying it’s alone is caused by the server:), it’s just one of many possible reasons. Not all servers are the same to assume it couldn’t cause any of that. But based on what I saw and troubleshoot in the forum, the server always has large contributing factors. Even if the server is 64gb with 32 cores but decided to block or throttles any of the requests then server and internet speed are out of the question. The builder even works flawlessly on shared hosting but given it only has minimal content and traffics it allows. I wasn’t disagreeing with you, I was also confirming that the speed is relative to the amount of content it needs to process.

d) So far, I have no issues with that. But with longer content, older Pro or not, it’s same and slower. And a bit buggy since the longer content puts a toll on the browser. But I’m still on it.

e) It doesn’t need the internet to enable inline editing since it’s a browser feature and the builder only uses it and added some control to fully utilize its capability. But again, it has drawbacks as explained in #b which still a bit buggy.

And it only needs internet when it generates a preview after the edits. I’m sorry for the confusion again, I wasn’t actually referring to all of these of what’s really happening on your end. I was only discussing about the speed since we started with specs and such. All of that are only possible causes, and causes could be multiple combinations. But again, inline editing could be buggy and laggy depending on the amount of content and code.

2. It is, that’s what I was referring. The more the slower . Let’s not look far, try editing in visual composer and put content as much as you want. Then reload the builder and it’s going to be too slow and sometimes it freezes the browser. Another one is Wordpress menu, try adding hundreds of menu, and that page as well will be slow and may freeze. That happens regardless of server, specs, internet speed and so on but it doesn’t mean it can’t contribute to the issue.

Let’s just skip all of these explanations for now, I was just really explaining why it could be slower regardless of specs. And you have only proved it multiple times that it’s not really about specs or internet so we’re going on circle

We’ll check it see what else we can improve for inline editing.

Thanks!

[co50]

Thank you. As you must know, advanced devs are all using inline editing. Nobody is taking those extra steps to edit text the way it used to be prior to inline editing being implemented. So I think a more laser-like focus should be made to improving the speed and efficiency of inline editing.

I feel bad that you spent a lot of time going over the server and Internet speed stuff since it’s not related to this issue. I’m aware that other parts and plugins of WP can be problematic, but our systems are powerful enough that this isn’t an issue. We work with menus large enough to require increasing MAX_INPUT_VARS and they still can be manipulated pretty easily. We have a couple of legacy sites still on Salient theme (which uses VC editor) and while it can sometimes take a few seconds to load up, it always works reliably and edits are quick and painless.

Our only issue with any software we use in our development process is Pro. It is VERY bloated. Large sites with lots of elements will often fail to load completely on tablets (even brand new speedy ones), and can take a while on even modern laptops. Our desktops load it no problem but even then, sometimes elements will not show their preview after manipulation (eg. text element just shows hashbox with “T” in the middle), fail to show inline edits just made, and of course the big issue with inline editing double clicks not being grabbed properly. So while our issue is specifically the inline editing, Pro as a whole uses a TON of resources and this leads to memory issues even on well-equipped systems. What I think Themeco needs to understand is that only Themeco can fix this. Nothing we do on our end will fix this problem. Not upgrading our systems, our server, our browser, our Internet speed. Nothing. So we must rely on you to improve it. Please do so. Thank you.

[christian]

Hey @co50,

May we test the pages having this Inline Editing issue? If not, can you export some pages as a template and make it available for us to download?

I tested about 50 headlines and 50 text elements on a page and I couldn’t seem to replicate the issue. In this case, it might be best to test the exact setup rather than us recreating the issue.

Thanks.

[co50]

Christian,

Our pages where this issue occurs have 50+ headlines/text but all sorts of other elements as well. I’m quite sure it’s related to resource usage since it only happens on packed pages. Though it could also related to OS/browser since not many people use Win 7 anymore - but we do.

Secure note attached.

[christian]

Hey @co50,

Thanks for providing access. I have replicated the issue and now even in my test site. I’ll post this in our issue tracker. For now, please avoid moving the mouse until the text edit is complete.

[co50]

I’m glad you were able to replicate it, but I do need to state that this happens even when you don’t move the mouse. In fact, the only way we can inline edit the pages you looked at is to double click, wait 1 second to see if it took or if it lost focus, and then start typing. We are not moving the mouse at all while waiting to see if the double click took or not. So it could be worse of an issue on our browser/OS combo than yours.

Currently, and we’ve tried, we have not found any workaround or timing in which double clicks to go into inline edit work reliably. So we just wait 1 sec after the double click and see what happens. About 75% of the time, it enter inline edit, the other 25% it loses focus and does nothing. Our results are the same regardless of double click speed, mouse movement after the double click, etc.

[christian]

Thanks for the additional input. Are you double-clicking on another text element when the Inline Mode is still active in the other element? I tested your page and that’s the only way I could replicate what you’ve described. See attached.

When the Inline Mode is still active, you’ll need to click outside of the element first to deactivate it then you can proceed to another element.