RESOLVED FIXED Bug 38506
Regression (r41792): Repaint issue with textarea inside overflow:scroll div
https://bugs.webkit.org/show_bug.cgi?id=38506
Summary Regression (r41792): Repaint issue with textarea inside overflow:scroll div
Steven Lai
Reported 2010-05-03 21:51:27 PDT
Created attachment 54993 [details] Test case Refer to the attached HTML. There is a textarea inside 2 nested divs, both being position:absolute. Typing text into the textarea results in corrupted text when and only when either scrollLeft or scrollTop of the outer div are > 10. See the attached screen cap for the corrupted text. * STEPS TO REPRODUCE 1. Load the html in Safari 4+ or Webkit 2. Type some text into text area * RESULTS Text corrupted. * REGRESSION Since r41792 http://trac.webkit.org/changeset/41792 * NOTES If both scrollLeft and scrollTop are < 10, the text is only slightly corrupted. Already typed texts will be recovered when being repainted, after further scrolling or switching to another window.
Attachments
Test case (441 bytes, text/html)
2010-05-03 21:51 PDT, Steven Lai
no flags
Test case that doesn't involved textareas (644 bytes, text/html)
2010-05-07 15:08 PDT, James Robinson
no flags
Patch (52.55 KB, patch)
2010-05-07 17:11 PDT, James Robinson
no flags
Patch (40.97 KB, patch)
2010-06-02 19:32 PDT, James Robinson
mitz: review+
mitz
Comment 1 2010-05-03 21:54:38 PDT
<rdar://problem/7100751> The layout state at the time of repaint has an incorrect offset. It’s a subtree layout and the LayoutState::LayoutState(RenderObject*) constructor, called with the textarea as the root, does not account for the scroll offset of the container (the div).
James Robinson
Comment 2 2010-05-07 15:08:40 PDT
Created attachment 55421 [details] Test case that doesn't involved textareas This test case shows that the issue is not limited to text areas but any object relayout boundary.
James Robinson
Comment 3 2010-05-07 15:10:56 PDT
The second test case fails at r41760. I think that the textarea behavior did regress at r41792 but the underlying bug (the LayoutState ignores the scrolloffset) predates that.
James Robinson
Comment 4 2010-05-07 17:11:38 PDT
mitz
Comment 5 2010-06-02 11:35:58 PDT
Comment on attachment 55437 [details] Patch > + RenderLayer* layer = toRenderBoxModelObject(container)->layer(); Although inspection of the current code shows that it’s true, there is no great guarantee that container is a RenderBoxModelObject. Do you think we can change the signature of the constructor to require a RenderBoxModelObject? Should this also initialize m_clipped and m_clipRect?
James Robinson
Comment 6 2010-06-02 17:50:36 PDT
Thanks for taking a look at this! I had actually forgotten about this patch completely. I'll look in to whether to initialize m_clipped and m_clipRect explicitly. I'm not sure what you mean about changing the signature - do you mean making the constructor something like: LayoutState(RenderObject* root, RenderBoxModelObject* container) ? That would just move the cast to the callsite, I believe.
James Robinson
Comment 7 2010-06-02 19:32:23 PDT
James Robinson
Comment 8 2010-06-02 19:33:56 PDT
Updated the patch to properly take care of m_clipped and m_clipRect and added a test to cover it. Without the clip handling we would overpaint in some circumstances. layout-state-scrolloffset3.html covers this case. I'm still not quite sure what you mean by changing the signature.
mitz
Comment 9 2010-06-02 20:01:10 PDT
(In reply to comment #6) > I'm not sure what you mean about changing the signature - do you mean making the constructor something like: > > LayoutState(RenderObject* root, RenderBoxModelObject* container) > > ? That would just move the cast to the callsite, I believe. Or perhaps the caller already has a RenderBoxModelObject, or perhaps the caller’s caller, or perhaps just casting there would make it more obvious why the cast is correct; and changing the signature would force new callers to do the right thing.
James Robinson
Comment 10 2010-06-03 15:08:14 PDT
Note You need to log in before you can comment on or make changes to this bug.