Open
Bug 67084
Opened 24 years ago
Updated 2 years ago
Need to refactor state change notifications in docShell
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
NEW
Future
People
(Reporter: sfraser_bugs, Unassigned)
Details
Attachments
(1 file)
8.96 KB,
patch
|
Details | Diff | Splinter Review |
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...
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
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.
Reporter | ||
Comment 4•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Updated•15 years ago
|
Assignee: adamlock → nobody
QA Contact: adamlock → docshell
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•