Fix: null check in setSmallerLargerStatus to prevent TypeError on wheel scroll

[swapnachoudhary43]

Fixes #6436

Problem

When scrolling the mouse wheel on the canvas before the UI is
fully initialized, setSmallerLargerStatus crashes with:

TypeError: Cannot read properties of null (reading 'children')
    at Activity.setSmallerLargerStatus (activity.js:2188:43)
    at Activity._doSmallerBlocks (activity.js:2176:24)
    at doSmallerBlocks (activity.js:2145:28)
    at HTMLCanvasElement.__wheelHandler (activity.js:2525:55)

Root Cause

this.smallerContainer and this.largerContainer can be null
when the wheel event fires before containers are initialized.

Fix

Added a single null guard at the top of setSmallerLargerStatus:

if (!this.smallerContainer || !this.largerContainer) return;

Testing

• All 123 test suites passing
• Manually verified no console errors on mouse wheel scroll

Checklist

• I have read the contributing guidelines
• Tests pass locally
• Fix is minimal and focused

[github-actions]

❌ Some Jest tests failed. Please check the logs and fix the issues before merging.

Failed Tests:

synthutils.test.js

[kartikktripathi]

Initially, the code looks good, but while trying to reproduce the bug, I was not able to. Can you give the exact steps to reproduce or maybe a clip of this error showing up while you test it?

[github-actions]

✅ All Jest tests passed! This PR is ready to merge.

[swapnachoudhary43]

Hi @kartikktripathi! Thanks for the review. Here are the exact steps to reproduce:

Open Music Blocks in browser
Immediately scroll the mouse wheel on the canvas (within the first 1-2 seconds before UI fully loads)
Open DevTools Console (F12)
You will see: TypeError: Cannot read properties of null (reading 'children') at Activity.setSmallerLargerStatus

This happens because smallerContainer and largerContainer are initialized as null in setupDependencies() and only get assigned later in _setupPaletteMenu(). If the wheel event fires in that window, the crash occurs.
The fix adds a single null guard at the top of setSmallerLargerStatus to return early if containers aren't ready yet.

[kartikktripathi]

Hey, I tried to reproduce it, but I'm still not able to do so on the master branch. Can you record a video of this bug if possible, and attach it here? That'll be helpful.

[Ashutoshx7]

hy any updates on this

[github-actions]

This PR has merge conflicts with master.

Please rebase your branch:

# Add upstream remote (one-time setup)
git remote add upstream https://github.com/sugarlabs/musicblocks.git

# Fetch latest master and rebase
git fetch upstream
git rebase upstream/master

# Resolve any conflicts, then:
git push --force-with-lease origin YOUR_BRANCH

Tip: Enable "Allow edits from maintainers" on this PR so we can auto-rebase for you next time. This only grants access to your PR branch. Your fork's other branches are not affected.

[github-actions]

Merge conflicts resolved. Ready for review.

[swapnachoudhary43]

The Jest failure is in phrasemaker.test.js due to IndexedDB not supported in the Node/Jest environment — this is a pre-existing failure unrelated to this PR. This PR only modifies js/activity.js and js/logo.js.
Confirmed locally: all 71 tests in logo.test.js pass, and phrasemaker.test.js fails on master too.
The last commits to touch phrasemaker.test.js were #6549 and #6516 — neither is part of this PR:
376ccc8 Increase PhraseMaker test coverage from 2% to 47% (#5955)
9738910 fix PhraseMaker default drum preview (#6549)
273e710 fix(phrasemaker): read meter from triggering turtle (#6516)
The Lighthouse desktop failure may also be pre-existing. Happy to investigate further if needed.

[swapnachoudhary43]

@kartikktripathi — conflicts are resolved and CI failures are pre-existing. Could you take another look when you get a chance? Happy to record a video of the bug reproduction if that helps.

[Ashutoshx7]

jest and lighthouse ci faling take a look