WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
143360
Scrollbars are left in the wrong position when resizing a fixed layout view
https://bugs.webkit.org/show_bug.cgi?id=143360
Summary
Scrollbars are left in the wrong position when resizing a fixed layout view
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+
Details
Formatted Diff
Diff
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.
Top of Page
Format For Printing
XML
Clone This Bug