Bug 31036 – need a height equivalent of RenderBox::minPrefWidth()

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Erik Kay]

(apologies if an API like this already exists, but I haven't been able to find it)

For Chrome's extension system, we let the extension create a popup widget using HTML.  This popup widget's size is (mostly) unconstrained externally.  The idea is to let the developer take advantage of some dynamic layout so that they don't have to worry about issues like system font sizes and localization.  Obviously, the developer needs to put some constraints in (whitespace: nowrap,  , an explicit width or height on an element, etc.).

I can get pretty close to my goal by using RenderBox::minPrefWidth() (on RenderView) and using contentHeight() for the height and resizing the RenderView to match.  Unfortunately, with this technique, the height will never shrink.  There doesn't seem to be a way to ask for the "intrinsic height" of the view at its current width.  I'm assuming this must be known somewhere in order to calculate the overflow if any, but it looks like this value isn't saved or exposed.

[Dave Hyatt]

Just size the height of the view to 0 and then get the lowestPosition.

[Erik Kay]

Thanks for replying Dave.  I'm not sure if your suggestion will work for me.  There are two issues.  The first issue is that since there's no real way to know when layout is "done", there's not a good point for me to know when size it back to the correct height so that it can draw.  When I have the view sized to a zero height, I can't draw it, so this affects the responsiveness of the UI (how long it takes for me to be able to display the widget initially).  

The second (related) issue is that given that I want to display the widget as quickly as possible, I really need to be able to respond to size changes dynamically and resize the view accordingly.  This would put me in a position of having to toggle back and forth between a zero height and the desired height after each layout, just to be able to see if the height changed.  I'm concerned that it may be difficult to do that without introducing some serious flicker.

[Aaron Boodman]

Dave, do you know where the correct state might live in WebCore so that we could add plumbing to make it more accessible to a WebKit host?

[Aaron Boodman]

Created attachment 43209 [details]
patch

This isn't a complete solution because it doesn't work in quirks mode. I will create a separate bug to fix that, harder problem.

[Aaron Boodman]

Created attachment 43210 [details]
tabs to spaces

[Eric Seidel (no email)]

I do not know if this is the height value you want.  The patch is certainly non-harmful however, so I'm happy to r+ it.  But, I think you should seek confirmation from other web experts as to if document.scrolleHeight will be sufficient.

[Aaron Boodman]

Thanks.

Erik Kay requested that I add to this bug what I found with fixing quirks
mode in case someone else wants to pick it up:

The important routine is RenderBox::calcHeight(). At the end of that method, if
the document is in quirks mode, the calculated height is overwritten with a
different one that is computed a different way (look for the comment that
starts with "WinIE").

I think that in order to get what we want in quirks mode, we would need to
store that first, unquriked value from calcHeight(), and then add a new method
like scrollHeightWithoutQuirks() or some such that uses the non-quirked height.

(It could probably be factored nicer).

[Aaron Boodman]

Comment on attachment 43210 [details]
tabs to spaces

Rejecting patch 43210 from commit-queue.

Found no modified ChangeLogs, cannot create a commit message.
All changes require a ChangeLog.  See:
http://webkit.org/coding/contributing.html

[Aaron Boodman]

Comment on attachment 43210 [details]
tabs to spaces

Rejecting patch 43210 from commit-queue.

Found no modified ChangeLogs, cannot create a commit message.
All changes require a ChangeLog.  See:
http://webkit.org/coding/contributing.html

[Eric Seidel (no email)]

Aaron, looks like this never quite made it in.  Would you like me to cq+ it?  The commit-queue is back up and running fine now.

[Aaron Boodman]

It did make it, I'm afraid:
http://trac.webkit.org/changeset/50983

When I was trying to repeat the steps you showed me to workaround the problem we encountered with bugzilla-tool, I accidentally submitted this with my git change description, which was not very informative.

[Eric Seidel (no email)]

Thanks for the update!  Doing your first commit on a new machine is always a bit tricky.  Sorry our process isn't simpler. :(