Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

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

Already on GitHub? Sign in to your account

Potential crash in removeStyleElement when sourcemaps are enabled #179

Closed
Jessidhia opened this issue Feb 28, 2017 · 6 comments
Closed

Potential crash in removeStyleElement when sourcemaps are enabled #179

Jessidhia opened this issue Feb 28, 2017 · 6 comments
Assignees

Comments

@Jessidhia
Copy link

Jessidhia commented Feb 28, 2017

Do you want to request a feature or report a bug?
Bug report

What is the current behavior?

TypeError: cannot read property 'removeChild' of null in the line styleElement.parentNode.removeChild(styleElement);. The styleElement exists, but its blob URL is not registered, and the parentNode is null.

Looking a few stack traces up, in the addStylesToDom call, the bad function call is the line domStyle.parts[j](item.parts[j]);. However, while domStyle.parts.length === 2, item.parts.length === 1; this seems to lead to the <link> element being created when j is 0, and immediately destroyed when j is 1 before it gets passed to the addStyle call that would attach to the DOM.

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

I am not entirely sure on the steps needed yet, but it might be related the file being processed (item.id) being empty after going through loaders (nothing but stylus variable declarations). Alternatively, it is not going through loaders correctly due to css-loader's importLoaders hack.

What is the expected behavior?

No crash.

Please mention other relevant information such as your webpack version, Node.js version and Operating System.

[email protected], [email protected], [email protected].

@PanJ
Copy link

PanJ commented Mar 8, 2017

Happened to me and then I tracked down and found this issue. Being recently discovered, could this be a bad combination of webpack & webpack loader versions? Tried to downgrade but still no luck.

@michael-ciniawsky
Copy link
Member

@Kovensky 👋 Do maybe have a fix in mind ? 😛 See also #182

@Jessidhia
Copy link
Author

Nope, I still have no idea how this happens 😆

I just tried to debug the current state as of the crash, but I don't know what leads to the bad state. I ended up making a hack loader to delete the specific @import that pointed to the (ultimately) empty file before css-loader saw it 😕

@michael-ciniawsky
Copy link
Member

Could you link me to the code? But I have the slight feeling it will be complicated 🤣

@alexander-akait
Copy link
Member

alexander-akait commented Apr 19, 2017

@Kovensky can you create minimal test repo? It is speed up the solution of the problem 😄

@michael-ciniawsky
Copy link
Member

If this is still relevant reopen anytime with a reproducible test repo (as simple as possible) :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants