http://bugs.winehq.org/show_bug.cgi?id=17627
Summary: winhlp32: clickable area out of sync with hyperlink text Product: Wine Version: 1.1.13 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: richedit AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net
[The following cannot be observed since wine-1.1.14 because of bug #17601. I believe this makes #17601 a blocker for the present issue.]
Between wine-1.1.0 and 1.1.13, after scrolling with keyboard, the mouse sensitive clickable areas stay at their old position, while all text has scrolled! Also, the bottommost line of text may not be refreshed when scrolling upwards. Similar results with PgUp and PgDn, where sometimes half the screen is not refreshed.
OTOH, scrolling via the mouse with the wheel, the scrollbar or the 2 scrollbar arrow buttons works.
It looks like the situation degraded over time -- perhaps several bugs are involved -- however one issue is older than 1.0.1:
In 1.1.0, as well as 1.0.1, the synchronisation between link text and sensitive area is mostly fine -- except when using the cursor keys on a page where all text fits on the page. There, using the up arrow key causes scrolling up, while the clickable areas don't move. If you click inside the window, a cursor appears and the up/down keys cease scrolling and move this cursor instead.
To reproduce, go to a page with links that fits the window (I used winace.hlp). The cursor shall not be visible. Hit the down cursor key. The text scrolls up, while the mouse sensitive areas remain in place (and are functional). Click into the window and the cursor appears. If you move up now, some text scrolls down, but the refresh is very incomplete.
To observe the effect in 1.0.1, you need to scroll up with the down key until after the scrollbar reaches the bottommost position: i.e. you're scrolling farther than would be possible with only the mouse.
Obviously, the fact that 1.0.1 displays scrollbars immediately while 1.1.0 lacks them (cf. bug #14293) does not matter. So this is not the same as bug #14293 which only appeared in 1.1.0.
http://bugs.winehq.org/show_bug.cgi?id=17627
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |17601
http://bugs.winehq.org/show_bug.cgi?id=17627
--- Comment #1 from Jörg Höhle hoehle@users.sourceforge.net 2009-03-06 03:18:09 --- What I mean with the degradation of the situation is that it may not make sense to perform regression testing between 1.1.0 and 1.1.13 to discover when any keyboard scrolling caused loss of synchronisation, given that some loss of synchronisation can be observed in even older releases.
http://bugs.winehq.org/show_bug.cgi?id=17627
Dylan Smith dylan.ah.smith@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dylan.ah.smith@gmail.com Status|UNCONFIRMED |NEW Component|richedit |programs Ever Confirmed|0 |1
--- Comment #2 from Dylan Smith dylan.ah.smith@gmail.com 2009-03-07 00:45:22 --- It seems like the problem involves pressing up/down keys without first giving focus to the richedit control. It seems as if the builtin winhlp32 is scrolling the contents of the window, without actually sending messages to the richedit controls to have it do this scrolling.
Using native richedit dlls (msftedit, riched20, riched32) seems to have no effect on the bug, so it doesn't no seem to be a richedit bug. Using native winhlp32.exe doesn't have the same bug.
Either way, it is still a valid bug.
http://bugs.winehq.org/show_bug.cgi?id=17627
Dylan Smith dylan.ah.smith@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED
--- Comment #3 from Dylan Smith dylan.ah.smith@gmail.com 2009-03-07 01:11:25 --- I found what I expected in winhlp32, calls to ScrollWindow where EM_SCROLL messages should be sent to the richedit control.
I created a patch and sent it to wine-patches:
winhlp32: Use EM_SCROLL to scroll richedit control. http://www.winehq.org/pipermail/wine-patches/2009-March/070389.html
http://bugs.winehq.org/show_bug.cgi?id=17627
Bug 17627 depends on bug 17601, which changed state.
Bug 17601 Summary: winhlp32: links ceased working http://bugs.winehq.org/show_bug.cgi?id=17601
What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
http://bugs.winehq.org/show_bug.cgi?id=17627
--- Comment #4 from Jörg Höhle hoehle@users.sourceforge.net 2009-03-07 12:07:11 --- I applied your patch to 1.1.16 and it fixed the issue. Thank you again for the ultra fast response. All links are clickable where the text is and the window is now always refreshed properly when scrolling (not considering bug #14293).
Can be marked fixed as soon as it appears in git.
http://bugs.winehq.org/show_bug.cgi?id=17627
Dylan Smith dylan.ah.smith@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
--- Comment #5 from Dylan Smith dylan.ah.smith@gmail.com 2009-03-09 10:47:58 --- (In reply to comment #3)
winhlp32: Use EM_SCROLL to scroll richedit control. http://www.winehq.org/pipermail/wine-patches/2009-March/070389.html
In git as commit fb63cd0c87e6db85bc4ebc31931f0eba8975a0c8.
http://bugs.winehq.org/show_bug.cgi?id=17627
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2009-03-13 11:15:49 --- Closing bugs fixed in 1.1.17.