field_matrix does not use colors of the block containing it

Expected Behavior

field_matrix should follow the colors of the block containing it.

Actual Behavior

It keeps its own greenish color:

I’ve tried to solve the issue in the PR that references this issue, but my solution feels like a hack. Because the parentBlock property isn’t set on field_matix’s sourceBlock_ when the affected functions are initially called I’ve added guards to protect against ‘undefined’. This solves the issue, but feels wrong.

In contrast field_angle also references sourceBlock_.parentBlock_ but does not need the guards against parentBlock being undefined. I’m guessing that is because it only references sourceBlock_.parentBlock_ in showEditor_ which is called at a later stage than init and setValue where field_matrix sets its colors.

So perhaps the issue is that setParent should be called earlier? But that change seems like it would be above my paygrade 😃

Steps to Reproduce

Add a block containing a field_matrix to an extension and the the extensions colors. Something along the lines of:

getInfo: function () {
        return {
            blocks: [
                {
                    arguments: {
                        MATRIX: {
                            defaultValue: '0101011111111110111000100', 
                            type: 'matrix'
                        }
                    },
                    blockType: 'command',
                    opcode: 'show',
                    text: 'Show [MATRIX]'
                }
            ],
            colour: '#3D7DD9',
            colourSecondary: '#0D4E8E',
            colourTertiary: '#033D6C',
            id: 'myMatixTest',
            name: 'Matrix test',
            targetTypes: ['hub']
        };
    }

Operating System and Browser

Mac OS 10.13.6 (17G65) Chrome Version 70.0.3538.77 (Official Build) (64-bit)

[cwillisf]

@picklesrus I think it would make sense to generate the shadows in the VM. The main obstacle is that I’m not sure how to do that correctly 😉

In general I think it makes sense for the VM (and in particular the extension manager) to be as authoritative as possible when it builds block JSON and XML – I think that approach will decrease the chances that someone will need to troubleshoot in multiple locations when a block doesn’t look right or work correctly.

[picklesrus]

That makes sense. Yes, I think you’re right about the vm during the conversion to scratch blocks. I think we’re going to need something similar to the menu building code you referenced for shadows in extensions. I’m curious to get @cwillisf 's opinion on this though.

@cwillisf: When making extension blocks that have shadows, (e.g. the shadow that contains the matrix field for the microbit extension), should we be generating the shadow’s definition in the vm (right now I think we just get it from the blocks) so we can set the color appropriately? Let me know if you need more context - not sure how easy this thread is to follow if you haven’t had your head in it already 😃