Closed Bug 518929 Opened 12 years ago Closed 7 years ago
.external APIs in core code
They're really part of the web platform at this point, and shouldn't need to be re-implemented in Gecko consumers (i.e. Fennec and Firefox). They'd also benefit from being tied to windows to avoid having to fix bug 334875 (and all of its dependencies). They depend on the search service, but that's in toolkit now, and we can just have the methods throw if the service isn't present.
Not fully implemented yet, but stubs out the object in nsGlobalWindow. Modeled this on the existing nsNavigator/nsLocation stuff, but there are some details that I'm not sure about (related to WindowStateHolder, and what should happen in nsGlobalWindow::SetNewDocument - we "update mNavigator's docshell pointer now", but don't for mLocation for some reason).
nsISidebar is a really crappy interface (uses string/wstring, doesn't specify support for relative URIs, etc). I think we should probably just fix it, since I don't think there are internal (or native code) callers.
I'd like to drop support for window.sidebar (bug 862147), so re-summarizing.
No longer blocks: 341283
Summary: implement search nsSidebar APIs (window.sidebar.addSearchEngine, window.external.AddSearchProvider) in core code → implement window.external APIs in core code
Fixed by bug 1068186
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.