Change:
}); this._xterm.registerLinkMatcher(this._localLinkRegex, wrappedHandler, { validationCallback: (uri: string, callback: (isValid: boolean) => void) => this._validateLocalLink(uri, callback), <del> tooltipCallback: (e: MouseEvent) => this._widgetManager.showMessage(e.offsetX, e.offsetY, this._getLinkHoverString()), </del> <ins> tooltipCallback: (e: MouseEvent) => { if (this._terminalService && this._terminalService.configHelper.config.rendererType === 'dom') { const target = (e.target as HTMLElement); this._widgetManager.showMessage(target.offsetLeft, target.offsetTop, this._getLinkHoverString()); } else { this._widgetManager.showMessage(e.offsetX, e.offsetY, this._getLinkHoverString()); } }, </ins> leaveCallback: () => this._widgetManager.closeMessage(), willLinkActivate: (e: MouseEvent) => this._isLinkActivationModifierDown(e), priority: LOCAL_LINK_PRIORITY

Discussion:
The underline also isn't appearing <img width="676" alt="screen shot 2018-05-18 at 12 12 49 pm" src="https://user-"
I also encountered this problem on Ubuntu 16.04, underline is not displayed on std input , and std output for Terminal. Hope can be fixed. Version 1.24.1 Commit Date 2018-06-13T17:47:35.732Z Shell 1.7.12 Renderer 58.0.3029.110 Node 7.9.0 Architecture x64
Hi! After some testing I found that the problem (regarding tooltip location) seems to be that, when emits the event, the and properties of the fired instance are zero: ! I believe this is because the DOM element which fires the event is the rendering the character instead of some element with the size of the entire terminal (like the in the default renderer). In order to solve it, I  to and styles so the event don't target those objects and the becomes the , provider. do you think it is a good solution? I can make a PR, if you want. Edit: Those changes should be made on the package (And maybe this issue should be there also?)
Regarding the underline don't appearing I'm trying this solution , and it seems to work (I'm going to sleep right now, but tomorrow I'll make some testing). Do you think it's a feasible solution?
, we probably don't want to handle the tooltip location in since should just be providing all the info it has in the mouse event without making specific assumptions about how that info will be used. I'll let comment on the underline
I made some comments on the underline in that commit , looks pretty close to what we're after. I created to track this, a PR would be fantastic! You would also want to remove the line in that says link underlines are not supported.
Underline don't appearing was fixed in We should wait for 's 3.8.0 release in order to update and close this issue, right?
I've already pulled in your changes, we'll close this off when is merged.

Hmm, something is still a bit off, mousing over and pausing on the bottom few pixels will show the tooltip in the correct position but the pixels above will show the tooltip where it should be for the line above ! !
I still have no idea why this is happening but this is what I got so far: Target of the event in the expected behavior scenario: Target of the event in the unexpected behavior scenario:
PR out upstream which should fix this:
I can no longer reproduce.