WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
84252
[Chromium] set layout fallback width width when FrameView is resized in AutoSizeMode
https://bugs.webkit.org/show_bug.cgi?id=84252
Summary
[Chromium] set layout fallback width width when FrameView is resized in AutoS...
Peter Kotwicz
Reported
2012-04-18 10:33:28 PDT
[Chromium] set layout fallback width width when FrameView is resized in AutoSizeMode
Attachments
Patch
(1.69 KB, patch)
2012-04-18 10:50 PDT
,
Peter Kotwicz
no flags
Details
Formatted Diff
Diff
Patch
(1.72 KB, patch)
2012-04-19 12:37 PDT
,
Peter Kotwicz
no flags
Details
Formatted Diff
Diff
Patch
(1.67 KB, patch)
2012-04-19 13:29 PDT
,
Peter Kotwicz
no flags
Details
Formatted Diff
Diff
Patch
(2.39 KB, patch)
2012-04-20 16:30 PDT
,
Peter Kotwicz
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Peter Kotwicz
Comment 1
2012-04-18 10:50:00 PDT
Created
attachment 137721
[details]
Patch
Fady Samuel
Comment 2
2012-04-18 20:55:08 PDT
Comment on
attachment 137721
[details]
Patch Please check the default device scale factor not the device scale factor.
Peter Kotwicz
Comment 3
2012-04-19 12:37:49 PDT
Created
attachment 137952
[details]
Patch
Fady Samuel
Comment 4
2012-04-19 13:23:09 PDT
Comment on
attachment 137952
[details]
Patch The if statement is unnecessary. You can set the layoutFallbackWidth independent of fixed layout mode, it just won't have any effect.
Peter Kotwicz
Comment 5
2012-04-19 13:29:49 PDT
Created
attachment 137967
[details]
Patch
Darin Fisher (:fishd, Google)
Comment 6
2012-04-20 10:37:18 PDT
Comment on
attachment 137967
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=137967&action=review
> Source/WebCore/page/FrameView.cpp:2501 > + page->settings()->setLayoutFallbackWidth(newSize.width() / page->settings()->defaultDeviceScaleFactor());
nit: indent by 4 spaces
Darin Fisher (:fishd, Google)
Comment 7
2012-04-20 10:38:41 PDT
Comment on
attachment 137967
[details]
Patch Actually, R- I have a few questions: 1- Why are mutating Settings? Normally, Settings are set by the embedder. Perhaps the "effective layout fallback width" should be stored elsewhere? 2- Wondering about Fady's comments.
Fady Samuel
Comment 8
2012-04-20 10:44:55 PDT
(In reply to
comment #7
)
> (From update of
attachment 137967
[details]
) > Actually, R- > > I have a few questions: > > 1- Why are mutating Settings? Normally, Settings are set by the embedder. Perhaps the "effective layout fallback width" should be stored elsewhere? > 2- Wondering about Fady's comments.
1. What's the right place to do this? The issue being solved here is we need to detect this resize, and update the layout fallback width so the viewport scaling is computed correctly 2. Peter had an additional if statement: if (useFixedLayout()) that he later removed.
David Levin
Comment 9
2012-04-20 10:47:04 PDT
Comment on
attachment 137967
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=137967&action=review
> Source/WebCore/ChangeLog:4 > +
https://bugs.webkit.org/show_bug.cgi?id=84252
What is this change fixing?
> Source/WebCore/ChangeLog:7 > +
Why is there no layout test? (Or any test at all?) Is one possible? If not, why not?
> Source/WebCore/page/FrameView.cpp:2498 > +#if ENABLE(VIEWPORT)
Why is this behind ENABLE(VIEWPORT)?
> Source/WebCore/page/FrameView.cpp:2499 > + Page* page = frame()->page();
Why is this done inside of the loop instead of after the loop in this method? I wonder why it is done here at all as opposed to some place closer to "page->chrome()->client()->layoutUpdated(frame());".
Fady Samuel
Comment 10
2012-04-20 10:54:27 PDT
Comment on
attachment 137967
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=137967&action=review
>> Source/WebCore/page/FrameView.cpp:2498 >> +#if ENABLE(VIEWPORT) > > Why is this behind ENABLE(VIEWPORT)?
layoutFallbackWidth is logically associated with viewport computations and so it's behind ENABLE(VIEWPORT)
>> Source/WebCore/page/FrameView.cpp:2499 >> + Page* page = frame()->page(); > > Why is this done inside of the loop instead of after the loop in this method? > > I wonder why it is done here at all as opposed to some place closer to "page->chrome()->client()->layoutUpdated(frame());".
Good point. This doesn't need to be in WebCore at all I think. This can probably be moved to ChromeClientImpl.
Peter Kotwicz
Comment 11
2012-04-20 16:30:10 PDT
Created
attachment 138190
[details]
Patch
David Levin
Comment 12
2012-04-20 16:35:23 PDT
Comment on
attachment 138190
[details]
Patch Looks so much better here. (Note that this method is called at the end of recalc regardless of autosize mode iirc.)
Fady Samuel
Comment 13
2012-04-20 18:14:20 PDT
(In reply to
comment #12
)
> (From update of
attachment 138190
[details]
) > Looks so much better here. (Note that this method is called at the end of recalc regardless of autosize mode iirc.)
Yup this feels like the right place for this code. I think we might be able to remove the layoutFallbackWidth code from: RenderViewImpl::OnResize in the chromium repo now. It only needs to be here I think. Peter could you please verify this?
Stephen Chenney
Comment 14
2013-04-15 07:08:48 PDT
https://code.google.com/p/chromium/issues/detail?id=231320
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