Bug 143360 - Scrollbars are left in the wrong position when resizing a fixed layout view
Summary: Scrollbars are left in the wrong position when resizing a fixed layout view
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Horton
URL:
Keywords:
Depends on: 143364
Blocks:
  Show dependency treegraph
 
Reported: 2015-04-02 22:49 PDT by Tim Horton
Modified: 2015-04-03 11:30 PDT (History)
6 users (show)

See Also:


Attachments
Patch (8.78 KB, patch)
2015-04-02 22:50 PDT, Tim Horton
bdakin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 2015-04-02 22:49:40 PDT
Scrollbars are left in the wrong position when switching into fixed layout
Comment 1 Tim Horton 2015-04-02 22:50:18 PDT
Created attachment 250040 [details]
Patch
Comment 2 Tim Horton 2015-04-02 23:38:22 PDT
http://trac.webkit.org/changeset/182307
Comment 3 Csaba Osztrogonác 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.
Comment 4 Tim Horton 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.
Comment 5 Brent Fulgham 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!
Comment 6 Tim Horton 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.
Comment 7 Brent Fulgham 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! :-)