Open Bug 67084 Opened 24 years ago Updated 2 years ago

Need to refactor state change notifications in docShell

Categories

(Core :: DOM: Navigation, defect)

defect

Tracking

()

Future

People

(Reporter: sfraser_bugs, Unassigned)

Details

Attachments

(1 file)

The stuff that happens in nsDocShell::OnStateChange() is gnarly and fragile, and 
not factored in a way that makes it possible for derived classes to override the 
default behaviour.

For editor embedding, I'm going to be makeing a subclass of nsDocShell (actually 
nsWebShell currently), which needs to hook in to document loads. By factoring out 
the code in OnStateChange into discrete, overridable methods, I am able to do 
this in a clean way. Patch coming...
With this patch, I've tried to move the recently added cursor and redirection 
stuff into separate methods. One thing that I'm not quite clear on is whether the 
NotifyingCurrentDocument() test is appropriate for every 'STATE_IS_DOCUMENT' type 
state change. Please review.
Simon, the patch looks fine though I'm a bit concerned that you want to subclass 
nsDocShell. Is this something we want to do considering how hateful webshell is? 
If may be more desirable to use some kind of XPCOM notification mechanism 
instead.
I've reimplemented the editor stuff to work without any subclassing. I no longer 
require this state change notification refactoring, but it still seems a good 
thing for maintainability reasons.
agreed. nominating mozilla0.9.1
Keywords: mozilla0.9.1
Target Milestone: --- → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Future
Target Milestone: mozilla0.9.2 → Future
Changing platform
Hardware: All → Macintosh
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Assignee: adamlock → nobody
QA Contact: adamlock → docshell
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: