Bug 1089815 - Printing and print preview from view source will be broken when bug 1082575 lands

This is a regression that I caused with my PrintUtils work.

Uplift happens on November 24th.

The problem seems to be that, for some reason, that browser that is created for print previewing in the view source window does not have a message manager.

That's pretty interesting. Why is that? Does the main browser in the view source window have a message manager?

Yes it does. It just looks like programmatically generated browsers in the view source window don't get a message manager. I wonder if that's true in general as well.

Yes… it does. Programmatically created browsers don't seem to get message managers.

And yet, that's preposterous. tabbrowser creates browser elements programmatically all the time. What are we doing differently?

Interesting… in nsFrameLoader::EnsureMessageManager, we seem to bail out in the view source case because mIsTopLevelContent is false. In the tabbrowser case, mIsTopLevelContent is true.

I wonder where that distinction is made...

Ah - looks like mIsTopLevelContent is set to the return value of nsFrameLoader::AddTreeItemToTreeOwner, which only returns true if the browser element has type="content", "content-targetable" or "content-primary".

So, I guess that's what we'll do then - I'll set "content" on it.

I'll also update the PrintUtils documentation while I'm at it.

Mossop (and I!) are curious about why that type attribute is needed here. I'm needinfo'd smaug.

From smaug:

"We certainly don't want message manager for all the <browser>s. IIRC that would break sidebar for example. You'd get the frame scripts loaded which are meant for content tabs (assuming window level mm was used for loading the scripts). That was at least the original issue, years ago, IIRC."

This might no longer be true with the messagemanagergroup stuff that was added. But meh. Now I know.