Streaming live at 10am (PST)

Insane & hair-pulling Designer bug: selecting a div in Navigator resets page layout?!

This is an asinine bug. Just watch this video and do try to avoid the hair-pulling screech that will inevitably come:

Steps to reproduce

  1. Select a div in the Navigator
  2. Part of the page’s layout will reset
  3. Press “Ctrl +S” to fix

What should happen

  1. Select a div
  2. Not a damn thing should change

Reported on Dec 30th, with two earlier videos: Webflow claimed “someone else is probably editing on your account; can’t help more because we’re on holiday”. Impossible, by the way: I am the sole developer.

Followed up January 19th: Webflow didn’t reply. Long holidays, apparently.

Followed up February 10th: Webflow hasn’t replied.

Impossible to continue working. Having used Webflow for well over a year, I can confidently say it has only gotten buggier and buggier. This bug is reproducible on 3+ different systems, all running Google Chrome (latest; as of today, 80.0.3987.87) on Windows 10 Pro x64 1909 (18363).

This is reproducible with zero extensions, on brand-new installs of Google Chrome.

Link: here
Read-only Preview: here


Brandon here with the Webflow Customer Support Team!

I will be happy to help you with your question regarding your issue.

What look is it that you want for your Image? Zoomed in? etc?

Please help me help you.

Best Regards,
~ Brandon

Brandon, thank you for replying, but—with all due respect—please re-read the initial post. I’d like your help to stop Webflow from changing the layout if I select the div in the Navigator. This is a bug, though I appreciate your willingness to help with layout issues.

I’m a little flabbergasted. Can you not view the video I linked above? I’ve linked it again here now:

EDIT: I meant that “view the video” question literally. I’ve checked this page on two machines on private mode & the video is loading. Please let me know if it’s not loading. I can re-upload to YouTube if that will help?


Sorry, I did see the video from you.

Here is what I saw when I imported on my end:

Watch and lmk your design thoughts.

Best Regards,
~ Brandon

That’s OK: thank you for viewing it.

Agreed: clearly, something is wrong, i.e., why it’s bug report. As to why you can’t reproduce it, I can only guess (I’m as bewildered as you are):

  1. Could this be a caching issue? Is there a way to reset the server-side cache of our entire site? Because the issue is “fixed” by repeatedly saving, I’m curious if it’s related to a bad cache.
  2. When you imported it to production, did you import the entire site or just that page? Because this bug is reproducible on other pages on the site, as well (but not all pages).
  3. Console output is below, though mostly identical to yours.

FWIW, the auto max-width was only for testing this bug as I was attempting to rule out variables; that’s not actually used in production.

Even using your suggestion, @WebDev_Brandon, this bug is reproducing in even wilder ways on other systems. An example on a completely different computer, which is not affected by the original reproduction, but a SIMILAR reproduction:

Steps to Reproduce

  1. Change the max-width to 500%
  2. Press enter
  3. Press “CTRL+S”

What happened

  1. The max-width is reset to 100%

What should’ve happened

  1. The max-width stays at 500%

The fourth video I’m sending to Webflow:

I think my hypothesis of a server-side caching issue (or something similar) is now more than likely.

I can only assume your console debug output is not verbose enough. What other troubleshooting information can you look into?

Running a quick and dirty Devtools performance profile shows a resize event is triggered immediately when I hit “CTRL+S”, for whatever reason.

Do I need to wait another 40 days before I get a response here? I sincerely hope it’s not the boilerplate response Webflow has given to the half-dozen active bugs I’ve reported:

Copied from another one of my bug reports: We don’t have any new information at this time, but we wanted to touch base with you once more to let you know we’ve not forgotten about this issue. I don’t yet have a time frame for you as to when a fix will be deployed, but we will follow up in this thread when we have an update.

^^ That won’t be acceptable 40+ days on, as Webflow ignored a half-dozen emails. That was no way to support a product that Webflow asks us to pay $200/year.

TG2, I’m away from my desk the moment. When i get back I’ll look further and escalate to the appropriate teams.


1 Like

Yup…I’ll be here waiting. I’d hoped it had already been escalated by Dave 6+ weeks ago when I first reported it and he also had zero usable explanations, workarounds, nor troubleshooting tips.

Please dovetail your escalation with the original bug report. There are no case numbers or reference numbers, so the emails will have to do:

