search

vercel / next.js

The React Framework
https://nextjs.org
MIT License
125.24k stars 26.77k forks source link

IE11, development, HMR: Object doesn't support property or method 'attachShadow'. #13231

Closed aorsten closed 1 year ago

aorsten commented 4 years ago

Bug report

Describe the bug

Basically the nextjs page bugs in IE11 development with the following message.

Object doesn't support property or method 'attachShadow'

It seems related to development hot module reloading. Somehow the /_next/webpack-hmr route is caught by express. I have by the way seen similar bugs when using custom routes in pure nextjs pages previously. Unsure if this is related.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

  1. Install the custom-server-express example.
  2. Add this snippet in server.js: 
    server.get('/:one/:two', (req, res) => {
console.log("Parameters", req.params)
return res.redirect('/a')
})
  3. Open localhost:3000 in Internet Explorer 11.
  4. The page flashes the actual content before going white.
  5. Open the console (F12) and the attachShadow message flashes indefinitely.
  6. In the command window, read the message Parameters { one: '_next', two: 'webpack-hmr' }

Expected behavior

I expected to see my content. I would have also expected that attachShadow was either added as a built-in polyfill in nextjs, or that the function was avoided. I believe it can be traced to this location: @next\react-dev-overlay\lib\internal\components\ShadowPortal.js. In other locations in the next package you have an if-test to avoid this - it seems to me.

Screenshots

image

System information

Additional context

I came across this while updating a production package. I wanted to debug the polyfills and find out whether I still need to add polyfills for IE11 after next 9.3. This was a major roadblock.

The real problem here is probably using attachShadow in IE11.

I will try to recreate it without an express server...

aorsten commented 4 years ago

Small update - I couldn't immediately recreate the error without an express server, but I didn't pour my soul into it. Would it be an easy fix to add an if-test for attachShadow in the specific place I pointed to?

kate-hall commented 4 years ago

I'm having the same error, also using an express server.

revolunet commented 4 years ago

same error error here with next@9.4 on IE11 in dev mode. this make IE11 debugging impossible in dev mode

tomdohnal commented 4 years ago

