Marko: Uncaught TypeError: Cannot read property 'nextSibling' of null

Created on 3 Nov 2017 · 17Comments · Source: marko-js/marko

Bug Report

Marko Version: 4.5.6

Details

See an exception in the log. Also seeing occasional modelling errors -- such as some items in an each rendering twice. I'm guessing they're related. This happens when updates occur.

Expected Behavior

No error in log and items appear only once even when re-rendering

Actual Behavior

Items appear twice when updates trigger re-render

Possible Fix

It may be a concurrency issue, as I'm using Marko to build a Chrome extension, and events can actually come in between any async processing.

Additional Info

Your Environment

Environment name and version (e.g. Chrome 39, node.js 5.4):
Operating System and version (desktop or mobile):
Link to your project:
Google Chrome Version 62.0.3202.75 (Official Build) (64-bit)
Mac OSX High Sierra

Steps to Reproduce

Not sure how to reproduce it without using my project. I can send a link to it privately if needed.

Stack Trace

view.js:4036 Uncaught TypeError: Cannot read property 'nextSibling' of null
    at Component.___forEachNode (view.js:4036)
    at Component.___detach (view.js:4027)
    at morphChildren (view.js:3236)
    at morphComponent (view.js:3118)
    at morphChildren (view.js:3242)
    at morphEl (view.js:3502)
    at morphChildren (view.js:3275)
    at morphEl (view.js:3502)
    at morphChildren (view.js:3275)
    at morphEl (view.js:3502)
___forEachNode @ view.js:4036
___detach @ view.js:4027
morphChildren @ view.js:3236
morphComponent @ view.js:3118
morphChildren @ view.js:3242
morphEl @ view.js:3502
morphChildren @ view.js:3275
morphEl @ view.js:3502
morphChildren @ view.js:3275
morphEl @ view.js:3502
morphChildren @ view.js:3275
morphComponent @ view.js:3118
morphChildren @ view.js:3242
morphdom @ view.js:3511
(anonymous) @ view.js:4011
batchUpdate @ view.js:2864
___rerender @ view.js:3994
update @ view.js:3949
updateComponents @ view.js:2845
updateUnbatchedComponents @ view.js:2817
(anonymous) @ view.js:2785
postMessage (async)
setImmediate @ view.js:2792
scheduleUpdates @ view.js:2836
queueComponentUpdate @ view.js:2902
___queueUpdate @ view.js:3926
___set @ view.js:2409
set @ view.js:2343
mouseOver @ view.js:23290
invokeComponentEventHandler @ view.js:4302
(anonymous) @ view.js:4319

bug

Source

bohdyone

👍2

Most helpful comment

@bohdyone @hedav85 We've confirmed that this is a bug and are investigating the root cause. Thanks for the report.

austinkelleher on 7 Nov 2017

👍3

All 17 comments

Hi,
could this be related to https://github.com/marko-js/marko/pull/895 ?

I also run in errors like currentNode is null or endNode is null if I rerender components which where included via <inlcude>-Tag.

hedav85 on 6 Nov 2017

@hedav85 Looks like yes! The error I'm seeing seems to be fixed if I apply the change in the PR. Thanks for the tip. Will leave this open till the PR gets merged properly.

bohdyone on 7 Nov 2017

Actually, spoke too soon. Looks like the error above still occurs.

bohdyone on 7 Nov 2017

@bohdyone @hedav85 We've confirmed that this is a bug and are investigating the root cause. Thanks for the report.

austinkelleher on 7 Nov 2017

👍3

@austinkelleher
So I've updated to 4.6, and still getting exceptions:

view.js:3672 Uncaught TypeError: Cannot read property 'insertBefore' of null
    at insertBefore (view.js:3672)
    at morphComponent (view.js:3769)
    at morphChildren (view.js:3894)
    at morphdom (view.js:4163)
    at view.js:4665
    at Object.batchUpdate [as ___batchUpdate] (view.js:3509)
    at Component.___rerender (view.js:4648)
    at Component.update (view.js:4603)
    at updateComponents (view.js:3490)
    at updateUnbatchedComponents (view.js:3462)

bohdyone on 24 Nov 2017

I've also updated to 4.6 and get the following error if I switch the last dynamic include from the iteration.

The example is available at https://github.com/hedav85/marko-test

<p for(module in data.modules)>
  <button on-click('toggleModule', module.name)>Switch</button>
  <if(component.isActive(module.name))>
    <include('../module', {name: module.name})/>
  </if>
</p>

```
Uncaught TypeError: Cannot read property 'removeChild' of null
at index-2fdefdef.js:539
at Array.forEach ()
at morphdom (index-2fdefdef.js:526)
at Component-cf3a6128.js:477
at Object.batchUpdate [as ___batchUpdate] (update-manager-640cef8a.js:63)
at Component.___rerender (Component-cf3a6128.js:460)
at Component.update (Component-cf3a6128.js:415)
at updateComponents (update-manager-640cef8a.js:44)
at updateUnbatchedComponents (update-manager-640cef8a.js:16)
at nextTick-browser-35b093ea.js:16

If I surround the include with a div it works well.
```html
<p for(module in data.modules)>
  <button on-click('toggleModule', module.name)>Switch</button>
  <if(component.isActive(module.name))>
    <div>
      <include('../module', {name: module.name})/>
    </div>
  </if>
</p>

hedav85 on 24 Nov 2017

