Gecko:Content Team Minutes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(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

Latest revision as of 17:57, 26 December 2005

Last week's actions:

  1. current team roster: bz, dbaron, jst, sicking
  2. who else should be included? bryner, peterv, mrbkap
  3. how should we track our work? wiki.mozilla.org
  4. laundry list construction

Laundry list:

  1. sicking: get XUL story in better shape, get somewhere with vector graphics.
    • brendan: beware w3c compound doc whim-wham, consider xul2 as consolidated namespace, keep eye on "rich client app" platform competitors. also, footprint, perf, web compatibility, etc.
  2. wyciwyg caching for javascript:
  3. document.open/write-after-close blows away state
  4. blazingly fast "Back" issues
    • can't just treat it like tab switching if onunload/onbeforeunload are missing, because of timers, blur handlers
  5. brendan, need help: E4X <-> DOM
  6. sicking: fix IndexOf quadratic growth
    • sicking: will filling only in IndexOf pay off (don't want to fill in ChildAt)?
    • bz: yes, for sibling following use-case
    • jst: get something in, instrument cache hits/misses
    • bz: fill for all kids (if above a threshold) on first IndexOf, keep "search rotor" to start from
  7. bz: extensibility story with XBL and XTF
    • security story for these extension mechanisms [1]
    • brendan: jst's patch to split content vs. chrome xpconnect scopes
    • scripting language neutrality
    • XTF API may be kept, but need common insertion point magic (see also [2])
    • bz: when is binding attached, detached -- poorly spec'ed
    • dbaron: avoiding CSS when expressing bindings will help that
    • bz: trying to attach before node is in doc breaks chrome
    • brendan: keep default for compat, convenience
    • bz: cloning XUL elements is exception: [https://bugzilla.mozilla.org/show_bug.cgi?id=53901 cloneNode attaches before node is in doc]
    • migration to XBL2 will help us clean up, but compatibility is king for
    • now we need to evaluate sXBL and XBL2 spec drafts
    • bryner is gonna implement the sXBL/XBL2 extensions for binding attachment etc.
    • bryner has a [https://bugzilla.mozilla.org/show_bug.cgi?id=283257 native-delegate interface for doing XBL impl. in C++ rather than JS]
    • bz: base tag and extends issue: namespace/tag assumes XUL common content data structure, doesn't work well with HTML, etc.
    • bryner: should we really keep XTF if XBL2 fixes everything?  probably not, but are there things XTF can do that XBL2 can't?
    • bz: class attribute in HTML and XForms counterexample: nsIStyledContent has methods to query these, but it's not scriptable. But native-delegate goodness should address this
    • bryner: another issue: binding to a namespaced attribute instead of an element
    • bz: can't remove bindings because it breaks QI identity/round-tripping; attribute bindings make this even more fun
    • bryner: XTF uses wrappers, maybe we could use those to handle removal; upon removal, the wrapper keeps on QI'ing to the missing interface, but its methods give back errors; could have perf probs though
    • bz: maybe distinguish removable bindings by saying they can't add interfaces?
    • bz: moving nodes from one doc to another issue: ownerDoc changes, what should happen?
    • brendan: we should ask Hixie
    • jst: if binding was attached by CSS, it should go away when node moves to other doc, else not necessarily
    • bz: need a new bug filed on this (update: filed
  8. dbaron: it's hard not to leak with our toolkit
    • brendan: maybe the ephemerality of XPConnect wrappers is the underlying bug?
    • bz: IE allows "expando" properties on DOM objects to persist
    • dbaron: can find strong component root by walking up parent chain
    • bz: but not for anonymous content
    • dbaron: script-reachable a.c. or not?
    • bz: not yet, but maybe
    • dbaron: sXBL and XBL2 fix this
  9. bz: native anonymous content:
    • breaks some bindings, not scriptable
    • what's the ordering w.r.t. regular anonymous content
    • bz: I need a more complete list, and do we need a tracking bug?
  10. better security model for XUL and XBL, broadly construed
    • brendan: work at higher level (data tainting?) with Coverity et al.
    • see Andrew Meyer's JIF?
  11. bz: display:none shouldn't tear down iframe content
    • so we need to move docshell ownership into XBL
    • sicking: or rewrite in C++
    • brendan: don't rewrite in C++ if there's a better security model that's language-neutral and within our reach
    • dbaron: could help dynamic theme switching if we change horses, approaches
    • two issues, really: XUL and HTML; HTML iframe still loses content when removed from doc
  12. jst: plugins should be owned by content nodes, not frames
  13. sicking: 4% Tp win if we improve the mutation event implementation; more to do with mutation events, for code cleanup as well as perf.
  14. brendan: are there high-level design changes to improve perf, not seen by profilers?
    • jst: batching of HTML content notifications is a mess, could be wins
    • bz: refactor to share with XML sink? initially just making XML increment
    • clean up event loop scheduling hacks
    • dbaron: content sink is batching stuff up, parser is breaking things up; if content sink is "taking too long" -> conflict
    • brendan: timers (bz: resolution bug due to condvar notify impl) come up
    • sicking: we're reflowing while loading too much, maybe to make offsetTop etc. valid? KTHML better?
    • bz: reflows are flushed by offsetTop getter
    • paint suppression is yet another hack to consider in global sense
  15. bz: document object setup and ownership (content viewer, docshell, etc.) are hard to diagram
    • brendan: draw "anatomical sections" or partial overlays
    • dbaron, everyone: too many objects, period
    • bz: we have two separate ways to own docshells: embeddings vs. non-embedding XUL; we should unify toward embedding APIs (nsIWebBrowser)
    • jst: eliminate internal methods that duplicate embedding API
  16. bz: should we post wiki references to the m.dom etc. newsgroups?  group: Yes
  17. jst: right before Firefox 1.0, we were fighting synthetic event bugs that got handled by chrome handlers; we could ignore those that aren't trusted events.
    • this breaks if we synthesize events that should be trusted but are not marked "trusted", because some C++ uses the untrusted DOM event APIs.
    • Need a use-case.
  18. bz: event dispatch issues: two different methods on pres-shell to dispatch, one to content, one to content and to frames.
    • Latter used from widget and view manager event sources, but content events could have coordinates too.
    • This means you can't change the selection from a DOM event, because it doesn't dispatch to frames.
    • The method that does dispatch to frames fails to dispatch at all (to content) if there are no frames.
  19. bryner, bz: dangling pointer to on-stack nsEvent bug
    • bryner, bz, hyatt: let's get rid of nsEvent stack allocation and all, and just move logic into DOM event classes.
    • bryner: some events have opaque pointers to native data not valid after unwinding; need a method to null them out before unwinding
    • sicking, bryner: [https://bugzilla.mozilla.org/show_bug.cgi?id=234455 centralize the DOM event logic nested under HandleDOMEvent]. Probably need pre-capture and other observation points
    • bz: need some interface other than nsIDOMEvent, so let's have a deCOMtaminated nsIPrivateDOMEvent (we have one already, jst said).  Always use the private one internally, QI for external consumption.
  20. Wiki URL: http://wiki.mozilla.org/wiki/Gecko:Content_Team_Minutes
  21. Splitting the window object into inner and outer objects: Gecko:SplitWindow

/be

Retrieved from "https://wiki.mozilla.org/index.php?title=Gecko:Content_Team_Minutes&oldid=19819"