Closed Bug 13374 Opened 20 years ago Closed 19 years ago
Shell] ns IWebshell improvements
This bug is for tracking all beta issues with nsIWebshell improvements. For the record, here's an email exchange between Travis and Steve ... ---------- Date: Tue, 7 Sep 1999 11:11:46 -0700 From: firstname.lastname@example.org (Travis Bogard) To: "Steve Clark" <email@example.com> Cc: "peter linss" <firstname.lastname@example.org>, "Don Melton" <email@example.com> Subject: RE: do you own nsIWebshell now? Hi Steve, To answer your question, "maybe". :) What actually happened is Don asked me if I could take ownership of it, so in that respect yes, I am. My answer however was that because of my current workload, I was not sure I could do it for beta one. I told him I would look at the work involved to spec out better if it could happen for beta 1. After talking with Scott and others, it sounds like there is quite a bit to do it right and I don't think it can happen for beta 1. Scott did mention to me the improvements you mentioned. I have not gotten a detailed overview of the current webshell and requirements and list of problems. Which I would be more than happy to get more information from anyone who has it. Travis -----Original Message----- From: Steve Clark [mailto:firstname.lastname@example.org] Sent: Tuesday, September 07, 1999 8:49 AM To: Travis Bogard Cc: peter linss Subject: do you own nsIWebshell now? rumor has it you are the new owner of nsIWebshell. Peter L. and I had been working with Scott C. on major design improvements needed for webshell. These improvements are badly needed for gfx text controls, as well as for performance of framesets and iframes. I need to know if these improvements are actually going to get done before beta, and if not I need to devise an alternate plan for getting performance from gfx text controls. When Scott handed webshell to you, did he include any of the design for such improvements? They involve breaking webshell into 2 objects, a top-level webshell that is used to embed gecko and which includes all the heavyweight related services like session history; and a smaller lightweight subdoc shell used for embedding logically independent chunks in the topmost webshell, basically a wrapper for <a doc, a pres shell>. The key performance improvements are the small size of the subdoc shell, the ability to hand the subdoc shell a doc rather than forcing a URL load via necko, and the ability to hand the subdoc shell a pres context rather than having it fabricate its own. I'd love to talk to you about these things, assuming of course you really are the new owner. steve
Priority: P3 → P1
Summary: [BETA][FEATURE] nsIWebshell improvements → [BETA] nsIWebshell improvements
Whiteboard: Who owns nsIWebshell? Travis? He must decide ...
Target Milestone: M13
the second paragraph of my note pretty well covers it. 1) webshell needs to be split into 2 objects, a topmost webshell used for embedding gecko, and a lightweight 'docshell' used for embedding subdocs recursively in the webshell. The docshell will basically be a pres shell and a document. 2) the docshell must have an API for the caller to supply a document, rather than going through necko to load a URL 3) the docshell must have an API for the caller to supply a pres context, rather than creating one itself. 4) webshell currently spawns a window that sets itself up for drag and drop. for subdocs that don't want to support drag and drop, this is a tremendous waste of time. windows support being told whether they should enable drag and drop, but webshell doesn't expose this. the reasons for doing this are: 1) API rationalization. webshell is a total mess right now 2) performance (size). webshell is huge, and requires loading lots of services and allocating lots of memory for each shell. 3) performance(speed). webshell requires a trip through necko for loading about:blank which is very slow compared to simply constructing a tiny html document myself. webshell also imposes on me the need to re-resolve style for the entire document on load since it creates its own pres context. text controls and framesets will benefit enormously.
Whiteboard: Who owns nsIWebshell? Travis? He must decide ... → [Perf]Who owns nsIWebshell? Travis? He must decide ...
Putting on [Perf] radar.
Summary: [BETA] nsIWebshell improvements → [BETA][WebShell] nsIWebshell improvements
Putting Rick Potts on the cc list because I think he should take over this bug.
reassigning QA contact to Leger since this is a tracking bug
Assignee: don → travis
Severity: normal → critical
Whiteboard: [Perf]Who owns nsIWebshell? Travis? He must decide ...
Target Milestone: M13 → M11
seems like travis should own this now.
Summary: [BETA][WebShell] nsIWebshell improvements → [Dogfood][BETA][WebShell] nsIWebshell improvements
Added dogfood and PDT+ annotations. Lower level infrastructure needs to be landed ASAP to avoid late term destabilization. Thanks.
Summary: [Dogfood][BETA][WebShell] nsIWebshell improvements → [DOGFOOD][BETA][WebShell] nsIWebshell improvements
Whiteboard: [PDT+] → [PDT+] 12/17??? completion
Can we get this fully completed before 12/17?
Whiteboard: [PDT+] 12/17??? completion → [PDT+] 12/17 completion
Target Milestone: M12 → M13
Finalized date to 12/17 but move to M13.
Updating QA contact.
Removing PDT+ status because it's obvious we're not gonna hold up dogfood for this.
Putting on PDT- radar. spoke with don, enough of this is working at this time.
Updating the QA Contact.
Summary: [DOGFOOD][BETA][WebShell] nsIWebshell improvements → [FEATURE][WebShell] nsIWebshell improvements
Whiteboard: [PDT-]12/17 completion
Replace "DOGFOOD" and "BETA" with "FEATURE" in summary.
Removed dependency from bug #12659.
*** Bug 15056 has been marked as a duplicate of this bug. ***
Move to M14. Much has landed already, but keeping the bug around until we have everything done. We have individual bugs for features waiting on the full webshell landing. Those are being addressed as possible. As you can see from the dependency list, much are already getting fixed.
Hmmmm ... it didn't move to M14 for soe reason. Weird ...
Nominating as a "beta1" blocker.
We need latest status please!
Could we be more specific about the user impact of what's left to implement? The 3/10 date scares me. Removing PDT+ for reconsideration.
Whiteboard: [PDT+] 3/10 → 3/10
Putting on PDT- radar for beta1.
Whiteboard: 3/10 → [PDT-]3/10
Move this tracker to M15. (And I'm willing to move it to M16 too :-)
Target Milestone: M14 → M15
Move to M16 for now ...
Target Milestone: M15 → M16
This bug blocks bug 28142 as indicated by the comments there. Adding. Please correct me I shouldn't have.
M16 has been out for a while now, these bugs target milestones need to be updated.
Travis no longer works here. reassigning ownerless bugs to docshell owner, valeski for further triage.
Assignee: travis → valeski
Status: ASSIGNED → NEW
this blocks 5569, we need it for beta3...
closing out. not used.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Could you 'Verify' this tracking bug, if applicable? Thanks from QA...
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.