ToolTips.setATooltipBasic(tooltipList, argid, location) in umpleonline/scripts/umple_tooltips.js only explicitly handles location == "above" and location == "below". Any other value — including "right" — falls through to the else branch, which uses a left-side positioning block. Two existing call sites currently pass "right" and therefore silently receive left-side positioning without any warning or error.

Reproduce

1. Open umpleonline/scripts/umple_tooltips.js, the setATooltipBasic function at lines 173–190:

   var positionBlock;
   if (location == "above") {
     positionBlock = {my:"center+15% bottom", at:"top", of:"#"+argid};
   }
   else if (location == "below") {
     positionBlock = {my:"left top+10", of:"#"+argid};
   }
   else { // left
     positionBlock = {my:"right", at:"left", of:"#"+argid};
   }

2. Grep for the callers: grep -rn "setATooltipBasic" umpleonline/ shows two "right" call sites:

   • umpleonline/scripts/umple_feature_tree.js:321 (feature-tree modal hover tooltips)
   • umpleonline/scripts/umple_action.js:6061 (mixset / filter / gv panel-button tooltips)

3. Both produce tooltips visually positioned to the left of the target element, not the right.

Expected

At least one of the following:

• setATooltipBasic should recognize "right" and place the tooltip to the right of the target with a symmetric position block, e.g. {my:"left", at:"right", of:"#"+argid}.
• Alternatively, unknown location values should produce a console.warn (or throw) so silent mismatches don't slip past review.
• Each existing "right" call site should then be audited — its author may have intended the tooltip to be on the right (bug to fix via the new branch) or on the left (caller should pass "left" literally).

Actual Result

location == "right" is silently routed to the left-positioning branch with no indication. The only hint that this is intentional is the // left comment next to the else branch, which is easy to miss.