Hi René, is it happening every time you refresh the page? I could probably round it to the pixel safely but it’s measuring that width, which should never really be changing unless you add a new line.
Is a custom font being applied to it maybe? Or any idea why the width is changing? I’ll try to reproduce it as well.
Is this a dynamic value calculated by values depending on the client system, like screen size, browser size, etc., and is there a workaround?
When I save an article, that change is not applied.
No, it shouldn’t differ in these cases.
Hey @kbat82
Thanks for your quick reply.
> is it happening every time you refresh the page?
It happens only when someone changes a code block and then saves it. It does not happen on page refresh. We need to actually change something, and it will modify all code blocks, even those that an author did not update.
I did a few more tests:
– It happens only when my colleague changes and updates anything in a post on his machine (In regular and incognito mode/chrome); it does not need to be a modification in a code block.
– It does not happen when I use his WP account on my machine, so it seems coupled to a client. That’s why I assumed in my first email that something client-specific was added to a code block while saving.
It’s very strange; no matter what I do, I cannot reproduce it even by using my colleague’s wordpress account on my machine, but once he uses one of his machines, we get differences in each code block.
We use the same browser and version, and the error pops up even with the same screen resolution.
This seems to be one of the issues that can not be solved:-)
After these tests, it does not feel like an issue in the code block plugin, and I will close it.
Thanks again, Kevin.
That’s very odd! I wonder if it’s a browser extension (that is enabled on incognito), or maybe something on their OS that is manipulating the page. I guess they could try another browser, or their friend’s machine and rule that out too.
I know the editor itself (and React too) has some issues with the Google translate extension and others that do dom manipulations (like grammarly), but to me it sounds like something font related.
If it comes up and they want to try to debug some more or if any other clues come up, I’d be happy to try and think of some things to try. Just reply here or email me.
Got the culprit:-)
Your tip with the font size gave me the idea for a new test!
You can reproduce it even with the same user:
– Set your operating systems display font size to 150%. (For instance, I use 150% on a 4K screen on Win OS to make text better readable for my old eyes)
– Create a post. Add two or more code blocks to it with some content. Save it.
– Reduce the operating systems display font size to 100%. (This will simulate a different client with different OS/font size)
– Refresh the article and make a tiny change in one code block like a blank comment //
– Now, use revisions to compare the updated article with the previous one, and you will notice that all code blocks now will have a modified lineNumbersWidth value
I am unsure if this is even something “fixable”.
I guess for the majority, this is no problem and only for users who actually rely on comparing revisions.
How important is lineNumbersWidth, do we actually need it?
Nice detective work! The width is needed because I wanted to use a css counter for the line numbers to avoid persisting the line number markup in the database. The limitation is that browser support for courter pad characters is limited to numbers and some other symbols, but not explicitly a blank/empty space. It might work, but it’s not in the spec (assuming I’m interpreting it all correctly). The width allows for the numbers to be properly right-aligned.
I may be able to do the math a bit better though. I’ll look into it this weekend and follow up after that.
Fingers crossed. I’ve starred your project on github. You can ping me there if you want me to test something (Use @rene-hermenau)