It’s been well over 40+ days, so I want to ensure everyone has a clearly documented history of how badly this has gone belly-up at Webflow Support.

Hi there!

Thank you for providing a detailed explanation and screen recording. However, I was also not able to replicate this behavior on my end which makes it difficult for us to troubleshoot. This issue could be related to browser cache. Please retry reproducing the same behavior while in incognito mode with all browser extensions disabled.

Another suggestion is to give your image a fixed width in addition to the max-width. You can increment the percentage of the fixed width depending on how zoomed-in you’d like the appearance of the image to be (ie… 300%, 400%, etc).

If you can help us understand the desired result, we can recommend another approach.

Please let me know if you have any other questions, and I’ll be happy to assist further!

All the best,

Wadood, thank you for the reply. Let’s move quickly:

  1. The desired result is Webflow stops changing layout settings when I hit save. That’s it. That’s literally it. If I set it 100%, keep it 100%. If I set it 250%, keep it 250%. Are you unaware why users would want the Layout settings…to actually stick?

  2. It is not a client-side cache issue, as far as the data shows. Please read the original bug report, which re-iterates this. However, because apparently each test must be done twice by me, here you go, again:

Wadood, are there any SERVER-side cache flushing options? This issue transcends browsers, computers, private & non-private windows. Surely…you can see this is a deeper issue.

Please share a shred of evidence showing how this might be a client-side caching issue. I’ll wait. All signs point to a Webflow site or Webflow account issue.

In the meantime, please tell me what other tests I need to reproduce, re-do, and re-evaluate because having done them once was not enough. I’m flabbergasted: does Webflow not realize some bugs only affect some accounts?

I expected something more thorough from Webflow, Wadood. Please do not feel personally maligned: this is a failure of many Webflow staff before you, too. If anyone at Webflow is still confused, please give me a call: I’ll DM you my number. There should be no confusion on what this bug is and what steps Webflow needs to take next.

Hi @TG2,

You were pulling your hair out and so was I, the little I have anyways. So I escalated this on our designer team. I have created another video for you for what I found out and hopefully this explains more and fixes this issue you are having:

When you have a defined width the Save function will not revert the settings. Finished testing after I finished the video.

Please let me know if you have any other questions,

~ Happy Designing ~


Thank you so much for getting back to me, @WebDev_Brandon, and I’m ecstatic it was able to be reproduced.

Oh, yes: for two months, there’s hair everywhere. I expect we’ll both have similar amounts left in a few more months, heh.

re the explanation: Wow, all right. That solves this months-long mystery. Thank you, thank you, thank you for finally getting to the bottom of this. Your QA & Designer geniuses are definitely earning their title.

So, in conclusion, the Webflow in-page preview is a partially-built-iframe. Now, images need to have a defined height/width (not just max-height/max-width). So when first building out the iframe, Webflow tries to understand an image without a set height/width, but it can’t: it gives a bad/partial/incomplete guess. That preview-guess is fixed when the iframe is refreshed by 1) a save command or 2) selecting another div (i.e., creating the blue outline highlight). Once the iframe actually builds out its complete preview, it finally reveals what the live website looks like, i.e. a shrunken image).

I’m thankful this issue was as minor as that, as I was afraid I’d need to start over understanding how images, CSS, and Webflow worked. But, noting the image set height/width, it’s probably needed.

Thank you so much for the workaround. I went and read up a little more on object-fit and I’ve done it like this, on the image, on the desktop & it gracefully cascades on its own to smaller viewports:

height: 100%
width: 100%
object-fit: cover

With this combo, the image doesn’t need different widths/heights on every viewport + won’t be distorted + will always cover any screen size no matter how weird its ratio + maintains image responsiveness (downsizing image resolution on smaller viewports) + the image doesn’t jump as the user shrinks the viewport (e.g., on a desktop) + you can control the “focus point” w/ wonderful recent addition of object-position, too, by Webflow.

See the short clip here, for what the final result looks like:

Thank you very kindly, @WebDev_Brandon for getting to the bottom of a bug that I was afraid was forever stuck in the nobody-knows-and-nobody-can-fix-it abyss. Much appreciate your suggestion, @Wadood_Hussaini, too: you were on the right track about the image width/height, which would’ve corrected the behavior; but, now knowing how Webflow’s in-page preview operates, this should hopefully stave off more confusion and hair-pulling.

1 Like

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