You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

WebShell Redesign

By Travis Bogard
Last Modified: 10-14-99


     Welcome to the WebShell Redesign page.  This page is dedicated to providing the links and information to track the redesign of the WebShell which is the design of nsWebBrowser and DocShell.  It will also provide the information to follow the process of converting from WebShell to the new system.  If you are interested or affected by WebShell changes, please check back here frequently over the coming days and weeks.
 

Topics of Interest:

Reasons for Redesign:

Take a look at the list of problems in the current WebShell.

Expected Gains in Redesign:

[XXX Add Expected Gains here]

Issues to Deal With:

[XXX Add Issues list here]

Plan of Attack:

    We are running on a bit of a tight schedule for this redesign.  This redesign has far reaching effects in a number of ways, both simple variable type changing all the way to architectural use of the current WebShell.  That said we are coming up with a schedule we think we can meet, yet still get everything in by the time we need it.  In building this new piece we want to minimize out time on a branch.  Branches in general are evil as your code becomes outdated in the APIs it uses from the rest of the system.  But inversely when plugging in your APIs into existing code, you have to worry about changes occuring in the existing code. [Note the below schedule and process is a high-level swag.  As we get farther in we will update these dates and add any steps to the plan that are needed.]

Basic Plan:

  1. Post specs and design to get feedback.
  2. Create two new top-level directories for nsWebBrowser and DocShell to live in
  3. Post interfaces for feedback
  4. Start implementing both nsWebBrowser and DocShell in parrallel in main tree (don't change any uses of webShell).
  5. Build some tests to do component level testing on nsWebBrowser.
  6. Once the components appear to work in our test beds and all implementation is considered done, branch.
  7. On branch start removing all occurences of webShell and change the code to use either nsWebBrowser or DocShell depending on the case.
  8. Once branch is working, merge changes into main tree.
  9. Celebrate it all works!!!!
Schedule:
  1. By 10-14-99 we should have most of the docs posted and complete
  2. By 10-14-99 we should have most of the interfaces done and posted
  3. By 10-15-99 we should have some basic code framing ready
  4. By 11-2-99 we should branch
  5. By 11-16-99 we should be ready to merge back into tip

    6. By 11-30-99 we should be celebrating it all working

How you can help:

    As you can see there is a lot to do and very little time to do it.  So we could use all the help that you can provide.  There are a number of sub-systems that rely on WebShell and that WebShell interaccts with in some way.  We are doing and will do our best to make sure we have not overlooked anything in any particular sub-system in terms of requirments on WebShell or subtle implmentation dependencies.  If you own a sub-system that interacts with WebShell in any way, it would be greatly appreciated if you could review the nsWebBrowser/ DocShell design and make sure there won't be any gotchas.  It is expected that during integration we will have to change a number of these interactions.  That said it would be great if you would sign up to talk out how to change the sub-system to interact with the new system and perhaps sign up to implement those changes when we branch.

General Areas for help:

  1. Interface Review - As mentioned above if your sub-system interacts with WebShell please take a look at the new interfaces.  We are aware that the interface change will require basically a change of every line referencing webShell.  What we want you to point out is if the new interfaces are missing some vital piece of functionality that would be needed.  If you need additional functionality, please let us know.  Those of you out there wishing to embed Gecko, please take this time to review the nsWebBrowser interfaces and make sure every thing you need to do your embedding is available.  Our goal is to make embedding Gecko as easy if not easier than embedding IE.  Any place we fail in this, please let us know.  If we are missing some functionality that IE embedding provides, please let us know.
  2. Tests - The nsWebBrowser and DocShell pieces are going to be written as components.  Since nsWebBrowser is to be the main class for client to Gecko interaction, it must be stand-alone.  If you are currently working on embedding, please help us by starting to write and test agains the new interfaces.  Since these pieces are components, we also hope to get very good component level testing.  If you have ideas for component level tests on the nsWebBrowser please let us know.  Perhaps you could help in implementing them.
  3. Implementation - Once we get all the interfaces done and the code basically framed out there will be a number of opportunities to help out with implementation.  If you wish to help out by implementing a single function to implementing a complete component let us know.  If you aren't very familiar with the Mozilla code, this could be a great opportunity for you to get your feet wet.  There will be many places in code that are commented with "XXX" (do a grep or use lxr.mozilla.org).  In many of the cases there will be comments about what needs to happen.  If you want to start slow and bite off a function at a time, this will be your chance without the steep learning curve of the entire code-base.  If you are more knowledgeable about the Mozilla codebase or if you have components currently working with WebShell please let us know if you want to help implement a whole sub-system to work with the new design.
  4. Come up with new Doc Shells - In the new design, Doc Shells provide a way for us to support embedding different data within the browser.  Basically a DocShell provides an API for managing position within the window and document heirarchy.  Different DocShell's can be written to have completely different content or rendering within them.  For instance there could be an ActiveX DocShell or a Graphics Editor DocShell.  The choice is yours.  If you have ideas and wish to add support for a new embedding within the browser, let us know and try writing to the Doc Shell APIs.

Progress:

[XXX Add Progress Table here]

Team:

Below is a list of people that are currently making up the WebShell redesign team.  There are countless contributors of feedback and design.  This list is meant to be for those wishing to know who to contact for a given problem.  This list will grow as we get more implementers helping us out with the conversion to the nsWebBrowser/ DocShell world.
 
Member Responsibilities (Sub-systems)
Travis Bogard Leading/ Organizing the overall design.  (Interfaces, Core nsWebBrowser, Component Tests, Overall embedding ability).
Steve Clark Helping with design and webshell research, 60% of time currently devoted to WebShell work.  (DocShell)