By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Bug report

Webpack-dev-server version 4.12.0 causes compile errors in application on browser viewport resize

Actual Behavior

We run an application which uses webpack-dev-server 4.12.0 as a dependency. With this version of webpack-dev-server, whenever we resize the browser viewport in our application (e.g. by opening developer tools), an error overlay pops up stating "ResizeObserver loop limit exceeded". This behaviour does not occur in the exact same version of the application that uses webpack-dev-server version 4.11.1 .

Expected Behavior

The error should not appear when resizing the browser viewport in any way.

How Do We Reproduce?

How Do We Reproduce?
Run an application that uses webpack-dev-server version 4.12.0
Open developer tools in the browser

Sorry I can't please provide normal reproducible test repo, we don't have ResizeObserver at all in our code, so I think you have a non official plugin and something that patch our dev server runtime, without good example and configurations I can't help you, please in future avoid using screenshots for such errors, because rewritting them takes a lot of time

There is a PR for our new overlay and it was improved and redesign 87a26cf and you will not find there something criminal

Please avoid any spam, if you need help, provide a reproducible test repo as we ask and I will help you

please in future avoid using screenshots for such errors, because rewritting them takes a lot of time

The error text is literally in the bug description.

"devDependencies": { "@typescript-eslint/eslint-plugin": "^5.40.1", "@typescript-eslint/parser": "^5.40.1", "@vue/cli-plugin-babel": "^5.0.8", "@vue/cli-plugin-eslint": "^5.0.8", "@vue/cli-plugin-typescript": "^5.0.8", "@vue/cli-service": "^5.0.8", "@vue/eslint-config-typescript": "^9.1.0", "babel-eslint": "^10.1.0", "copy-webpack-plugin": "^11.0.0", "cross-env": "^5.2.0", "eslint": "^7.32.0", "eslint-plugin-vue": "^8.0.3", "sass": "1.43.4", "sass-loader": "10.2.0", "typescript": "4.2.4", "vue-reactive-provide": "^0.3.0", "vue-template-compiler": "2.6.14" },

our dev dependencies

the error this morning:
ERROR
ResizeObserver loop completed with undelivered notifications.
./node_modules/webpack-dev-server/client/overlay.js/createOverlay/<@ https://localhost:50009/js/chunk-vendors.js:469001:56
EventListener.handleEvent*listenToRuntimeError@ https://localhost:50009/js/chunk-vendors.js:469128:10
createOverlay@ https://localhost:50009/js/chunk-vendors.js:468994:82
./node_modules/webpack-dev-server/client/index.js?protocol=wss&hostname=localhost&port=50009&pathname=%2Fws&logging=none&progress=true&overlay=%7B%22errors%22%3Afalse%2C%22warnings%22%3Afalse%7D&reconnect=10&hot=true&live-reload=true@ https://localhost:50009/js/chunk-vendors.js:467834:73
webpack_require @ https://localhost:50009/js/app.js:5349:33
@ https://localhost:50009/js/app.js:6569:83
webpack_require .O@ https://localhost:50009/js/app.js:5398:23
@ https://localhost:50009/js/app.js:6572:53
@ https://localhost:50009/js/app.js:6574:12

As for a test repo, it is like I said, install webpack-dev-server 4.12.0 in an application and then open and close the developer tools a few times in a browser of your choice (I've seen it happen in Chrome, Edge and Firefox). Hard installing webpack-dev-server version 4.11.1 into our devdependencies resolves the error, so that is the minimal working example of that it must be caused by the new webpack-dev-server version.

If this is not enough, please be more clear in what you need from me to be able to look into this issue.

@alexander-akait I think it may be caused by the runtime error catching behavior. I'll see if I can add new config options to opt-out this behavior next week.

Does that sounds like good idea to you?

@AlmaFenetre thanks for raising the issue, I'm sorry that you have some issue with the latest release.

Regarding reproduction, knowing 4.12.0 cause error in your setup does tell us that some change in 4.12.0 cause the error, but it doesn't tell us "in what scenario it has issue", which is important to create a proper fix.

A popular project like webpack-dev-server can be used in so many ways, having a minimal reproduction example allows us to understand what's happening. Thank you.

@alexander-akait I think it may be caused by the runtime error catching behavior. I'll see if I can add new config options to opt-out this behavior next week.

Does that sounds like good idea to you?

Can you clarify, I think they have custom scripts for our runtime and because our HTML was changed they have a problems now, usually I closed such issues, because no one provide how we can reproducible it and we don't have ResizeObserver , and yes, if it was a bug regression we will have here a lot of issues and 👍

I will keep open some times, if noone give normal reproducible example I will close, unfortunately we are not magicians

I'm seeing this as well.
What's really frustrating is that I have client: { overlay: false } set up so WDS won't show up any overlay, yet is still does, why?
We use WDS to run custom visual regression tests in CI, and WDS now breaks them by displaying an overlay we didn't opt in to, and swallows the errors.

https://stackoverflow.com/questions/49384120/resizeobserver-loop-limit-exceeded

From this link:
"This error means that ResizeObserver was not able to deliver all observations within a single animation frame. It is benign (your site will not break)."

So what I think is happening is that all errors (including benign ones that are ignored by the application, as they do not show up in the developer console in my instance) are nevertheless bubbled up to webpack-dev-server's error overlay.

I'm also seeing this.

In my case I have multiple apps, but I only get the immediate overlay with errors when resizing in one of my apps. In each of them, any logged JS error leads to the overlay. This is despite having client: { overlay: false } in my webpack config, as @nstepien mentioned. I have not tried the CLI argument --no-client-overlay .

This happens on 4.12.0 but if I use 4.11.1 hiding the overlay works as expected.

I am experiencing this issue as well. client: { overlay: false } & --no-client-overlay are not respected.

Inspecting the code, these options are never passed to createOverlay() . Here is the PR to get merged and published ASAP: #4773

@alexander-akait a really "nice to have" feature would be an option to filter errors/warnings ie:

client: {
 errors?: boolean | (error: Error) => boolean
 warnings?: boolean | (warn: unknown) => boolean
Where we could use it like:
client.errors = (error) => !error.message.includes('ResizeObserver')
client: {
 errors?: boolean | (error: Error) => boolean
 warnings?: boolean | (warn: unknown) => boolean
 runtimeErrors?: boolean | (error: Error) => boolean
But let's implement boolean firstly, so you can disable it if you need, and then we can look at serilization
          
This bit us as well, hampering local development. Another very confusing aspect is this is listed as a compilation error when it's not. We were aware of the ResizeObserver issue in other contexts and had measures to deal with it, however, suddenly it started showing up as a compilation error in webpack, which made no sense as it doesn't show up in the build console during compilation, and we were stumped as to why what is normally a runtime error had suddenly morphed into a compilation error.

If you are going to show runtime errors now as well, please don't label them as compilation errors, label them properly as runtime errors.
I'm seeing this as well. What's really frustrating is that I have client: { overlay: false } set up so WDS won't show up any overlay, yet is still does, why? We use WDS to run custom visual regression tests in CI, and WDS now breaks them by displaying an overlay we didn't opt in to, and swallows the errors.
Thank you! This solved my problem