This is an asinine bug. Just watch this video and do try to avoid the hair-pulling screech that will inevitably come: https://streamable.com/ir3qq
Steps to reproduce
Select a div in the Navigator
Part of the page’s layout will reset
Press “Ctrl +S” to fix
What should happen
Select a div
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.
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?
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
Change the max-width to 500%
The max-width is reset to 100%
What should’ve happened
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.
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).
Wadood, thank you for the reply. Let’s move quickly:
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?
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.
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: https://share.getcloudapp.com/5zuygqzj
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,
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:
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.