This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Try setting the tooltip text to this: "<html><font size=-2>Foo = 0x5242323<br>Type: struct foo *<br>*Foo = { v = 17; y = \"mod\"; next = nil }</html>" This tooltip is taller than your average one-line tooltip, so the net result is that the tooltip sometimes completely covers the text it's associated with (in the case where the tooltip is placed above the text). The tooltip code must assume a certain height of the tooltip. Instead, it should get the height of the tip by looking it up dynamically, and then using that height in the positioning code. This is important for accessibility (a11y) too. If the user has chosen a really large font (say 48 pixels) because of sight issues, the same issue could occur. In my case this is for debugger balloon evaluation. When looking at an expression (in native code) you often are looking at a pointer, e.g. 0xffe4232. You often want to know what it's pointing to. Sometimes you want to know the type of an expression (e.g. what is the type of foo.bar.baz?). Therefore, I encode all three values in the tooltip, one per line. This works pretty well except for the size issue. I played around with this some months ago, and wrote the below code. It's probably not right, but perhaps contributes some ideas. I think that ToolTipSupport's updateToolTipBounds method should be adapted to something like this. Note that this is based on ToolTipSupport the way it was written before Milo did his extensive tooltip work, so many details may have changed. protected void updateMultiLineToolTipBounds() { Dimension prefSize = toolTip.getPreferredSize(); Rectangle extBounds = extEditorUI.getExtentBounds(); int x = Math.min(lastMouseX - prefSize.width / 2, extBounds.x + extBounds.width - prefSize.width); x = Math.max(x, extBounds.x); int lineHeight = extEditorUI.getLineHeight(); int y = lastMouseY - 2 * lineHeight; if (y - extBounds.y < lineHeight) { y = lastMouseY + lineHeight; } // XX what are the extent bounds? y = lastMouseY - lineHeight - prefSize.height; if (y < 0) { // Hrm, it's above the top, so try below instead. y = lastMouseY + lineHeight; /* if (y + prefSize.height > screenHeight) { y = screenHeight-prefSize.height; // try to move it to the right as well such that it // doesn't block the text. Move it all the way to the // left or right to minimize what it's blocking for // the user. if (x < screenWidth / 2) { x = screenWidth-prefSize.width; } else { x = 0; } } */ } /* System.out.println("\nupdateMultiToolTipBounds:"); System.out.println("extBounds.x: " + extBounds.x); System.out.println("extBounds.y: " + extBounds.y); System.out.println("x: " + x); System.out.println("y: " + y); System.out.println("boundsx: " + (int)(x-extBounds.x)); System.out.println("boundsy: " + (int)(y-extBounds.y)); System.out.println("ToolTipX is " + toolTip.getText()); System.out.println("PrefSize.width: " + prefSize.width); System.out.println("PrefSize.height: " + prefSize.height); */ toolTip.setBounds(x - extBounds.x, y - extBounds.y, prefSize.width, prefSize.height); }
Why has this bug A11Y keyword?
> Why has this bug A11Y keyword? It's right there in the original description: This is important for accessibility (a11y) too. If the user has chosen a really large font (say 48 pixels) because of sight issues, the same issue could occur. Anytime you fail to accept an arbitrarily large font (which users with poor eyesight usually do) you have an a11y bug. And note that 48 pixel fonts are not unrealistic. I've seen users use them. What happens then is that the screen shows a viewport of the whole desktop and as the mouse moves around the viewport follows.
Target milestone -> 3.3.1.
Reassigned.
lower priority to P4, due to Accessibility Bug Priority Guidelines.
I don't know that this bug should be downgraded based on a11y criteria. The root problem for us is that we can't use multiline tooltips. This is needed in the debugger to show both value and type information. I added the note about a11y because it's also an a11y bug.
Hi Tor, I think this issue should be covered by the fix of the #22047 that fixes the bad appearance of the tooltip texts being too long to fit horizontally into the editor window. If that fix does not cover the problem please reopen the issue again. *** This issue has been marked as a duplicate of 22047 ***
Resolved for 3.3.x or earlier, no new info since then -> closing.