MozillaWiki

Gecko:Content Team Minutes: Difference between revisions

Gecko Discussion

Gecko:Content Team Minutes (view source)

Revision as of 17:57, 26 December 2005

698 bytes added ,  26 December 2005
no edit summary
(Minutes for 2005-Mar-03 meeting)
No edit summary
 
(8 intermediate revisions by 3 users not shown)
Line 10: Line 10:
<ol>
<ol>
   <li>sicking: get XUL story in better shape, get somewhere with vector
   <li>sicking: get XUL story in better shape, get somewhere with vector
graphics.</li>
graphics.
   <ul>
   <ul>
     <li>brendan: beware w3c compound doc whim-wham, consider xul2 as
     <li>brendan: beware w3c compound doc whim-wham, consider xul2 as
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:
(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=206531 wyciwyg caching for javascript:]
(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=114461 document.open/write-after-close blows away state]
(https://bugzilla.mozilla.org/show_bug.cgi?id=274784)
   </li>
   </li>
  <li>[https://bugzilla.mozilla.org/show_bug.cgi?id=274784 blazingly fast "Back" issues]
   <ul>
   <ul>
     <li>can't just treat it like tab switching if
     <li>can't just treat it like tab switching if
onunload/onbeforeunload</li>
onunload/onbeforeunload 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>
(https://bugzilla.mozilla.org/show_bug.cgi?id=270553)</li>
   <li>brendan, need help: [https://bugzilla.mozilla.org/show_bug.cgi?id=270553 E4X <-> DOM]
   <li>sicking: fix IndexOf quadratic growth
</li>
(https://bugzilla.mozilla.org/show_bug.cgi?id=240884)</li>
   <li>sicking: [https://bugzilla.mozilla.org/show_bug.cgi?id=240884 fix IndexOf quadratic growth]
   <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
fill in ChildAt)?</li>
fill in ChildAt)?</li>
     <li>bz: yes, for sibling following use-case</li>
     <li>bz: yes, for sibling following use-case</li>
     <li>jst: get something in, instrument cache hits/misses<br>
     <li>jst: get something in, instrument cache hits/misses</li>
    </li>
     <li>bz: fill for all kids (if above a threshold) on first IndexOf,
     <li>bz: fill for all kids (if above a threshold) on first IndexOf,
keep "search rotor" to start from<br>
keep "search rotor" to start from<br>
     </li>
     </li>
   </ul>
   </ul>
   <li>bz: extensibility story with XBL and XTF</li>
  </li>
   <li>bz: extensibility story with XBL and XTF
   <ul>
   <ul>
     <li>security story for these extension mechanisms</li>
     <li>security story for these extension mechanisms [https://bugzilla.mozilla.org/show_bug.cgi?id=236839]</li>
     <li>brendan: jst's patch to split content vs. chrome xpconnect
     <li>brendan: jst's patch to split content vs. chrome xpconnect
scopes</li>
scopes</li>
     <li>scripting language neutrality</li>
     <li>scripting language neutrality</li>
     <li>XTF API may be kept, but need common insertion point magic</li>
     <li>XTF API may be kept, but need common insertion point magic (see also [https://bugzilla.mozilla.org/show_bug.cgi?id=307394])</li>
     <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</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</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>
     <li>bryner has a native-delegate interface for doing XBL impl. in
     <li>bryner has a [https://bugzilla.mozilla.org/show_bug.cgi?id=283257 native-delegate interface for doing XBL impl. in
C++ rather than JS</li>
C++ rather than JS]</li>
     <li>bz: base tag and extends issue: namespace/tag assumes XUL
     <li>bz: base tag and extends issue: namespace/tag assumes XUL
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 <b>[file it]</b><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>
    https://bugzilla.mozilla.org/show_bug.cgi?id=283129)</li>
   <li>dbaron: [https://bugzilla.mozilla.org/show_bug.cgi?id=283129 it's hard not to leak with our toolkit]
   <ul>
   <ul>
     <li>brendan: maybe the ephemerality of XPConnect wrappers is the
     <li>brendan: maybe the ephemerality of XPConnect wrappers is the
Line 104: Line 100:
     <li>dbaron: sXBL and XBL2 fix this</li>
     <li>dbaron: sXBL and XBL2 fix this</li>
   </ul>
   </ul>
   <li>bz: native anonymous content:</li>
  </li>
   <li>bz: native anonymous content:
   <ul>
   <ul>
     <li>breaks some bindings, not scriptable</li>
     <li>breaks some bindings, not scriptable</li>
Line 111: Line 108:
     </li>
     </li>
   </ul>
   </ul>
   <li>better security model for XUL and XBL, broadly construed</li>
  </li>
   <li>better security model for XUL and XBL, broadly construed
   <ul>
   <ul>
     <li>brendan: work at higher level (data tainting?) with Coverity et
     <li>brendan: work at higher level (data tainting?) with Coverity et
Line 117: Line 115:
     <li>see Andrew Meyer's JIF?</li>
     <li>see Andrew Meyer's JIF?</li>
   </ul>
   </ul>
   <li>bz: display:none shouldn't tear down iframe content</li>
  </li>
   <li>bz: display:none shouldn't tear down iframe content
   <ul>
   <ul>
     <li>so we need to move docshell ownership into XBL</li>
     <li>so we need to move docshell ownership into XBL</li>
Line 130: Line 129:
     </li>
     </li>
   </ul>
   </ul>
   <li>jst: plugins should be owned by content nodes, not frames</li>
  </li>
   <li>sicking: 4% Tp win if we improve the mutation event
   <li>jst: plugins should be owned by content nodes, not frames
implementation (https://bugzilla.mozilla.org/show_bug.cgi?id=231676);
    <ul>
      <li>dbaron: ...and make nsObjectFrame not do all the dispatching.  See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1156#c4">bug 1156</a></li>
    </ul>
  </li>
   <li>sicking: [https://bugzilla.mozilla.org/show_bug.cgi?id=231676 4% Tp win if we improve the mutation event implementation];
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,
not seen by profilers?</li>
not seen by profilers?
   <ul>
   <ul>
     <li>jst: batching of HTML content notifications is a mess, could be
     <li>jst: batching of HTML content notifications is a mess, could be
wins</li>
wins</li>
     <li>bz: refactor to share with XML sink? initially just making XML</li>
     <li>bz: refactor to share with XML sink? initially just making XML increment
     <li>incremental clean up event loop scheduling hacks</li>
     <li>clean up event loop scheduling hacks</li>
     <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</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 151: Line 153:
sense</li>
sense</li>
   </ul>
   </ul>
  </li>
   <li>bz: document object setup and ownership (content viewer,
   <li>bz: document object setup and ownership (content viewer,
docshell, etc.)
docshell, etc.)
are hard to diagram</li>
are hard to diagram
   <ul>
   <ul>
     <li>brendan: draw "anatomical sections" or partial overlays</li>
     <li>brendan: draw "anatomical sections" or partial overlays</li>
Line 162: Line 165:
     </li>
     </li>
   </ul>
   </ul>
  </li>
   <li>bz: should we post wiki references to the m.dom etc. newsgroups?&nbsp;
   <li>bz: should we post wiki references to the m.dom etc. newsgroups?&nbsp;
group: Yes</li>
group: Yes</li>
   <li>jst: right before Firefox 1.0, we were fighting synthetic event
   <li>jst: right before Firefox 1.0, we were fighting synthetic event
bugs that got handled by chrome handlers; we could ignore those that
bugs that got handled by chrome handlers; we could ignore those that
aren't trusted events.</li>
aren't trusted events.
   <ul>
   <ul>
     <li>this breaks if we synthesize events that should be trusted but
     <li>this breaks if we synthesize events that should be trusted but
Line 173: Line 177:
     <li>Need a use-case.</li>
     <li>Need a use-case.</li>
   </ul>
   </ul>
  </li>
   <li>bz: event dispatch issues: two different methods on pres-shell to
   <li>bz: event dispatch issues: two different methods on pres-shell to
dispatch, one to content, one to content and to frames.</li>
dispatch, one to content, one to content and to frames.
   <ul>
   <ul>
     <li>Latter used from widget and view manager event sources, but
     <li>Latter used from widget and view manager event sources, but
Line 185: Line 190:
all (to content) if there are no frames.</li>
all (to content) if there are no frames.</li>
   </ul>
   </ul>
   <li>bryner, bz: dangling pointer to on-stack nsEvent bug</li>
  </li>
   <li>bryner, bz: dangling pointer to on-stack nsEvent bug
   <ul>
   <ul>
     <li>bryner, bz, hyatt: let's get rid of nsEvent stack allocation
     <li>bryner, bz, hyatt: let's get rid of nsEvent stack allocation
and all, and just move logic into DOM event classes.<br>
and all, and just move logic into DOM event classes.</li>
    </li>
     <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</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;
Line 199: Line 204:
     </li>
     </li>
   </ul>
   </ul>
  </li>
   <li>Wiki URL: http://wiki.mozilla.org/wiki/Gecko:Content_Team_Minutes</li>
   <li>Wiki URL: http://wiki.mozilla.org/wiki/Gecko:Content_Team_Minutes</li>
  <li>Splitting the window object into inner and outer objects: [[Gecko:SplitWindow]]</li>


</ol>
</ol>
/be
/be
Bzbarsky
308

edits

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