Bug ID: JDK-8130727 WebView Tooltip position no longer changes in 8u60

Type: Bug
Component: javafx
Sub-Component: web
Affected Version: 8u60,9

Priority: P3
Status: Resolved
Resolution: Fixed
OS: windows_7
CPU: x86_64

Submitted: 2015-07-06
Updated: 2016-07-01
Resolved: 2016-07-01

JDK 8	JDK 9
8u112Fixed	9 masterFixed

FULL PRODUCT VERSION :
java version "1.8.0_60-ea"
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b19)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b19, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows 7 x64

A DESCRIPTION OF THE PROBLEM :
The Java Tooltip used to properly appear over the dom element that had the title attribute. Now this is no longer the case in in Java8U60 when there is a second tooltip that is adjacent to the other tooltip. 


REGRESSION.  Last worked in version 8u45

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
To recreate the issue see this jsfiddle:

https://jsfiddle.net/7sjp6bjx/

or use this html source:

<div title='t1'>test</div>
<div title='t2'>test2</div>

In Java8U45 WebView, the tooltip for both div elements is over the proper element. In Java8U60, if you mouse over one element, get the tooltip, then move to the next element, the tooltip does NOT properly move to the new element and it stays on the original element.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
title should move over the proper html element
ACTUAL -
title stays on wrong html element

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
https://jsfiddle.net/7sjp6bjx/

or use this html source:

<div title='t1'>test</div>
<div title='t2'>test2</div>
---------- END SOURCE ----------

changeset: 45dedcf0547e tag: tip user: asrivastava date: Fri Jul 01 12:20:56 2016 +0530 Reviewed-by: arajkumar, kcra, mbilla URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/45dedcf0547e
01-07-2016
Tested the fix and similar to safari and chrome behaviour. +1
30-06-2016
Confirmed. In that case the fix looks good to me. +1
30-06-2016
I have tested with above mentioned test case on various browsers and old JDK, below is the result: JDK -8 {java version "1.8.0"} -> Issue reproducible [ Tooltip position doesn��t change when text is same] Chrome -> Issue reproducible Safari -> Issue reproducible Internet Explorer -> Not reproducible [ Tooltip position changes when text is same] Firefox -> Not reproducible Ephiphany Browser Linux -> Not reproducible So the fix is not causing any regression .
30-06-2016
You can test this by applying the fix and notice that it fixes the case where no two adjacent divs have the same text, but doesn't work for the following: <html> <body> <div title='tt'>test</div> <div title='tt'>test2</div> <div title='tt'>test3</div> </body> </html>
28-06-2016
This is only a partial fix, since it relies on the value of the Tooltip text. It won't handle the case where two divs have the same string as their Tooltip. Is there a way to associate the Tooltip with the DOM element so that you can check that rather than the text?
28-06-2016
Please review: http://cr.openjdk.java.net/~asrivastava/8130727/webrev.01/ Making "oldTooltipText" to private. Solution works fine as per the old JDK behaviour. No need to remove "oldTooltipText", checked the behavior is not correct if we remove oldTooltipText.
28-06-2016
Option 1 : (Current Impl) convert "String oldTooltipText ... " --> "private String oldTooltipText ..." tooltip.setText(tooltipText); after Tooltip.uninstall(view, tooltip); // Not sure about the behaviour with current solution Option 2 : (Can we eliminate "oldTooltipText" member) ? if (!tooltip.getText().equals(tooltipText)) { Tooltip.uninstall(view, tooltip); isTooltipRegistered = false; }
28-06-2016
+ String oldTooltipText = ""; Should be private String oldTooltipText. I guess old WebKit sets null text before setting new one to platform. So instead of fixing at the bottom layer you could add workaround in the top layer(ie. WebPage.fwkSetTooltip). private final String oldTooltipText = ""; private void fwkSetTooltip(String tooltip) { log.log(Level.FINER, "Set tooltip: " + tooltip); if (pageClient != null) { if (!oldTooltipText.equals(tooltipText)) { tooltip.setText(null); oldTooltipText = tooltip; } pageClient.setTooltip(tooltip); } }
28-06-2016
Please review: http://cr.openjdk.java.net/~asrivastava/8130727/webrev.00/ Casue: Toolkit doesn't aware about divs of a webpage. On hovering from one div to another exit event is not getting fired. Which is needed for hideTimer to stop i.e. "hideTimer.stop();" Which should cause MOVE_HANDLER to get the correct position of tooltip objects. Solution: If the text has changed , uninstall and install the tooltip again. Verified mouse tooltip behavior matches with old JDK behavior.
28-06-2016
Since the impact of this bug is low, changing priority from P3 to P4.
16-06-2016
Tested this issue in windows 8 GA , 8u60 , 9 (webkit upgrade) and observed that this issue is reproducible from 8u60 onwards. This issue is a regression ( introduced from 8u60).
03-06-2016
SQE is ok to defer from 8u60.
14-07-2015
I see no such regression in controls, so it is likely related to the WebKit upgrade. I recommend to defer this to 9. The impact of this bug is low (we might want to consider lowering the priority to P4).
08-07-2015
I can reproduce this bug, but I think it might be a controls bug rather than a web bug. I will run another test and reply here. I do note that it seems to be timing related. If you display the tooltip over the first line and then move directly to the second line, the bug reproduces. If, however, you move to the first line, then move away for a second, then move to the second line, the tooltip shows up in the right place.
08-07-2015
Pending evaluation
08-07-2015