Open
Bug 283056
Opened 19 years ago
Updated 2 years ago
Is nsWebShellWindow::LoadContentAreas needed?
Categories
(Core :: XUL, defect)
Tracking
()
NEW
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.
Updated•16 years ago
|
Assignee: jag → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•