Bugzilla – Full Text Bug Listing
| Summary: | [Hover] Hover tooltip obscures code with multi line annotation | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Eric Moffatt <emoffatt> |
| Component: | Client | Assignee: | Curtis Windatt <curtis.windatt.public> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | curtis.windatt.public, Michael_Rennie |
| Version: | unspecified | ||
| Target Milestone: | 12.0 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
Two problems with using the last line: 1) With the new placement strategy, the tooltip may sometimes be above the annotation. 2) Would the tooltip be shifted over to line up with the start of the last line as the annotation offset on the last line would be different than the first. Assuming the user is hovering in the editor (not clicking on the left ruler), we also have the offset they are hovering over in the annotation. Perhaps in that case we can use the annotation offsets only from the line they are hovering over. Optimally we should change the 'anchorArea' to not be a simple rectangle, instead use a polygon covering the entire annotation area.
Looks like we may want to do the following:
- first try using the last line and placing the tooltip below
- if there's no room them place it above using the *first* line (so that the *bottom* of the tooltip aligns with the top of the first line)
Note that the combination of the 'anchorArea' and the 'tooltipRect' define the 'polygon' I think (if you're in either one of those areas we ignore hovers...).
(In reply to Eric Moffatt from comment #2) > Looks like we may want to do the following: > - first try using the last line and placing the tooltip below The last line may be quite a long distance from where the mouse is. It is likely still ok for annotations, but you can also have multiple line anchors for contributed hovers. For example, currently the javascript hover for 'function' in the below code has offsets containing the entire function. Something to keep in mind. var a = { x: function(a, b, c){ doStuff(); } }; > - if there's no room them place it above using the *first* line (so > that the *bottom* of the tooltip aligns with the top of the first line) Aligning above is already done with the new tooltip placement code. > Note that the combination of the 'anchorArea' and the 'tooltipRect' define > the 'polygon' I think (if you're in either one of those areas we ignore > hovers...). The 'outerArea' which is a rectangle covering anchor and tooltip, does have that purpose, but the polygon I'm referring to is having a more complex anchor area. With a multi line annotation, the starting offset and end offset may be at different x locations. A simple rectangle anchor area would cover the entire line and the tooltip will always be placed at the leftmost side. var b = [, , , ,, ]; In this case the tooltip is placed outside of the target area so there is no way for the user to move the mouse to the tooltip and press the quick fix. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=1c748907985042d2b8659505cd508e7ef7a84e9c Fixed in master, when computing a rectangle for an annotation offset range we enclose the entire annotation. There isn't a need to do a complex polygon because if another annotation is hovered over within the rectangle a new show tooltip operation occurs closing the existing one. |
If you have a blank method: _foo: function() { } The tooltip appears under the *first* line of the annotation, causing the tooltip to appear on top of the blank line, making it impossible to click there... Perhaps we should change the code so that multi-line annotations use the *last* line rather than the first...