Bugzilla – Full Text Bug Listing
| Summary: | Popups and tooltips are showing multiple content | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Michael Rennie <Michael_Rennie> | ||||||
| Component: | Client | Assignee: | Eric Moffatt <emoffatt> | ||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | curtis.windatt.public | ||||||
| Version: | 9.0 | ||||||||
| Target Milestone: | 10.0 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 471976 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
Looks like there is some weird caching going on in tooltip.js#_processInfo, then later in #_showContents we end up appending to the same cached version over and over again. Caused by Bug 471976. The hide short circuits if you don't pass in the clearLock flag. When mousing or keyboard updown in content assist the flag is passed, but when typing to filter CA, the code path is separate and the flag is not used. Tooltip.hide (tooltip.js:184) objects.mixin.install._listener.onSelection (editor.js:856) EventTarget._dispatchEvent (eventTarget.js:76) EventTarget.dispatchEvent (eventTarget.js:62) TextView.onSelection (textView.js:2776) TextView._setSelection (textView.js:6914) TextView._modifyContent (textView.js:6558) TextView._doContent (textView.js:4874) TextView._handleKeyPress (textView.js:3881) TextView._hookEvents.handlers.push.handler (textView.js:6317) Yes, this is a strange one...the page tries to tear down the tooltip and fails but then we get another 'show' (without CA ever having called 'hide' with the 'clearLock' set I think). In any case here's a 'fix' that ensures that the '_tooltipDiv' only ever contains a single '_tooltipContents': http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=67f6b421f8df3a7ca6d0ae04e88d26db4c9b662b (In reply to Eric Moffatt from comment #4) > Yes, this is a strange one...the page tries to tear down the tooltip and > fails but then we get another 'show' (without CA ever having called 'hide' > with the 'clearLock' set I think). > > In any case here's a 'fix' that ensures that the '_tooltipDiv' only ever > contains a single '_tooltipContents': > > http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/ > ?id=67f6b421f8df3a7ca6d0ae04e88d26db4c9b662b something is still flakey here. While testing the new version of Tern I could do the following: /*eslint-env amqp*/ /** * @param {object} a * @param {type} b */ function f(a, b, c) {} new Array().concat(new Array(1)); f(); a^ 1. hover over f() -> see hover 'a function' 2. activate assist at ^ -> see first proposal with hover 'a function' 3. mouse up/down it corrects I think at this point if we can't properly fix this we should revert any commits prior to this problem. It gives the impression that the tools are not working, when in reality its just the tooltip code. Created attachment 255246 [details]
Here's what I see for the two cases you mention
Mike mentioned that we really should have some unit tests for this. I'll look into how we might do this (special testing hover providers...). We haven't seen any more duplicate issues since we added API to only update the div size without affecting contents. Recently in Bug 482522 we had duplicate contents because we weren't using this new API. I'm closing this bug as WORKSFORME. Mike, if you have seen any other duplicated tooltips please reopen. |
Created attachment 255188 [details] screen shot of assist hover multiples Something has happened with the tooltips / popups, they are now showing old content when reopened, and multiples of it. In the attached screen shot I activated HTML assist and started typing 'base' You can see the tooltip for the first entry in the template list, followed by 'b' followed by 'base'.