JDK-8162618 : Scrollbars get deformed after resizing window when msn.com is loaded
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-07-27
  • Updated: 2016-12-21
  • Resolved: 2016-12-21
Related Reports
Duplicate :  
JDK-8132675 - VBox.setVgrow and HBox.setHgrow corrupt following controls when window resized
Description
Scrollbars get deformed after resizing window when msn.com is loaded.
Image 1 corresponds to b123 rendering, image 2 - to b127.
As of JDK9 b113, issue is not reproducible.

To reproduce, load http://msn.com into Webnode, and try to resize the window.
Comments
Since the patch for JDK-8132675 is fixing the current issue, so making JDK-8162618 as duplicate of JDK-8132675
21-12-2016
Seems you were right then in thinking this was a duplicate. Probably some other difference between 8 and 9 is causing this particular issue to only be seen in 9 even though the underlying problem is in 8, too.
16-12-2016
Tested the POC Patch "fix-for-growbug-02.patch" (attached in JDK-8132675) and seems like fixed the current issue.
16-12-2016
Seems like this issue is a duplicate of JDK-8132675. Currently checking on why the current issue is reproducible only 9 and JDK-8132675 is repro. both on 8 & 9.
15-12-2016
Thanks for the additional hints. It might then make sense for the WebView guys to debug it further to determine what the difference is between JDK 8u and JDK 9.
07-09-2016
My observation is that com.sun.webkit.WebPage::setBounds receives a height of 600px. This calls com.sun.webkit.WebPane::twkSetBounds with height of 600px. twkSetBounds then calls com.sun.javafx.webkit.theme.ScrollBarThemeImpl::getThumbPosition with a height of 100px, and tells the scrollbar to adjust to this height. Prior to this, the same code flow happens, but the height is the expected value of 17px. If I write code that straddles the native call (so in WebPage::setBounds and ScrollBarThemeImpl::getThumbPosition), I can see when the horizontal bar is rendered accurately that the height before / after is 600 / 17, and when it is rendering incorrectly it is 600 / 100. To me, the native code needs to be inspected further to understand what causes this value to change.
07-09-2016
I think it is likely that it is either a controls, graphics or scenegraph bug, since the bug does not happen in JDK 8u112, and the WebKit code is identical between 8u and 9. One possibility is something relating to JEP 253 (although Jonathan's analysis seems to disprove that). Another is an implementation change in scenegraph (e.g., layout), or scrollbar itself. Still another possibility is a graphics bug, perhaps relating to Hi-DPI changes, although I think I've seen it on a non-Hi-DPI screen.
07-09-2016
I can reproduce the issue as outlined by Kevin. I can see, by adding a println to com.sun.javafx.webkit.theme.ScrollBarThemeImpl::adjustScrollBar(ScrollBar sb, int w, int h, int orientation) that the height of the horizontal scrollbar jumps from 17px to 100px. The thread dump is below, but it does not involve controls - this appears to be a webview related issue. "JavaFX Application Thread@826" prio=5 tid=0x10 nid=NA runnable java.lang.Thread.State: RUNNABLE at com.sun.javafx.webkit.theme.ScrollBarThemeImpl.adjustScrollBar(ScrollBarThemeImpl.java:116) at com.sun.javafx.webkit.theme.ScrollBarThemeImpl.adjustScrollBar(ScrollBarThemeImpl.java:125) at com.sun.javafx.webkit.theme.ScrollBarThemeImpl.getThumbPosition(ScrollBarThemeImpl.java:370) at com.sun.webkit.WebPage.twkSetBounds(WebPage.java:-1) at com.sun.webkit.WebPage.setBounds(WebPage.java:522) at com.sun.javafx.sg.prism.web.NGWebView.resize(NGWebView.java:63) at javafx.scene.web.WebView.doUpdatePeer(WebView.java:1304) at javafx.scene.web.WebView.access$2400(WebView.java:101) at javafx.scene.web.WebView$11.doUpdatePeer(WebView.java:1320) at com.sun.java.scene.web.WebViewHelper.updatePeerImpl(WebViewHelper.java:67) at com.sun.javafx.scene.NodeHelper.updatePeer(NodeHelper.java:104) at javafx.scene.Node.syncPeer(Node.java:699) at javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2385) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2531) at com.sun.javafx.tk.Toolkit.lambda$runPulse$33(Toolkit.java:366) at com.sun.javafx.tk.Toolkit$$Lambda$378.1672844077.run(Unknown Source:-1) at java.security.AccessController.doPrivileged(AccessController.java:-1) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:365) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:392) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) at com.sun.javafx.tk.quantum.PaintCollector.liveRepaintRenderJob(PaintCollector.java:320) at com.sun.javafx.tk.quantum.GlassViewEventHandler$ViewEventNotification.run(GlassViewEventHandler.java:870) at com.sun.javafx.tk.quantum.GlassViewEventHandler$ViewEventNotification.run(GlassViewEventHandler.java:830) at java.security.AccessController.doPrivileged(AccessController.java:-1) at com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleViewEvent$461(GlassViewEventHandler.java:911) at com.sun.javafx.tk.quantum.GlassViewEventHandler$$Lambda$173.555908745.get(Unknown Source:-1) at com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:389) at com.sun.javafx.tk.quantum.GlassViewEventHandler.handleViewEvent(GlassViewEventHandler.java:910) at com.sun.glass.ui.View.handleViewEvent(View.java:539) at com.sun.glass.ui.View.notifyResize(View.java:875) at com.sun.glass.ui.mac.MacView.notifyResize(MacView.java:113)
07-09-2016
Transferring to controls team for further evaluation as this issue is not a webkit regression and this issue is specific to JDK 9
06-09-2016
Able to reproduce on JDK9. Not able to reproduce on 8u112 and 8u111 (looks like not a regression from webkit upgrade).
24-08-2016
I cannot reproduce this on 8u112, so that might mean that this is not a WebView bug, but possibly a bug elsewhere.
17-08-2016
I stumbled on this bug again, and after some experimenting, I can make this happen every time on Windows with the following recipe: 1. Load http://google.com/ in HelloWebView 2. Resize the window horizontally smaller starting from the right edge until less than 1/2 of the web page is visible. 3. Scroll the horizontal scroll bar all the way to the right (so the right 1/2 of the page is visible) 4. Resize the window horizontally larger starting from the right edge until the entire web page is visible and the scroll bar disappears. 5. Resize the window horizontally smaller starting from the right edge until less than 1/2 of the web page is visible. 6. Repeat steps 4-5 if needed 7. BUG: a very thick horizontal scroll bar will be drawn
17-08-2016
It seems to be intermittent. I couldn't reproduce it later after launching HelloWebView again.
28-07-2016
The above was done on Windows 10 with the latest FX 9-dev.
28-07-2016
I tried several times as well, first loading msn.com and then resizing. I didn't see the issue. However, later, after loading bugs.openjdk.java.net, I was able to see the problem, where the web page was rendered with a very large scroll bar even before I resized it. See the attached image (openjdk-1). I tried loading another JBS issue, resized the window and the scroll bar is not being properly repainted, you can see leftover garbage to the right of the drawing area in the same very large scroll bar area as in the first image. See the second attached image (openjdk-2).
28-07-2016
[~ilatyshe] Since im not able to reproduce this issue, can you explain in detail about your observation regarding scroll bar?
28-07-2016
I tested this issue on JDK 9, b127 and b128 in windows 7 and i did not see any scroll bar deformation after resize.
28-07-2016