Currently most of the code for showing HTML dialogs is hard-coded to the
gears scheme ("gears://"), used by the 'Create Application Shortcuts'
dialog. If you wanted to add another HTML dialog today, you would need to
add a new scheme for the URL that points to the resource you would like to
have rendered. The sync setup wizard and google account authentication
dialog do this right now using a "cloudy://" scheme. This is crappy.
Especially when you dig a bit deeper and notice things like
// Don't inspect *HTML dialogs* (doesn't work anyway).
if (active_entry->url().SchemeIs(chrome::*kGearsScheme*)) {
popping up here and there. I was thinking of adding a general purpose
scheme for triggering HTMLDialogUI, say 'dialog-resource' and add
DataSources for different paths.
Thoughts? Where on earth do the gears:// urls come from, though?
In the grand scheme of things we likely want to rework the html dialog
altogether, to tear it away from TabContents and use a RenderViewHost
directly. The personalization code used to do something like this using a
thing I added called HWNDHtmlView. I think extensions used it for a while,
and there was a bug+todo there to try and extend it's usefulness, but it
went the way of the dodo bird in r16392
<http://codf1.jail/viewvc/chrome?view=rev&revision=16392>.
Is there some other new thing we have that primarily just implements
RenderViewHostDelegate and runs an RVH?
Anyway, I'm trying to avoid doing this more significant refactor right now.
Id first like to consolidate code paths for the application shortcut+sync
html dialogs in my effort to get rid of the CHROME_PERSONALIZATION #define.
Tim
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
