MozillaWiki

Gecko:Content Team Minutes: Difference between revisions

Gecko Discussion

Gecko:Content Team Minutes (view source)

Revision as of 03:38, 4 March 2005

12 bytes removed ,  4 March 2005
no edit summary
No edit summary
No edit summary
Line 16: Line 16:
competitors. also, footprint, perf, web compatibility, etc.</li>
competitors. also, footprint, perf, web compatibility, etc.</li>
   </ul>
   </ul>
   <li>wyciwyg caching for javascript:
   <li>[https://bugzilla.mozilla.org/show_bug.cgi?id=206531 wyciwyg caching for javascript:]
[https://bugzilla.mozilla.org/show_bug.cgi?id=206531]
   </li>
   </li>
   <li>document.open/write-after-close blows away state
   <li>[https://bugzilla.mozilla.org/show_bug.cgi?id=114461 document.open/write-after-close blows away state]
(https://bugzilla.mozilla.org/show_bug.cgi?id=114461)
   </li>
   </li>
   <li>blazingly fast "Back" issues
   <li>[https://bugzilla.mozilla.org/show_bug.cgi?id=274784 blazingly fast "Back" issues]
(https://bugzilla.mozilla.org/show_bug.cgi?id=274784)
   </li>
   </li>
   <ul>
   <ul>
Line 30: Line 27:
     <li>are missing, because of timers, blur handlers</li>
     <li>are missing, because of timers, blur handlers</li>
   </ul>
   </ul>
   <li>brendan, need help: E4X <-> DOM
   <li>brendan, need help: [https://bugzilla.mozilla.org/show_bug.cgi?id=270553 E4X <-> DOM]
(https://bugzilla.mozilla.org/show_bug.cgi?id=270553)</li>
</li>
   <li>sicking: fix IndexOf quadratic growth
   <li>sicking: [https://bugzilla.mozilla.org/show_bug.cgi?id=240884 fix IndexOf quadratic growth]</li>
(https://bugzilla.mozilla.org/show_bug.cgi?id=240884)</li>
   <ul>
   <ul>
     <li>sicking: will filling only in IndexOf pay off (don't want to
     <li>sicking: will filling only in IndexOf pay off (don't want to
Line 53: Line 49:
     <li>bz: when is binding attached, detached -- poorly spec'ed</li>
     <li>bz: when is binding attached, detached -- poorly spec'ed</li>
     <li>dbaron: avoiding CSS when expressing bindings will help that</li>
     <li>dbaron: avoiding CSS when expressing bindings will help that</li>
     <li>bz: trying to attach before node is in doc breaks chrome (https://bugzilla.mozilla.org/show_bug.cgi?id=265086)</li>
     <li>bz: [https://bugzilla.mozilla.org/show_bug.cgi?id=265086 trying to attach before node is in doc breaks chrome]</li>
     <li>brendan: keep default for compat, convenience</li>
     <li>brendan: keep default for compat, convenience</li>
     <li>bz: cloning XUL elements is exception: cloneNode attaches
     <li>bz: cloning XUL elements is exception: [https://bugzilla.mozilla.org/show_bug.cgi?id=53901 cloneNode attaches
before node is in doc (https://bugzilla.mozilla.org/show_bug.cgi?id=53901)</li>
before node is in doc]</li>
     <li>migration to XBL2 will help us clean up, but compatibility is
     <li>migration to XBL2 will help us clean up, but compatibility is
king for</li>
king for</li>
     <li>now we need to evaluate sXBL (http://www.w3.org/TR/sXBL/)
     <li>now we need to evaluate [http://www.w3.org/TR/sXBL/ sXBL]
and XBL2 (http://www.hixie.ch/specs/xbl/XBL2.html spec drafts</li>
and [http://www.hixie.ch/specs/xbl/XBL2.html XBL2] spec drafts</li>
     <li>bryner is gonna implement the sXBL/XBL2 extensions for binding
     <li>bryner is gonna implement the sXBL/XBL2 extensions for binding
attachment etc.</li>
attachment etc.</li>
Line 68: Line 64:
common content data structure, doesn't work well with HTML, etc.</li>
common content data structure, doesn't work well with HTML, etc.</li>
     <li>bryner: should we really keep XTF if XBL2 fixes everything?&nbsp;
     <li>bryner: should we really keep XTF if XBL2 fixes everything?&nbsp;
probably not, but are there things XTF (http://www.croczilla.com/xtf) can do  
probably not, but are there things [http://www.croczilla.com/xtf XTF]  can do  
that XBL2 (http://www.hixie.ch/specs/xbl/XBL2.html) can't?</li>
that [http://www.hixie.ch/specs/xbl/XBL2.html XBL2] can't?</li>
     <li>bz: class attribute in HTML and XForms counterexample:
     <li>bz: class attribute in HTML and XForms counterexample:
nsIStyledContent has methods to query these, but it's not scriptable.
nsIStyledContent has methods to query these, but it's not scriptable.
Line 88: Line 84:
     <li>jst: if binding was attached by CSS, it should go away when
     <li>jst: if binding was attached by CSS, it should go away when
node moves to other doc, else not necessarily</li>
node moves to other doc, else not necessarily</li>
     <li>bz: need a new bug filed on this [update: filed (https://bugzilla.mozilla.org/show_bug.cgi?id=284707)]<br>
     <li>bz: need a new bug filed on this (update: [https://bugzilla.mozilla.org/show_bug.cgi?id=284707 filed]<br>
     </li>
     </li>
   </ul>
   </ul>
   <li>dbaron: it's hard not to leak with our toolkit (see
   <li>dbaron: [https://bugzilla.mozilla.org/show_bug.cgi?id=283129 it's hard not to leak with our toolkit]</li>
    https://bugzilla.mozilla.org/show_bug.cgi?id=283129)</li>
   <ul>
   <ul>
     <li>brendan: maybe the ephemerality of XPConnect wrappers is the
     <li>brendan: maybe the ephemerality of XPConnect wrappers is the
Line 131: Line 126:
   </ul>
   </ul>
   <li>jst: plugins should be owned by content nodes, not frames</li>
   <li>jst: plugins should be owned by content nodes, not frames</li>
   <li>sicking: 4% Tp win if we improve the mutation event
   <li>sicking: [https://bugzilla.mozilla.org/show_bug.cgi?id=231676 4% Tp win if we improve the mutation event implementation];
implementation (https://bugzilla.mozilla.org/show_bug.cgi?id=231676);
more to do with mutation events, for code cleanup as well as perf.</li>
more to do with mutation events, for code cleanup as well as perf.</li>
   <li>brendan: are there high-level design changes to improve perf,
   <li>brendan: are there high-level design changes to improve perf,
Line 143: Line 137:
     <li>dbaron: content sink is batching stuff up, parser is breaking
     <li>dbaron: content sink is batching stuff up, parser is breaking
things up; if content sink is "taking too long" -> conflict</li>
things up; if content sink is "taking too long" -> conflict</li>
     <li>brendan: timers (bz: resolution bug due to condvar notify impl)
     <li>brendan: timers (bz: [https://bugzilla.mozilla.org/show_bug.cgi?id=257454 resolution bug due to condvar notify impl]) come up</li>
come up (https://bugzilla.mozilla.org/show_bug.cgi?id=257454)</li>
     <li>sicking: we're reflowing while loading too much, maybe to make
     <li>sicking: we're reflowing while loading too much, maybe to make
offsetTop etc. valid? KTHML better?</li>
offsetTop etc. valid? KTHML better?</li>
Line 192: Line 185:
     <li>bryner: some events have opaque pointers to native data not
     <li>bryner: some events have opaque pointers to native data not
valid after unwinding; need a method to null them out before unwinding</li>
valid after unwinding; need a method to null them out before unwinding</li>
     <li>sicking, bryner: centralize the DOM event logic nested under
     <li>sicking, bryner: [https://bugzilla.mozilla.org/show_bug.cgi?id=234455 centralize the DOM event logic nested under
HandleDOMEvent.&nbsp; Probably need pre-capture and other observation points (https://bugzilla.mozilla.org/show_bug.cgi?id=234455)</li>
HandleDOMEvent]. Probably need pre-capture and other observation points</li>
     <li>bz: need some interface other than nsIDOMEvent, so let's have a
     <li>bz: need some interface other than nsIDOMEvent, so let's have a
deCOMtaminated nsIPrivateDOMEvent (we have one already, jst said).&nbsp;
deCOMtaminated nsIPrivateDOMEvent (we have one already, jst said).&nbsp;
Bzbarsky
308

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/3492"