I'm working on a port of webKit to WinCE, and am currently encountering what appears to be a redraw/paint issue when scrolling (horizontally, in this case) to a widget that is originally partially off-screen (an input button in a form). The text all appears to scroll just fine, and the image of the start of the button (which is initially on screen) is moved correctly as well through the backingStore. However, when a paintButton is issued, the button appears in the same location on the screen post-scroll as it does pre-scroll, i.e. in the same position and still partially off the screen, even though the rest of the screen has scrolled.
I'm looking for someone that can help debug this a bit further; hopefully can someone point me at some places to break and look to see which values are being set wrong and why; or if you'd like some specific stack traces I can get those too. I've tracked the code from WebView::scrollBackingStore (where the correct dx,dy values are being used to scroll the entire screen), through WebView::updateBackingStore, through paint code in RenderBlock, into RenderTheme and finally RenderThemeWin::paint (and subsequently paintButton). At this last stage, the x,y,width,height values for my button are still holding their original values (positioning the button partially offscreen in its initial paint), which I believe is correct. drawControl in RenderThemeWin is called, which ends up at DrawFrameControl. However, at this point, the paint still positions the button incorrectly. It is interesting to note that button's text IS positioned correctly after the scroll, however the frame of the button is not. I've downloaded and built webkit in safari, stepped through and verified this code works correctly on a pc and screen coords, etc are the same, so I suspect the culprit is WinCE-specific code, however I've been unable to get further. The html that produces this behavior is: <table> <form id="one" method=post action="/"> <tr> <td> <nobr> Much more text here to offset the whole input field area and require scrolling. It looks like more and more is why <input type="submit" value="Submit More Please!" /> And read this! </nobr> </td> </tr> </form> </table> I can also send in some screen shots of the issue but I wasn't sure if this mailing list supported that. _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
