The two macros are used in `GetPrefISize()` and `GetMinISize()` implementations.
After removing them, we could further simplify some implementations because we
don't need a `result` variable in many cases.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D206316
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
Use a MiddleCroppingBlockFrame subclass that looks at the value attribute
instead. We don't need accesskey etc for these so we can just reuse it as is.
Differential Revision: https://phabricator.services.mozilla.com/D173669
Factor a MiddleCroppingBlockFrame that does the double reflow shenanigans.
That should both be faster and easier to reason about. The only thing we need
to be careful about is to use the current inline coord from the line layout if
present to compute the real available isize.
Differential Revision: https://phabricator.services.mozilla.com/D173668
Ting-Yu Lin