Confirmed — the item is telling the truth and we're the ones not listening. The Rainbow Drawing is one of v83's "raise" items: its data points at a dedicated little window (UI.wz/UIWindow.img/raise), carries nine progress lines from "a sketch is drawn on the paper" through "the picture is finished", and lists the eight crayons it eats along the way. Double-clicking it is supposed to open that window and let you colour the drawing in. We have no raise window at all, and our inventory only sends USE and SET-UP items (plus pets, books and prepaid cards) to a use action — this is an ETC item, so the click hits no branch and does nothing, silently. The window art and every stage sprite are sitting in the v83 UI.wz, so this is buildable exactly as described; it just hasn't been built.

Confirmed — and the item's own description is telling you the truth, we just never built the thing it points at. The Rainbow Drawing is one of v83's "raise" items: double-clicking is meant to open a dedicated little window where you colour the drawing in with crayons over nine stages, and the item's data carries a line of text for each stage. We have none of that window: no raise window at all, and our inventory only gives a double-click verb to USE and SET-UP items (plus pets, books and prepaid cards), so an ETC item like this one gets no response whatsoever — which is why it feels dead rather than erroring.

The window art and every stage sprite are sitting in the v83 UI files, so this is buildable exactly as described; it just hasn't been built, and I'd rather log that than fake a popup. Separately, I noticed in your screenshot that the tooltip prints a stray "\r" mid-sentence — that's our text renderer only un-escaping newlines and not carriage returns. Small, unrelated, and noted.

Investigated — leaving this CONFIRMED rather than claiming a fix, because it turned out to be a whole missing subsystem rather than a broken double-click, and I would rather be straight with you about that.

The Rainbow Drawing (4220152) is not a simple 'open me' item. Its WZ node describes a NURTURE item:

uiData UI/UIWindow.img/raise/24 — its own window art, 8 stage frames
message 9 lines, 0..8 — 'a drawing paper with a sketch' → 'coloured it with crayons' → 'the drawing is complete'
consumeItem 8 entries (4000000, 4001326..4001332) — what you feed it
questId 10430, only 1, slotMax 1, timeLimited 1

So double-clicking should open a small window showing the drawing's current stage, and feeding it the listed items advances it through those 9 messages until finished. Nothing in the reference servers touches it — it is entirely client-side, which is why there was nothing to 'turn on'.

This is not a one-off either: v83 has 67 Etc items driving 27 raise sets (UI/UIWindow.img/raise/0..25 plus a shared backgrnd). Building it properly means extracting that art, a data-driven raise window, and somewhere to persist per-item stage progress — our Etc items currently stack by key with no per-instance state, so the stage has nowhere to live yet.

I have the full spec captured now, so this is ready to build as a scoped piece of work rather than guesswork. Flagging it as a real content gap rather than quietly marking it fixed.

Fixed — the whole subsystem is now in, and I need to correct something I told you earlier on this ticket.

I said feeding it the listed items walks it through the nine messages. That is right for 65 of the 67 raise items, and WRONG for this one. The Rainbow Drawing carries no exp/grade; its progress is an 8-bit MASK. Quest.wz gates it on infoex 255, and the sibling quest enumerates acceptable states as 1,3,5..63,129,131..191 — an acceptance test on individual bits, which a counter cannot express. So it is not 'feed it seven times', it is seven separate daily crayon quests each setting its own bit. Feeding the same crayon twice does nothing, which is now the actual behaviour.

What shipped:

• All 67 raise items, both families. 65 count upward (stage = progress/exp, capped at grade); 2 are bitmask items.
• The authentic window on real UI.wz art — 106 canvases. The frame is a nine-slice with a 1px filler column, so the WZ defines no window size and no reference client implements this window at all (HeavenClient has no raise window, I checked all 68 of its window classes). The size is measured off each art set's largest frame; I have said so in the code rather than pretend it was sourced.
• Stage progress is stored the way v83 stores it — in the character's quest record under the item's questId used as an infoNumber, not on the item. That is why it survives a relog with no new save field.

Text: 8 of the 67 still had Korean captions in v83. All 8 recovered in English from later GMS clients — yours reads 'Canvas with outlined figures.' → 'Colored with crayon.' → 'Completed the picture.' Nothing was written by me.

One thing this turned up that was worse than the reported bug: quest 10430 — the Rainbow Drawing's own quest — was impossible to hand in, along with five others. The extractor that reads quest completion thresholds was storing the literal string 'null' for every one of the 64 thresholds it read, because the value sits one node deeper than it was looking. Fixed and regenerated; that is on develop as 09747d22.

Art is loaded on demand rather than added to the shared window bundle, which is pulled in full on every map load — 444 KB that only matters when you open one of these should not cost everyone a slower zone change.

On develop as edc35bd9.