JDK-6480547 : REG: bug 4118621 which got Integrated in 1.1.8 fails in mustang from b25 onwards.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.0,6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2006-10-11
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u10Fixed 7 b112Fixed
Related Reports
Relates :  
JDK-4118621 - Selected text scrolls text out of view even if there is enough room
Description
Step to reproduce:
----------------------
1)Run the attached program. You will see a frame with textfield. The textfield contains characters from 'A' to 'Z'. If you see character from 'm' to 't' selected in the textfield then the bug is reproduced. Actually the we should see selection from 'a' to 't'.

This happend only on windows. I tested in jdk 1.4.2/fcs/b28  , jdk 1.5.0/fcs/b64/ & Mustang 1.6.0/b20 where its working fine, but it has broken after that. Hence it is a regression. Its just a visual perception , but the functionality is working fine.
Comments
SUGGESTED FIX http://spbweb.russia.sun.com/~ad153231/jdk7/webrev_textcomps_menuitem/index.html
31-08-2010
EVALUATION Diving deeper into problems with selecting text inside Windows's single-line Edit-control... It not only scrolls oddly when its size is 0x0. It also doesn't ever "rescroll" upon being resized as the user might anticipate. Consider the case when Edit-control is already scrolled, and then is enlarged, so that the whole text can be shown. The user is likely to desire that the whole text is shown. But Edit-control doesn't do so, first visible letter keeps being just the same as before Edit-control was enlarged. So, probably a best fix would be to ovverride (customize) Edit-control autoscrolling upon resizing. But there're problems for that from Windows API side. Commands for getting or moditying scrolling state don't work for single-line Edit-control. I mean for example ::GetScrollInfo or EM_LINESCROLL. Still I can't believe that it's impossible to customize Edit's scrolling, but it doesn't seem easy at all. For now, I'm going to fix exactly the case of this regression. That is, to reapply selection when component size is set non-zero for the first time.
07-08-2007
EVALUATION Continuing with native test for setting text-selection on Windows' text-box... It is not clear, why or how native windows text-box decides to scroll itself, upon being set some selection, while box's size is 0x0. So I had an idea, that the fix could be to temporarily set dimensions to non-zero, then apply selection, then set dimensions back to whatever they were. It didn't work. If dimensions are non-zero, setting selection behaves reasonably - text-box gets scrolled so that the carret appears visible. If dimensions are then changed, no additional scrolling happens. Thus, even with having this reasonability, it doesn't help fixing the bug. This leaves the only way to fix this bug that I see. It is to postpone applying native selection until "real" initial size is set to a native text-box.
31-07-2007
EVALUATION Native test shows exactly the same scrolling problem, if EM_SETSEL message is sent to a text-box while its dimensions are 0x0. This makes me a kind of sertain about my previous guess about cause of the problem. Native window for a TextField (on Windows) is created with dimensions 0x0. Then native selection is set, to reflect the selection set until the peer was creted. Then dimensions are set again to 0x0, inside WComponentPeer.initialize. All this happens inside code, indirectly called from ctor (constructor) of WTextComponentPeer. BTW, I must also mention, that ctor of WComponentPeer calls "initialize"-method, which is overridden in WTextComponentPeer! And probably not only there. Thus, the method operates on not yet constructed instance of WTextComponent. Dangerous thing! I already ran into it in attempt to fix the bug.
30-07-2007
EVALUATION Problem is observed only if selection is set (or caret is positioned) before native peer is created. During creation of native peer, if selection was already set, native resource is made to reflect that selection. So, another wild guess for fixing this would be to postpone applying native selection until size is set for the first time.
26-07-2007
EVALUATION I haven't found thread racing. WND is created for a TextField, text is set, EM_SETSEL is sent. Even EM_SCROLLCARET is sent, though it doesn't seem to make any difference. My wild guess is that selection is set before TextField has its size set. If "default" size appears small, then text might appear scrolled. When TextField's heavyweight is enlarged, text might be not scrolled again, even if another EM_SCROLLCARET event is sent, because caret is already visible. Though, I might guess wrong.
26-07-2007
EVALUATION it looks this is a thread race we have in the code, but sync calls chaned timing in "right" direction :(
17-10-2006
EVALUATION actually, the only difference is that, for some reason, not all text is shown initially in the text field (a-l is off screen). So, it is indeed a visial problem only.
11-10-2006