richedit: do not read actual scrollbar state for scrollbar update, use internal state instead

[Alex Villací­s Lasso]

This is supposed to be a fix for bug #12311 . This bug involves a 
recursive message loop where the application forces visibility of 
scrollbars for the richedit control, which causes a WM_SIZE that 
triggers an update of the window size and re-hiding of the scrollbar. 
However, just after exiting the richedit winproc, the app forces 
visibility again, which again triggers a WM_SIZE, and so on. Native is 
oblivious to the fact that an external agent is messing with the 
scrollbar visibility, and is therefore unaffected by recursion. This 
patch attempts to fix this behavior in builtin and test for it. I have 
tried to test it on WinXP-SP2 and Win98, but testing on other platforms 
is helpful too.

Changelog:
* Use internal copy of scrollbar state instead of directly reading state 
from scrollbars, just as native does.
* Tests for ability to externally modify scrollbars.
* Test for behavior that caused recursion until builtin richedit was fixed.

[Alex Villací­s Lasso]

Alex Villací­s Lasso escribió:
> This is supposed to be a fix for bug #12311 . This bug involves a 
> recursive message loop where the application forces visibility of 
> scrollbars for the richedit control, which causes a WM_SIZE that 
> triggers an update of the window size and re-hiding of the scrollbar. 
> However, just after exiting the richedit winproc, the app forces 
> visibility again, which again triggers a WM_SIZE, and so on. Native is 
> oblivious to the fact that an external agent is messing with the 
> scrollbar visibility, and is therefore unaffected by recursion. This 
> patch attempts to fix this behavior in builtin and test for it. I have 
> tried to test it on WinXP-SP2 and Win98, but testing on other 
> platforms is helpful too.
>
> Changelog:
> - Use internal copy of scrollbar state instead of directly reading
>
> state from scrollbars, just as native does.
> - Tests for ability to externally modify scrollbars.
> - Test for behavior that caused recursion until builtin richedit was
>
> fixed.

Nobody has commented on this patch. Is this the wrong strategy to solve 
the problem? Or are tests failing in some other platform? Copy of patch 
at bug #12311 with downloadable app to test.

[Dylan Smith]

On Wed, Jul 2, 2008 at 1:31 PM, Alex Villací­s Lasso
 wrote:
> Alex Villací­s Lasso escribió:
> > This is supposed to be a fix for bug #12311 . This bug involves a
> > recursive message loop where the application forces visibility of
> > scrollbars for the richedit control, which causes a WM_SIZE that
> > triggers an update of the window size and re-hiding of the scrollbar.
> > However, just after exiting the richedit winproc, the app forces
> > visibility again, which again triggers a WM_SIZE, and so on. Native is
> > oblivious to the fact that an external agent is messing with the
> > scrollbar visibility, and is therefore unaffected by recursion. This
> > patch attempts to fix this behavior in builtin and test for it. I have
> > tried to test it on WinXP-SP2 and Win98, but testing on other
> > platforms is helpful too.
> >
> > Changelog:
> > - Use internal copy of scrollbar state instead of directly reading
> >
> > state from scrollbars, just as native does.
> > - Tests for ability to externally modify scrollbars.
> > - Test for behavior that caused recursion until builtin richedit was
> >
> > fixed.
>
> Nobody has commented on this patch. Is this the wrong strategy to solve
> the problem? Or are tests failing in some other platform? Copy of patch
> at bug #12311 with downloadable app to test.

I am wondering if the following is related.

Repeat the following steps with native and buildin wordpad:
1. Open up Wine's word
2. Type/Paste in a lot of lines of text
3. Put the cursor at the end of the text
3. Now increase the height of the window, but not to the point where
all the text is shown and the scrollbar disappears.

With native richedit you will notice the text stays in place and more
space will appear at the bottom past the end of the text.

With builtin richedit you will notice that the text will be scrolled down.

This might show that the scroll position is stored for the richedit
control but it might also show that there are differences as to how
WM_SIZE is handled which lead to the bug.

I haven't looked into it enough to figure it out, but I hope that helps.