I think this could be solved by using webcomponents polyfill (https://github.com/webcomponents/polyfills) in the packages/react-dev-overlay/lib/internal/components/ShadowPortal.tsx file.

I could try to make a PR if you'd be interested

amigolargo commented 4 years ago

We fixed this in our application using the @webcomponents/shadydom polyfill, +1 to @tomdohnal

myarete commented 4 years ago

@tomdohnal That did it for me, thank you.

@amigolargo - Could you post where exactly you decided to put the polyfill in your app? The issue for us is coming from <Head /> imported from next/document, and if we omit the <Head /> from _document.js, everything breaks from an error unrelated to this one. Obviously we'd still like to use _document.js

amigolargo commented 4 years ago

@altruisticsoftware in src/polyfills.js, import '@webcomponents/shadydom';

It is configured in next.config.js within the webpack config like so:

const originalEntry = config.entry;
    config.entry = async () => {
      const entries = await originalEntry();

      if (
        entries['main.js'] &&
        !entries['main.js'].includes('./src/polyfills.js')
      ) {
        entries['main.js'].unshift('./src/polyfills.js');
      }

      return entries;
    };
Timer commented 4 years ago

Would someone be willing to setup an IE 11 development test suite for us?

It'd be great to fix this and prevent future regressions with CI.

revolunet commented 4 years ago

do you have a browserstack.com account or another solution to run IE11 tests ?

Timer commented 4 years ago

Yes! See how we test Safari 10 using browserstack: https://github.com/vercel/next.js/blob/b1025995b2645666847d72fb85e65b59b375724f/.github/workflows/build_test_deploy.yml#L115-L133

bolatovumar commented 4 years ago

I believe this has been resolved in https://github.com/vercel/next.js/pull/13704? That PR does fix this issue for me.

mliq commented 4 years ago

I am still getting this error on next 9.5.3 - is there anything else I need to do to fix it? Production mode works. This is my .browserlistrc in root:

# Supported browser list.
# See https://github.com/browserslist/browserslist for more details.

last 2 chrome versions
last 2 ChromeAndroid versions
last 2 edge versions
last 2 firefox versions
last 2 ios_saf versions
last 2 safari versions
ie 11
node 12
Unsfer commented 4 years ago

I'm getting this error too on old Firefox, using next 9.5.3

TypeError: portalNode.current.attachShadow is not a function

    Portal/< webpack-internal:///./node_modules/@next/react-dev-overlay/lib/internal/components/ShadowPortal.js:37:30

The above error occurred in the <Portal> component:
    in Portal (created by ReactDevOverlay)
riazXrazor commented 4 years ago

thanks @amigolargo and @tomdohnal ur solution worked

haydnhkim commented 4 years ago

dev-build-watcher.js are checking for attachShadow. https://github.com/vercel/next.js/blob/8426f13713c6a1ac498562479d864633cf355c6d/packages/next/client/dev/dev-build-watcher.js#L18-L26

If you add @webcomponents/shadydom polyfill, it does not add a value to prefix, so the css name is applied globally. The website I am maintaining has a problem because it is using #container as its main content wrapper. #container is a universal class naming, so it could be a problem for others. (Problem only occurs with old browsers in the development mode) https://github.com/vercel/next.js/blob/8426f13713c6a1ac498562479d864633cf355c6d/packages/next/client/dev/dev-build-watcher.js#L124-L129

jtakahashi0604 commented 3 years ago

Thank you @amigolargo and @tomdohnal.

I just fixed this problem with your solution in Next.js 9.5.5.

package.json

"@webcomponents/shadydom": "^1.7.4"

next.config.js

module.exports = {
  webpack: function (config) {
    const originalEntry = config.entry;

    config.entry = async () => {
      const entries = await originalEntry();

      if (
        entries["main.js"] &&
        !entries["main.js"].includes("./src/polyfills.js")
      ) {
        entries["main.js"].unshift("./src/polyfills.js");
      }
      return entries;
    };

    return config;
  },
};

./src/polyfills.js

import "@webcomponents/shadydom";
mliq commented 3 years ago

^ Above code fixes for me too, I recommend this further optimization to keep that dependency out of prod:

./src/polyfills.js:

if (process.env.NODE_ENV === 'development') {
    require('@webcomponents/shadydom');
}
oliviertassinari commented 3 years ago

I have found a similar issue. In my case, the dev mode with IE11 is failing on the arrow function of https://github.com/vercel/next.js/blob/197d46ddb9bebc4a74360e66f50b091edd811ae0/packages/next/client/next-dev.js#L35

https://github.com/mui-org/material-ui/issues/24316

ntsim commented 3 years ago

The overlay styling is also really janky as well (this is with a barebones repo setup with create-next-app):

image

kevinolivar commented 3 years ago

Hi there,

getting also the same as @ntsim using nx

Environment:

"@nrwl/cli": "12.3.6",
"@nrwl/cypress": "12.3.6",
"@nrwl/eslint-plugin-nx": "12.3.6",
"@nrwl/express": "12.3.6",
"@nrwl/jest": "12.3.6",
"@nrwl/linter": "12.3.6",
"@nrwl/next": "12.3.6",
"@nrwl/node": "12.3.6",
"@nrwl/react": "12.3.6",
"@nrwl/storybook": "12.3.6",
"@nrwl/tao": "12.3.6",
"@nrwl/web": "12.3.6",
"@nrwl/workspace": "12.3.6",

.browserslistrc

last 2 versions
> .25%
not dead
ie >= 11
not op_mini all
github-actions[bot] commented 1 year ago

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the :+1: reaction on the topmost comment (please do not comment "I have the same issue" without repro steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

balazsorban44 commented 1 year ago

This is unlikely to get fixed, as Next.js 13 does not support IE11 by default anymore, although the target can still be configured to IE11. See https://nextjs.org/docs/basic-features/supported-browsers-features#browserslist, https://github.com/vercel/next.js/discussions/33227

Modern browsers are much more suited for development and should be the path forward.

github-actions[bot] commented 1 year ago

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.