Hi All, As I've mentioned a few times on this list, I'm developing an embedded browser control based on the test_shell project. Below is a synopsis of the design that I've implemented. If there is interest in seeing this included as part of the chromium code base then I'll make an effort to re-factor it into something that matches chromium's code style requirements and submit it for consideration. If it's close to something that might be interesting then I'd be happy to consider any required changes. Otherwise, I'll keep it a separate project and find a good home for it. Any comments or suggestions are welcome.
Regards, Marshall OVERVIEW The interface for the browser control is written in C using standard Windows data types and API functions. All strings are null-terminated and stored in wide character format. I decided on this design to keep the implementation and usage simple, minimize dependencies for the calling application, support i8n, and facilitate utilization from both C and C++. The browser control is hosted in a DLL and exports a single initialization function that accepts two arguments. The first argument is a structure that specifies initialization parameters. These parameters include the URL, arguments to CreateWindowEx(), and an application callback for browser events. The second parameter is a pointer to a thread handle. The chrome event handler, and all browser window procedures, run in a separate thread created by the initialization function. This thread will terminate automatically after all browser windows have been destroyed. EVENTS All notification from the browser to the application is handled via events passed to the application callback function. The application callback function accepts four arguments and returns a true or false value indicating whether it handled the event. The arguments accepted are (a) the handle of the browser window that the event originates from, (b) an arbitrary context pointer that the application can specify during initialization, (c) the event ID and (d) a pointer to the event data structure. All event data structures passed to the callback function are managed by the browser implementation and do not need to be freed by the application. For some events, values can be returned to the browser implementation by means of pointers in the event structure. The GlobalAlloc() function is used with the GPTR flag to allocate data for this purpose, and any data passed back to the browser implementation will be freed after use. Callback events currently supported are: - Window Created. Sent when a new browser window is created. The browser initialization function does not block, and therefore the first browser window handle will also be returned via this event. - Window Message. Every window message received by the browser's window procedure will be passed to the application callback for optional handling. The application could, for instance, intercept a WM_COMMAND message and change the default behavior of the control. - Before Popup. The application can cancel the creation of a popup window. - Before Browse. The application can cancel navigation. Information provided with this event includes the URL, post data and request headers. - Load Start. The browser is about to begin loading a URL. - Load End. The browser has finished loading a URL. - Resource Start. The browser is about to begin loading a resource. The application can provide an alternate data source (in-memory buffer, for instance) or cancel the load. The default behavior of the browser implementation is to load the resource in the same manner as test_shell. - Resource End. The browser has finished loading a resource. - Update Address Bar. Change the address bar to the specified string. This is sent after navigation is committed and before the page has begun loading. - Update Title. Change the title to the specified string. This is sent while the page is loading. - Before Menu. The browser is about to show a context menu. The application can either cancel the menu or show a custom menu in its place. The default behavior of the browser implementation is to show a basic context menu based on the disposition type. - Get Menu Label. Called one time for each item in a default context menu before that menu is displayed. The application can change the text from the English default to something else (a different language, for instance). - Get Print Header & Footer. Called after the web view is rendered to the print context but before the page is ended. The application can insert a custom header/footer string at any of six predefined locations (top left, top center, top right, bottom left, bottom center, bottom right) or do custom drawing on the print context. Information provided with this event includes the current URL, title, page number, total pages, print context, page bounding box and DPI scale factor. - Execute JavaScript. A method has been executed on the "window.embed" object. All JavaScript arguments are provided with this event and the application can specify a return value or cause a JavaScript "no method found" error to be generated. COMMANDS All commands from the application to the browser control are sent using SendNotifyMessage() or related functions. Simple commands, such as view source or print screen, are sent as WM_COMMAND messages. The wParam argument for the WM_COMMAND message is a combination of both the message event ID and the event target (main frame or focused frame). Commands currently supported via WM_COMMAND messages are: - Exit. Destroy the browser application window. - Back, Forward, Reload and Stop Load. Control navigation of the target frame. - Undo, Redo, Cut, Copy, Paste, Delete, Select All. Control selection on the target frame. - Print. Print the target frame. - View Source. Save the target frame's HTML source to a temporary file and open it in the default text viewing application. Commands that require complex arguments, such as load string or create window, are sent via custom windows messages. All data passed to the browser control for custom windows messages is allocated using GlobalAlloc() with the GPTR flag and freed by the browser implementation after use. Commands currently supported via custom windows messages are: - Load URL. Load the specified URL into an optionally specified target frame. - Load String. Load the specified string into the main browser frame with an optionally specified dummy URL. - Execute JavaScript. Execute an arbitrary JavaScript command. - Create Window. Create a new browser window. The application specifies the URL and arguments to CreateWindowEx(). FUTURE WORK The following capabilities still need to be implemented: - Provide access to and support manipulation of the DOM structure. - Design an easy way to dynamically mix application-provided windows with web content in the browser window. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
