Uncaught TypeError: Cannot read property 'nextSibling' of null #920

bohdyone · 2017-11-03T09:34:44Z

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

The text was updated successfully, but these errors were encountered:

hedav85 · 2017-11-06T11:56:22Z

Hi,
could this be related to #895 ?

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

bohdyone · 2017-11-07T01:24:34Z

@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 · 2017-11-07T04:34:26Z

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

austinkelleher · 2017-11-07T12:10:11Z

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

* Resolve issue #920. * Resolve issue #914 * Improve test.

bohdyone · 2017-11-24T05:42:21Z

@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)

hedav85 · 2017-11-24T19:51:37Z

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 (<anonymous>)
    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.

<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>

jesse1983 · 2017-12-10T20:44:08Z

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

bohdyone · 2017-12-11T02:31:24Z

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

DylanPiercey · 2017-12-11T02:49:36Z

@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.

patrick-steele-idem · 2017-12-11T15:36:20Z

@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

DylanPiercey · 2017-12-11T17:33:30Z

@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 · 2017-12-11T17:42:15Z

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

hedav85 · 2017-12-12T07:25:23Z

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

hedav85 · 2017-12-12T07:55:01Z

@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).

DylanPiercey · 2017-12-21T19:03:29Z

@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!

bohdyone · 2017-12-23T01:47:33Z

@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?

cameronbraid · 2018-01-16T01:10:42Z

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.

austinkelleher added the type:bug A bug report label Nov 7, 2017

patrick-steele-idem added a commit that referenced this issue Nov 9, 2017

wip #920

bc745f1

patrick-steele-idem added a commit that referenced this issue Nov 10, 2017

#920 additional work

82a7d9e

austinkelleher mentioned this issue Nov 13, 2017

Top-level "if" statement in marko template yields unhelpful error #914

Closed

DylanPiercey added a commit to DylanPiercey/marko that referenced this issue Nov 15, 2017

Resolve issue marko-js#920.

68129e6

DylanPiercey mentioned this issue Nov 16, 2017

Issue #914 & #920 fix #927

Merged

5 tasks

mlrawlings pushed a commit that referenced this issue Nov 20, 2017

Issue #914 & #920 fix (#927)

aed62f5

* Resolve issue #920. * Resolve issue #914 * Improve test.

DylanPiercey closed this as completed Dec 21, 2017

DylanPiercey added the reason-closed:resolved The question was answered, the bug was fixed, or the feature was implemented label Dec 21, 2017

DylanPiercey reopened this Dec 23, 2017

DylanPiercey self-assigned this Jan 2, 2018

DylanPiercey removed the reason-closed:resolved The question was answered, the bug was fixed, or the feature was implemented label Jan 3, 2018

BryceEWatson mentioned this issue Jun 24, 2018

Adding null check for nextSibling #1066

Closed

3 tasks

mlrawlings mentioned this issue Jul 23, 2018

Diff fragment #1094

Merged

5 tasks

mlrawlings closed this as completed in #1094 Aug 27, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uncaught TypeError: Cannot read property 'nextSibling' of null #920

Uncaught TypeError: Cannot read property 'nextSibling' of null #920

bohdyone commented Nov 3, 2017 •

edited

Loading

Your Environment

Steps to Reproduce

Stack Trace

hedav85 commented Nov 6, 2017

bohdyone commented Nov 7, 2017

bohdyone commented Nov 7, 2017

austinkelleher commented Nov 7, 2017

bohdyone commented Nov 24, 2017

hedav85 commented Nov 24, 2017

jesse1983 commented Dec 10, 2017

bohdyone commented Dec 11, 2017

DylanPiercey commented Dec 11, 2017

patrick-steele-idem commented Dec 11, 2017

DylanPiercey commented Dec 11, 2017

DylanPiercey commented Dec 11, 2017

hedav85 commented Dec 12, 2017

hedav85 commented Dec 12, 2017

DylanPiercey commented Dec 21, 2017

bohdyone commented Dec 23, 2017

cameronbraid commented Jan 16, 2018 •

edited

Loading

Uncaught TypeError: Cannot read property 'nextSibling' of null #920

Uncaught TypeError: Cannot read property 'nextSibling' of null #920

Comments

bohdyone commented Nov 3, 2017 • edited Loading

Bug Report

Marko Version: 4.5.6

Details

Expected Behavior

Actual Behavior

Possible Fix

Your Environment

Steps to Reproduce

Stack Trace

hedav85 commented Nov 6, 2017

bohdyone commented Nov 7, 2017

bohdyone commented Nov 7, 2017

austinkelleher commented Nov 7, 2017

bohdyone commented Nov 24, 2017

hedav85 commented Nov 24, 2017

jesse1983 commented Dec 10, 2017

bohdyone commented Dec 11, 2017

DylanPiercey commented Dec 11, 2017

patrick-steele-idem commented Dec 11, 2017

DylanPiercey commented Dec 11, 2017

DylanPiercey commented Dec 11, 2017

hedav85 commented Dec 12, 2017

hedav85 commented Dec 12, 2017

DylanPiercey commented Dec 21, 2017

bohdyone commented Dec 23, 2017

cameronbraid commented Jan 16, 2018 • edited Loading

bohdyone commented Nov 3, 2017 •

edited

Loading

cameronbraid commented Jan 16, 2018 •

edited

Loading