search

marko-js / marko

A declarative, HTML-based language that makes building web apps fun
https://markojs.com/
MIT License
13.39k stars 645 forks source link

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

Closed bohdyone closed 6 years ago

bohdyone commented 6 years ago

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 ```
hedav85 commented 6 years ago

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.

bohdyone commented 6 years ago

@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 commented 6 years ago

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

austinkelleher commented 6 years ago

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

bohdyone commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

bohdyone commented 6 years ago

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

DylanPiercey commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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

hedav85 commented 6 years ago

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

hedav85 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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.