Does this build? As mentioned in https://phabricator.services.mozilla.com/D81845#2501818, I had to keep it because there were files depending on this.

In D214042#7346770, @saschanaz wrote:

Does this build? As mentioned in https://phabricator.services.mozilla.com/D81845#2501818, I had to keep it because there were files depending on this.

This does not build, looks there are still files dependent on this ReflowInput.h include.

Built on the latest windows 11 OS.

Can you check what those files are and add ReflowInput.h there?

Actually, what I said was wrong earlier. Upon removing the "ReflowInput.h".

There are missing types:

• OverflowAreas
• StyleSizeOverrides

But I think these can be remedied if I include their header files, if that is allowed.

In the "nsIFrame" class, there are redefinitions that need to be removed:
using ReflowInput = mozilla::ReflowInput;
using ReflowOutput = mozilla::ReflowOutput;

There are some member functions of nsIFrame class that depend on a "ReflowInput::BreakType", but we can copy the definition from ReflowInput.h to nsIFrame.h. Looks like its just a small enum class.

Also some member functions of nsIFrame require a passed in an instance of ReflowInput:

• virtual void DidReflow(nsPresContext* aPresContext, const ReflowInput* aReflowInput);
• FinishReflowWithAbsoluteFrame(....)
• ReflowAbsoluteFrames(..)

There are some member functions of nsIFrame class that depend on a "ReflowInput::BreakType", but we can copy the definition from ReflowInput.h to nsIFrame.h. Looks like its just a small enum class.

Hmm yeah, ReflowInput::BreakType is tricky that it cannot be forward declared. I would argue that any enums that is used for parameters of other class methods should not be inside the struct but should be extracted to a separate declaration.

In D214042#7348899, @saschanaz wrote:

There are some member functions of nsIFrame class that depend on a "ReflowInput::BreakType", but we can copy the definition from ReflowInput.h to nsIFrame.h. Looks like its just a small enum class.

Hmm yeah, ReflowInput::BreakType is tricky that it cannot be forward declared. I would argue that any enums that is used for parameters of other class methods should not be inside the struct but should be extracted to a separate declaration.

I agree as well, should I extract the definition of "BreakType" in ReflowInput.h and create a separate headerfile containing only that definition. Something like "/layout/generic/BreakType.h" and make the appropriate replacements?

For the member functions that still contain a functions needing a "ReflowInput" class, are there replacement functions or should I look into cleaning that up.

Yeah so it seems this would need:

• Forward-declaring ReflowInput and .
• Move at least OverflowAreas, and ReflowInput::BreakType to a different file, or include for now.
• Move one or two functions out of line.

Still it seems it'd be worth it in general, but it's a fair amount of work.

In D214042#7353668, @emilio wrote:

• Move one or two functions out of line.

Just to clarify, by functions do you mean the member functions that take in a reference to "ReflowInput". And by "out of line" do you mean to convert them into local functions within the .h/.cpp file.

Commandeering so that I can mark this as abandoned, so that a newly-arrived contributor can pick this up.