Different window.open in an async call behaviour between Webpack 4 & Webpack 5

[samiashi]

Bug report

What is the current behavior?
Using the same React component we get different experiences when building with Webpack 4 & Webpack 5 on iOS devices

Clicking a button to open a new tab in an async call would only work when building with Webpack 4.
When building with Webpack 5 the new tab does not open when you click the button. The popup gets blocked.

Note: Clicking the button on Chrome/Firefox desktop works as expected (opens new tab) on both Webpack 4 & Webpack 5.

I understand that the code that triggers the new tab might not be the best but I'm really curious to understand why this works with Webpack 4 and doesn't with Webpack 5. And how come it only seems to affect Apple devices 🤔

If the current behavior is a bug, please provide the steps to reproduce.

I've created a repo to reproduce the issue https://github.com/samiashi/react-webpack-debug
Instructions are included there as well to reproduce the issue

1. Install the desired Webpack version (4.47.0 or 5.90.0)
2. Run npm run start
3. Using Xcode Simulator, open an iPhone (I've been testing with iPhone 15 running iOS 17.0) or open on real iPhone device or using Safari on Desktop
4. Navigate to http://localhost:8080
5. Click on the button

What is the expected behavior?
Clicking a button to open a new tab inside an async call should work when building with Webpack 4 & Webpack 5 on iOS.

Running with Webpack 4

webpack4.mov

Running with Webpack 5

webpack5.mov

Other relevant information:
webpack version: 5.90.0
Node.js version: v18.18.2
Operating System: iOS
Additional tools:

[alexander-akait]

Please open the safari dev tools console and look at the output

[samiashi]

@alexander-akait Sadly nothing pops out in the dev console

Attached is a video of running it under Webpack 5
https://github.com/webpack/webpack/assets/10187761/68303b9f-d0ab-4cf9-a740-7ecf1e7d271e

[alexander-akait]

I am sure there are no problems with webpack, we don't override your code and don't change logic, maybe something with dev env, I will investigate it later

[samiashi]

Many thanks @alexander-akait
I’m very keen to hear about your findings

just to note that I get the same issue when I build for production on version 5

[alexander-akait]

Sorry, I can't reproduce it, tested on iPhone 14, iOS 17.3, please check your environment, try to debug JS code using debugger/dev tools console/console.log/any other methods, try to disable minimizer and check it (maybe you have old terser version with bugs). We really don't touch your code here, you can open bundle.js file and see it

If we had the such problem you will see a lot of issues here...

[alexander-akait]

Anyway feel free to feedback and feel free provide any information, I moved it to dicussions because it doesn't reproducible

[samiashi]

I did some more digging and I think I understand the difference now.

Webpack itself is not rewriting my application code, but webpack 4 and webpack 5 produce a different browser runtime environment.

In webpack 4, the bundle includes the old automatic Node/browser polyfills, including timers-browserify / setimmediate. Because of that, React’s scheduler sees setImmediate and uses that scheduling path.

In webpack 5, those automatic Node polyfills were removed, so React’s scheduler no longer sees setImmediate and falls back to MessageChannel.

That matters specifically in Safari/WebKit because popup/user-activation behavior differs depending on which async mechanism is used. WebKit has an open issue where user gesture context is propagated through window.postMessage, but not through MessageChannel: https://bugs.webkit.org/show_bug.cgi?id=186593

So the likely chain is:

• webpack 4 -> setImmediate polyfill -> internally uses window.postMessage -> Safari preserves enough user activation -> window.open() works
• webpack 5 -> no setImmediate polyfill -> React scheduler uses MessageChannel -> Safari loses user activation -> popup is blocked

This also explains why it only shows up on Safari/iOS and why Chrome/Firefox desktop behave differently.

So I agree this is probably not a webpack code transformation bug. It looks like a migration side effect from webpack 5 removing automatic Node polyfills, combined with WebKit’s user-activation behavior around MessageChannel.

Relevant webpack change: https://webpack.js.org/blog/2020-10-10-webpack-5-release/#automatic-nodejs-polyfills-removed