Same problem from version 4.5.0 or higher. Until version 4.4.28 this problem did not exist.

jesse1983 on 10 Dec 2017

This issue is really blocking my project at the moment. Is there anything I can do to help it along?

bohdyone on 11 Dec 2017

@bohdyone one thing that would be helpful is if you could add a failing test case. You can take a look at similar tests in /test/components-pages/fixtures if you’d like to give this a go.

I hope we can try to get this issue resolved this week.

DylanPiercey on 11 Dec 2017

@marko-js/core I have already checked in a failing test on a separate branch (`issue-920-domdiff-ssr): https://github.com/marko-js/marko/tree/bc745f11a75ac1398bf3e0180fb3af90373eb008/test/autotests/components-pages/nesting

@DylanPiercey this is related to the fix we started on a month back. The problem occurs when we hydrate in the browser from a server-rendered page and the hydration incorrectly binds multiple UI components to the same DOM nodes. WIP fix: https://github.com/marko-js/marko/blob/82a7d9e7dc05d8e31894da44beea778132c44b0f/src/components/pairComponentNodes.js

patrick-steele-idem on 11 Dec 2017

@patrick-steele-idem that test case was actually copied in here and is currently passing. I decided to patch the issue instead of applying your WIP fix (it was stuck in an infinite loop and I was having a hard time diagnosing the issue).

Let me know if you have any feedback on those changes though.

DylanPiercey on 11 Dec 2017

@hedav85 could you confirm if 4.7.1 has resolved your issue?

DylanPiercey on 11 Dec 2017

@DylanPiercey I'll make a test today and give you some feedback.

hedav85 on 12 Dec 2017

@DylanPiercey I testet the version 4.7 + 4.7.1 with my test example (https://github.com/hedav85/marko-test) and the bug is gone. It's now working. Thanks a lot!

But it seems that I run into another issue with my current project (#946).

hedav85 on 12 Dec 2017

👎1

@hedav85 thanks for your patience with all this and your help in getting it resolved. I believe your other issue (#946) should also be resolved now.

Please feel free to comment back if that's not the case!

DylanPiercey on 21 Dec 2017

@DylanPiercey Hi Dylan,

@hedav85's issue may be fixed, but mine is not, as per my last comment. Can you reopen the issue please?

I've also been time poor in terms of creating a new test case for this, but I might have some time over the next few days. It's not yet clear how to reproduce it outside of my project however.

Just checking that the stacktrace I posted not sufficient to track down the problem?

bohdyone on 23 Dec 2017

I am getting a similar error using marko 4.7.4

TypeError: Cannot read property 'nextSibling' of null
  at ___forEachNode(turbo-8b8dbcb21bab1dc990eb.js:9541:1)
  at ___detach(turbo-8b8dbcb21bab1dc990eb.js:9532:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3721:1)
  at insertVirtualNodeBefore(turbo-8b8dbcb21bab1dc990eb.js:3546:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3778:1)
  at insertVirtualNodeBefore(turbo-8b8dbcb21bab1dc990eb.js:3546:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3778:1)
  at insertVirtualNodeBefore(turbo-8b8dbcb21bab1dc990eb.js:3546:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3778:1)
  at morphEl(turbo-8b8dbcb21bab1dc990eb.js:3979:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3758:1)
  at morphEl(turbo-8b8dbcb21bab1dc990eb.js:3979:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3758:1)
  at morphEl(turbo-8b8dbcb21bab1dc990eb.js:3979:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3758:1)
  at morphEl(turbo-8b8dbcb21bab1dc990eb.js:3979:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3758:1)
  at morphComponent(turbo-8b8dbcb21bab1dc990eb.js:3609:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3727:1)
  at morphEl(turbo-8b8dbcb21bab1dc990eb.js:3979:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3758:1)
  at morphComponent(turbo-8b8dbcb21bab1dc990eb.js:3609:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3727:1)
  at morphEl(turbo-8b8dbcb21bab1dc990eb.js:3979:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3758:1)
  at morphEl(turbo-8b8dbcb21bab1dc990eb.js:3979:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3758:1)
  at morphEl(turbo-8b8dbcb21bab1dc990eb.js:3979:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3758:1)
  at morphEl(turbo-8b8dbcb21bab1dc990eb.js:3979:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3758:1)
  at morphComponent(turbo-8b8dbcb21bab1dc990eb.js:3609:1)
  at morphChildren(turbo-8b8dbcb21bab1dc990eb.js:3727:1)
  at morphdom(turbo-8b8dbcb21bab1dc990eb.js:3988:1)
  at func(turbo-8b8dbcb21bab1dc990eb.js:9522:1)
  at ___batchUpdate(turbo-8b8dbcb21bab1dc990eb.js:10613:1)
  at ___rerender(turbo-8b8dbcb21bab1dc990eb.js:9505:1)
  at ___update(turbo-8b8dbcb21bab1dc990eb.js:9461:1)
  at updateComponents(turbo-8b8dbcb21bab1dc990eb.js:10594:1)
  at e(turbo-8b8dbcb21bab1dc990eb.js:10566:1)
  at apply(turbo-8b8dbcb21bab1dc990eb.js:4294:1)
  at e(app.js:13324:1)

It is not something I can reproduce easily as it doesn't always happen with the same behaviour. I have logs in sentry recording that this is happening periodically. My case is not related to hydrating the rendering on the server.