Bug 143360

Summary: Scrollbars are left in the wrong position when resizing a fixed layout view
Product: WebKit Reporter: Tim Horton <thorton>
Component: New BugsAssignee: Tim Horton <thorton>
Status: RESOLVED FIXED    
Severity: Normal CC: bdakin, bfulgham, hyatt, ossy, sam, simon.fraser
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 143364    
Bug Blocks:    
Attachments:
Description Flags
Patch bdakin: review+

Tim Horton
Reported 2015-04-02 22:49:40 PDT
Scrollbars are left in the wrong position when switching into fixed layout
Attachments
Patch (8.78 KB, patch)
2015-04-02 22:50 PDT, Tim Horton 		bdakin: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Tim Horton
Comment 1 2015-04-02 22:50:18 PDT
Created attachment 250040 [details] Patch
Tim Horton
Comment 2 2015-04-02 23:38:22 PDT
http://trac.webkit.org/changeset/182307
Csaba Osztrogonác
Comment 3 2015-04-03 05:34:11 PDT
(In reply to comment #2) > http://trac.webkit.org/changeset/182307 This new test is flakey on the Mac WK2 EWS. It reported a false failure in bug127428.
Tim Horton
Comment 4 2015-04-03 09:23:51 PDT
(In reply to comment #3) > (In reply to comment #2) > > http://trac.webkit.org/changeset/182307 > > This new test is flakey on the Mac WK2 EWS. > It reported a false failure in bug127428. Interesting. And it's the viewport-units part of the test that is broken, not anything actually important :( I'll try to figure it out in a bit.
Brent Fulgham
Comment 5 2015-04-03 10:37:32 PDT
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > http://trac.webkit.org/changeset/182307 > > > > This new test is flakey on the Mac WK2 EWS. > > It reported a false failure in bug127428. > > Interesting. And it's the viewport-units part of the test that is broken, > not anything actually important :( I'll try to figure it out in a bit. It is acting as if the 'resizeTo' happens over some period of time (is it animated)? Also, I'm confused by the expected test results. How does resizeTo(200, 200) result in a test expectation of 100x100? Is this a 2x resolution issue? But if so, why is the overall layer size correct (400x400)? layer at (0,0) size 400x400 RenderBlock (positioned) {DIV} at (0,0) size 400x400 [bgcolor=#008000] layer at (0,0) size 100x100 RenderBlock (positioned) {DIV} at (0,0) size 100x100 [bgcolor=#0000FF] Very confusing!
Tim Horton
Comment 6 2015-04-03 10:50:21 PDT
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > http://trac.webkit.org/changeset/182307 > > > > > > This new test is flakey on the Mac WK2 EWS. > > > It reported a false failure in bug127428. > > > > Interesting. And it's the viewport-units part of the test that is broken, > > not anything actually important :( I'll try to figure it out in a bit. > > It is acting as if the 'resizeTo' happens over some period of time (is it > animated)? > > Also, I'm confused by the expected test results. How does resizeTo(200, 200) > result in a test expectation of 100x100? Is this a 2x resolution issue? But > if so, why is the overall layer size correct (400x400)? > > layer at (0,0) size 400x400 > RenderBlock (positioned) {DIV} at (0,0) size 400x400 [bgcolor=#008000] > layer at (0,0) size 100x100 > RenderBlock (positioned) {DIV} at (0,0) size 100x100 [bgcolor=#0000FF] > > Very confusing! Not confusing. Fixed layout size of 400 square, viewport size of 200 square. That div is specified as 50 viewport units square, so 100px.
Brent Fulgham
Comment 7 2015-04-03 11:30:38 PDT
> > Very confusing! > > Not confusing. Fixed layout size of 400 square, viewport size of 200 square. > That div is specified as 50 viewport units square, so 100px. Not confusing now! :-)
Note You need to log in before you can comment on or make changes to this bug.