Investigating further...

Ah. I see why. The pinned blocks still use 'CONTEXT_BLOCK', but are stored in a separate block table than blocks. Blocks are in 'block_instance', while sticky blocks are in 'block_pinned'. This means that the 'get_context_instance' function is getting records with an instance id referring to the wrong table. Worse yet, they may actually create a context id record for the wrong block!

Note that the original complaint said that icon had an empty context id. Unfortunately, it may not be empty if it finds a regular block entry with the same id as the sticky block.

I think the better fix is to get rid of the 'block_pinned' table and add a 'pinned' field to the 'block_instance' table.

I do agree that block_pinned could be better re-implemented with a single new column in block_instance, just for increased simplicity alone.

About the contexts, it's a bit tricky to think about since the one "instance" appears site-wide within various other contexts, and so may inherit different permissions from the various parent contexts. Do we process all this like a normal block, effectively treating each place it appears as a sort of virtual instance?

Or are pinned blocks an exception to heirarchy rules, with their own context under SYSTEM level?

Needs some thinking about.

I'll file a new bug for improving sticky blocks.