Open Bug 283056 Opened 19 years ago Updated 2 years ago

Is nsWebShellWindow::LoadContentAreas needed?

Categories

(Core :: XUL, defect)

x86
Linux
defect

Tracking

()

People

(Reporter: bzbarsky, Unassigned)

Details

nsWebShellWindow::LoadContentAreas seems to be a method that looks at the
chrome:// URI for the window, extracts certain substrings from it, and uses
those to load certain other URIs in certain <xul:iframe>s or <xul:browser>s (or
perhaps <xul:editor>s) in the window.

The basic idea is that you can open a chrome URI like:

  chrome:///browser.xul?sidebar=sidebar-url;content-primary=browser-url

and cause "sidebar-url" to be loaded in the sidebar and "browser-url" to be
loaded in the thing with id content-primary.  The scheme has a clear problem in
that the "ids" involved are not actually unique nowadays, thanks to tabbrowser.

So the obvious questions:

1)  Is this method used?  Especially by extension authors or other people
writing on top of what we would like to call "libxul"?  This is effectively a
(undocumented as far as I can tell) private libxul api, but people may still be
using it...

2)  Is this something we want to support going forward or just legacy code that
we should work on removing?  Why was this put in anyway?  Danm, you have blame
for this code (back in 1999, so I know asking you questions now is not quite
fair), but the CVS comment just says what the code does, not why, and there is
no bug number or other indication of what the purpose of the code is...
We used this in the early days of XUL. I think it was so we could, for example,
open a browser window given its chrome URL and hand it an initial page to load
all in one handy line of script. Use of this technique may even predate
synchronous construction of chrome for content windows. It probably predates the
|arguments| parameter to window.openDialog.

As Boris mentioned, I have no idea whether it's still in use and it's not
something that falls to a grep with much assurance. Note as mentioned in bug
282938 this is the only known reason for XULWindow to keep its somewhat
problematic array of content shells.
Assignee: jag → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.