A book's Use line waits on a spell the client has not fetched

Move it

Frontmatter

Revision: 1
Type: bug
Status: done
Assignee: nobody
Estimate: none
Parent: none, which is loose rather than invalid
Labels

No timestamps and no authors. Git holds both, and the log on the overview is where they are read from.

Attachments (0)

None yet.

Body

Hover a profession book in the bags and the box says the item's name, its level and what skill it requires, and nothing about what it is for. The line that is missing is Use: Teaches you advanced first aid, allowing a maximum of 375 first aid skill., which is the whole reason anybody carries the book.

Why it is missing

That line is not the item's. It is the spell's own sentence printed on the item, and the client does not hold every spell's text at all times: it fetches one when something asks for it and leaves the line off the tooltip until it lands. A potion or a trinket you press reads correctly because its spell is already on the machine; a book teaching something you have never cast is the case where nothing ever asked.

UI/Scan.lua reads the tooltip once, at the moment the pointer arrives, and the box that comes back is complete in every respect but the one. Thin in UI/Tip.lua already rebuilds a box that was waiting on an item, and it cannot see this: the head band has lines in it and none of them is RETRIEVING_ITEM_INFO.

Syndicator does the same three calls on this client, in Search/CheckItem.lua:508: C_Item.GetItemSpell for the id, C_Spell.IsSpellDataCached for whether the text is here, and C_Spell.RequestLoadSpellData for one that is not.

The fix

Scan.Waiting(link): the spell behind an item's Use line, whether the client has it, and the ask for one it has not.
Thin counts a box waiting on that spell as thin, so Tip.Arrived rebuilds it, and SPELL_DATA_LOAD_RESULT joins GET_ITEM_INFO_RECEIVED on the frame that drives it.
A worn slot carries no link, so it is asked for: a trinket you press has a Use line the same as a book does.

Gate

48-tooltip-arrival.lua, on a book fixture whose spell is not cached: the first hover draws no Use line and asks the client for the spell, and the box fills in where it stands when SPELL_DATA_LOAD_RESULT arrives.

Write it

Comments (1)

Cause. The Use line on an item is the spell's own sentence, and the client fetches a spell's text separately from the item that prints it. A book teaching something nobody has cast is the one case where nothing ever asked, so the line was never on the tooltip UI/Scan.lua read. Every potion and trinket read correctly because their spells were already on the machine, which is why this looked like a book-shaped bug.

Fix. aa906b6. Scan.Waiting is the second question: the item's spell id, whether its text is here, and the request for one that is not, which are Syndicator's three calls in Search/CheckItem.lua on this client. Thin in UI/Tip.lua counts a box waiting on that spell as thin and SPELL_DATA_LOAD_RESULT joins GET_ITEM_INFO_RECEIVED on the frame that rebuilds it. A worn slot has no link so one is asked for through GetInventoryItemLink; a trinket you press has a Use line the same as a book does. ns.ItemSpell hands back the id beside the name and nothing else reads it.

Gate. 48-tooltip-arrival.lua, second half, on a book fixture carrying spell 27029 with its text uncached: the first hover draws the client's text without the Use line and asks for the spell, the sentence is in the box after the load fires, and a box that already says what it does does not rebuild for the next spell anybody loads. ./scripts/check.sh at 0 warnings and 0 errors, harness ok.

01M1ZXK9A2DQN15DXYHF6W16DW