Bug 64290

Created attachment 100314 [details] Patch

This would be a simple patch for simon or hyatt to review.

Comment on attachment 100314 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=100314&action=review > Source/WebCore/ChangeLog:18 > + No tests because this change affects only when fixedLayoutSize is set. Since our dumpRenderTree doesn't set it, we can't test this. DumpRenderTree has a layoutConstroller.overridePreference() which can be used to toggle a setting for a single test. Seems if your DRT supports that (which ideally it should), it would be easy to write a test for this.

Comment on attachment 100314 [details] Patch r- for lack of test.

(In reply to comment #3) > (From update of attachment 100314 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=100314&action=review > > > Source/WebCore/ChangeLog:18 > > + No tests because this change affects only when fixedLayoutSize is set. Since our dumpRenderTree doesn't set it, we can't test this. > > DumpRenderTree has a layoutConstroller.overridePreference() which can be used to toggle a setting for a single test. Seems if your DRT supports that (which ideally it should), it would be easy to write a test for this. No. layoutController.overridePreference() is not helpful because it toggles only settings of WebSettings. To turn on the fixedLayoutSize feature, to test this patch, FrameView::setUseFixedLayout(true) have to be called. I think there is no easy way to turn on this feature for a single test.

> No. layoutController.overridePreference() is not helpful because it toggles only settings of WebSettings. > > To turn on the fixedLayoutSize feature, to test this patch, FrameView::setUseFixedLayout(true) have to be called. > > I think there is no easy way to turn on this feature for a single test. It raises an interesting point. I do not think it should be necessary to set the fixedLayoutSize and set useFixedLayoutSize to TRUE. Maybe once it is set to something different than 0x0, it should be used. There could be a logicalLayoutSize in ScrollView that abstracts this for the call sites. IntSize ScrollView::logicalLayoutSize() const { if (m_fixedLayoutSize.isValid()) // != 0x0, and has non zero values return m_fixedLayoutSize; return viewportSize; }

(In reply to comment #6) > > No. layoutController.overridePreference() is not helpful because it toggles only settings of WebSettings. > > > > To turn on the fixedLayoutSize feature, to test this patch, FrameView::setUseFixedLayout(true) have to be called. > > > > I think there is no easy way to turn on this feature for a single test. > > It raises an interesting point. I do not think it should be necessary to set the fixedLayoutSize and set useFixedLayoutSize to TRUE. > > Maybe once it is set to something different than 0x0, it should be used. > > There could be a logicalLayoutSize in ScrollView that abstracts this for the call sites. > > IntSize ScrollView::logicalLayoutSize() const > { > if (m_fixedLayoutSize.isValid()) // != 0x0, and has non zero values > return m_fixedLayoutSize; > > return viewportSize; > } Here is the implementation of the layoutWidth(). int ScrollView::layoutWidth() const { return m_fixedLayoutSize.isEmpty() || !m_useFixedLayout ? visibleWidth() : m_fixedLayoutSize.width(); } As you can see, m_fixedLayoutSize is not returned, even if it isn't empty, when m_useFixedLayout is not TRUE. Unfortunately there is also no function like you said in ScrollView. For now, we have to set both fixedLayoutSize and useFixedLayoutSize.

> It raises an interesting point. I do not think it should be necessary to set the fixedLayoutSize and set useFixedLayoutSize to TRUE. Alex Faeroy has a patch up for review that removes the need for useFixedLayoutSize.

(In reply to comment #8) > > It raises an interesting point. I do not think it should be necessary to set the fixedLayoutSize and set useFixedLayoutSize to TRUE. > > Alex Faeroy has a patch up for review that removes the need for useFixedLayoutSize. Good. Can you point me to the patch? If it is true, I should wait for the patch to land.

(In reply to comment #8) > > It raises an interesting point. I do not think it should be necessary to set the fixedLayoutSize and set useFixedLayoutSize to TRUE. > > Alex Faeroy has a patch up for review that removes the need for useFixedLayoutSize. Kenneth, Alex, will this patch be submitted? Otherwise I can submit it myself?

(In reply to comment #10) > (In reply to comment #8) > > > It raises an interesting point. I do not think it should be necessary to set the fixedLayoutSize and set useFixedLayoutSize to TRUE. > > > > Alex Faeroy has a patch up for review that removes the need for useFixedLayoutSize. > > Kenneth, Alex, will this patch be submitted? Otherwise I can submit it myself? I can talk to Alex tomorrow; he is ahf on the #qtwebkit channel. I'm afraid that he is winded up in something pretty critical though. Did you have the bug id for the patch he was working on?

Comment on attachment 100314 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=100314&action=review >>> Source/WebCore/ChangeLog:18 >>> + No tests because this change affects only when fixedLayoutSize is set. Since our dumpRenderTree doesn't set it, we can't test this. >> >> DumpRenderTree has a layoutConstroller.overridePreference() which can be used to toggle a setting for a single test. Seems if your DRT supports that (which ideally it should), it would be easy to write a test for this. > > No. layoutController.overridePreference() is not helpful because it toggles only settings of WebSettings. > > To turn on the fixedLayoutSize feature, to test this patch, FrameView::setUseFixedLayout(true) have to be called. > > I think there is no easy way to turn on this feature for a single test. It just so happens that I have two layout tests that address precisely this problem and I added fixedLayout to the chromium DRT (I'm not sure if it's in other DRTs at the moment). I will move this to window.internals, I guess.