Bug 361458 just patched around the problem that we'll continue adding things to browser/base/content/browser-doctype.inc without remembering that we need to check the impact on browser.xul's little brother web-panels.xul. The problem with just doing it is that browser-doctype.inc is a <!DOCTYPE window, and web-panels.xul is a <page>, and the risk of future breakage if the current state of indifference to the root element named in the doctype declaration ever changes (I tested with "<!DOCTYPE goats" which currently works perfectly) isn't clear. We could just move the first line of browser-doctype.inc to the caller, but I'm not quite sure what it ought to be in macBrowserOverlay.xul, since it's both there to define entities in the <overlay> and to be overlaid on the <window> in hiddenWindow.xul.
Created attachment 246434 [details] [diff] [review] It's a window, v.1 Well, at least provisionally it looks like Mano's right that s/page/window/ makes no difference, though it'd be nice to hear from someone on Windows that it doesn't add in any unexpected titlebars or resizers or anything.
Comment on attachment 246434 [details] [diff] [review] It's a window, v.1 Oh, wait, either one of my potential reviewers will be building on Windows, and will see if it grows a titlebar or an extra head or something.
Comment on attachment 246434 [details] [diff] [review] It's a window, v.1 I'm temped to wontifx this. Maybe we should rather move browser-context.inc's entities to a separate dtd file and not include browser.dtd at all.
That WFM: it's certainly cleaner to not include all the UI entities just to get at the context menu ones. It doesn't particularly solve this bug's problem of making it impossible to add a content-related entity to browser.xul without adding it to web-panels.xul, and doesn't sound very interesting to do, so I'd probably leave it for someone who's getting paid to copy-paste-triple-check, but there are enough things to like about both approaches that I won't kick about it either way.
Filed bug 367001