Webpack-dev-server version 4.12.0 causing compile errors in application

[AlmaFenetre]

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?

• Run an application that uses webpack-dev-server version 4.12.0
• Open developer tools in the browser

[gustavo-salazar]

Same here

[AugustoPreis]

Try this:

[alexander-akait]

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

[AlmaFenetre]

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.

[malcolm-kee]

@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?

[malcolm-kee]

@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]

@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

[nstepien]

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.

[alexander-akait]

@malcolm-kee Can you check it, maybe we don't respect it? But we have tests...

[AlmaFenetre]

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.

[aeggum]

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.

[crobinson42]

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

[crobinson42]

The temporary work-around for frustrated developers is to rollback to v4.11.1 or manually comment this line out in node_modules/webpack-dev-server:

[alexander-akait]

Overlay will be fixed soon, with ResizeObserver I don't undestand, somebody can provide an example of this?

[crobinson42]

@alexander-akait ResizeObserver is a motherfucker in browsers, we can blame the chromium team for the annoying error related to missing frames in the browser 😂.

[alexander-akait]

Oh, I see, we can provide an option to disable this behaviour, I thought it will be better experience, but looks like not for all

[crobinson42]

@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')

[alexander-akait]

Ideally:

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

[alexander-akait]

Becaise errors and runtimeErrors are different things, mostly you should not ignore error because they are from compilation, but you can ignore runtimeErrors, for example you can implement only a part of application and another part can be buggy

[alexander-akait]

I think we will close such problem today (I need some rest after 12 hours of work), so workaround - keep 4.11.1 temporary

[RichieChoo]

lock version 4.11.1

[alexander-akait]

Link on improvements #4777 for overlay
Fixes #4773 for this problem

Please open an issue if you faced with problems in your versions, let's don't mix them in one issue and please follow the issue template, thank you

[alexander-akait]

https://github.com/webpack/webpack-dev-server/releases/tag/v4.13.0

[korgon]

Thanks for your work on this - looking forward to patch release to address this issue. 🙇🏻

[malcolm-kee]

@korgon you should be able to turn off the error by adding client.overlay.runtimeErrors: true to your webpack config. What's pending is just more granular control to filter specific error.

[redbugz]

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.

[alexander-akait]

/cc @malcolm-kee Can we rename our title for runtime errors?

[malcolm-kee]

To close the loop, this is documented https://webpack.js.org/configuration/dev-server/#overlay

[an-parubets]

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