A sharpening stone applied to a worn weapon errors instead of applying

Cause. A stone, an oil, an enchanting scroll or a poison leaves the client holding a spell that is waiting to be told which item it is for. In that state a click on a slot means "that item", and the call that says so is UseInventoryItem. Character/Worn.lua asked no such question: every left click went to PickupInventoryItem, which is the call the client refuses while a spell is pending, so the click errored. The same stone on the same weapon sitting in a bag worked, because the client's own bag button asks first. Baganator does the same thing two lines from its own click handler, which is where the API name was confirmed for this client.

Fix. Worn.Targeting() asks SpellCanTargetItem, then SpellCanTargetItemID, both through the pcall every other client call in that file goes through, because the two clients need not agree that either exists. Worn.Swap routes to Worn.Use when it answers yes. The combat refusal is untouched and still correct: item use is protected, so an insecure click cannot apply anything mid-fight whatever it calls.

Gate. The client stub had no third state, so it grew one: moved.targeting behind SpellCanTargetItem. Section 52 clicks the main hand with it on and asserts the use call was reached and the pickup was not. Checked the gate bites by pulling the fix out: two FAILs, and green with it back in.

Wrong cause, reverted. Pulled this client's own handler rather than reasoning about it: Gethe/wow-ui-source, branch classic_anniversary, Interface/AddOns/Blizzard_CharacterFrame/Vanilla/PaperDollFrame.lua. PaperDollItemSlotButton_OnClick is left button to PickupInventoryItem, right button to UseInventoryItem, and the file does not mention SpellCanTargetItem anywhere. With a spell waiting for an item the pickup call is what points it at that item; the client does this below Lua, which is why its own sheet asks nothing first. Character/Worn.lua already made exactly that call, so the fix was a no-op at best and a divergence at worst, and the Baganator line quoted in the previous comment was its own refresh notification, not the applying call. Everything from that attempt is out: Worn.Targeting, the routing, the stub state and the section 52 block.

Still open, and the click path is now provably identical to the client's own, so the cause is somewhere else. Blocked on the error text: no BugGrabber or Swatter installed, Logs/FrameXML.log holds only a stale 26 August load line, and the muted-error list in Comfort/Errors.lua is session-only and saves nothing.

Found it, from the screenshot. The dialog is ADDON_ACTION_FORBIDDEN: "WarriorKit has been blocked from an action only available to the Blizzard UI." That names a protected action, not a wrong call, which is why reading the client's own handler did not explain it: PaperDollItemSlotButton_OnClick may make that call because it is the client's own frame, and this page may not, whatever it calls. UseInventoryItem is protected, and so is finishing a spell the client is holding until it is told which item it is for, which is what a stone, an oil, a scroll or a poison is.

Fix. The squares are SecureActionButtonTemplate now. The right button carries type2 macro and macrotext2 "/use <slot>", written once at build, so taking a piece off and firing a trinket run on the path a macro runs on, in a fight as well. The left button is armed with the same line in PreClick only while Worn.Targeting() says a spell is waiting, and disarmed in PostClick, so a left click at rest is still the swap and a left click in a fight cannot fire a macro armed before it. It is the same "/use 16" every sharpening stone macro in the game already carries.

Second defect in the same square, and probably why right click never appeared to do anything: UI.PassCamera handed RightButton and MiddleButton straight through to the camera while the button was registered for RightButtonUp. Drawn, hovered and dead. Off these squares now, and the harness asserts it stays off.

Gate. The stub learned PreClick, which Region:Click never ran, and SetPassThroughButtons, which fell through to a no-op. Section 52 reads the attributes rather than watching for a call, because a call is the thing that must not happen. Pulled the arming and put PassCamera back to check it bites: three FAILs.