HeadManager removes elements added by non-next scripts
See original GitHub issueBug report
Describe the bug
After upgrading from Next 8 to Next 9, charts embedded from https://infogram.com/ stopped working for us.
My investigation shows that Infogram’s loader adds a <script> element to <head> which is then removed by next’s HeadManager. This causes the Infogram script to fail.
Infogram’s embedding scripts expects the ability to:
- Add a new
<script ... />right before the currently first<script .../>in the DOM. - Find this element (by id) at any point later.
To Reproduce
- Clone https://github.com/jarib/next-js-9-embed-bug
- Run
npm install && npm run dev - Visit http://localhost:3000 for a minimal example, check the console.
- Visit http://localhost:3000/infogram for a full example (using Infogram), check the console.
Expected behavior
The console should show “all ok” for step 3 and render an Infogram chart for step 4.
Instead, the added script element is removed. The script being loaded assumes that the script element that loaded it exists in the DOM, and when it cannot find it, it fails.
You can get the expected behaviour by removing the initial script element from <Head> in both examples, or by downgrading to Next 8 (and moving public/ to static/).
System information
- OS: macOs
- Browser (if applies): Chrome
- Version of Next.js: 9.5.2, 10.0.2, 10.0.4-canary.8, 10.0.5 and 10.0.6-canary.9
- The bug does not reproduce on Next.js 9.5.4, 9.5.5, 10.0.0, 10.0.1
Additional context
Since the embed codes unfortunately are saved as HTML in our CMS, we use createContextualFragment to load it, including the script tag. This has served us well so far, including for client-side navigation, and covers our embed use cases outside of Infogram as well. It also worked perfectly in Next 8.
Possibly related to https://github.com/zeit/next.js/issues/9573
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:6 (2 by maintainers)

Top Related StackOverflow Question
Bug does not reproduce on 9.5.4, 9.5.5, 10.0.0, 10.0.1 Bug does reproduce on 9.5.2, 10.0.2, 10.0.4-canary.8
@Timer That issue is closed as fixed, but my reprodcution repo still fails using 10.0.4-canary.8.