MozillaWiki - User contributions [en]

Platform/2008-08-27

2008-08-28T05:43:13Z

Taken: correct navigation

<small>[[Platform/2008-08-20|« previous week]] | [[Platform|index]] | [[Platform/2008-09-03|next week »]]</small>

=== Details ===
* Wednesdays - 11:00am Pacific, 2:00pm Eastern, 19:00 UTC
* Mozilla Building S - <script> conference room
* 650-903-0800 or 650-215-1282 x91 Conf# 8605 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 8605 (US)
* irc.mozilla.org #shiretoko for backchannel

=== Notices ===
* 1.9.1 Beta 1 Freeze Tuesday, Sep 9 @11:59PM PDT.
* Please take a look at the feature list and get things missing added, and update status for things you own: [[Firefox3.1/Features#Gecko_1.9.1]]

=== GFX 1.9.1 Update ===
* [http://tinyurl.com/5xfmvp GFX blocking 1.9.1+]
* [http://tinyurl.com/4zv2kn GFX wanted 1.9.1+]
* Performance:
** Color management perf landed. Not turned on for A2 because of a bunch of reftest failures. After a few days on it it appears that all but one or two issues are problems with the reftests, not the code. Patches in progress for all the issues (about 7 total).
* Downloadable fonts (jdaggett)
** Updated patch to do same-site origin checking of fonts
** Done at parse time, but probably need to do at load time to allow for access-control and redirects

=== Layout 1.9.1 Update ===
* [http://tinyurl.com/6zjp33 1.9.1 Layout Bugs]
* Video (roc/cdouble):
* Acid3:
* SMIL (dholbert):
** Not much new (OOTO for most of past week)
** Posting updated patch in next day or two
* SVG fonts - karlt: won't be in 1.9.1
* SVG CSS, roc:
* media queries (dbaron):
* CSS transforms - keith:

=== Content 1.9.1 Update ===
* [http://tinyurl.com/5a8vc2 Content 1.9.1 Bugs]
* Worker Threads:
** Script loading mostly done, needs reviews.
** XHR and JSON last major features.
** Need to catch up with the spec work, nothing really major.
* Cross-site XHR:
** Jonas has a good bit of this already done, needs finalized and reviewed.
* XHR Upload and download progress events - landed. Followups ([https://bugzilla.mozilla.org/show_bug.cgi?id=451991 451991], [https://bugzilla.mozilla.org/show_bug.cgi?id=444546 444546], [https://bugzilla.mozilla.org/show_bug.cgi?id=445225 445225]) have patches.

=== JS 1.9.1 ===
*[http://tinyurl.com/5gmg8y JS 1.9.1 Bugs]
''Last week'':
* JS Tracing:
** Last week's status:
*** going to land in m-c pref'd off
** This Week's Status:
*** https://wiki.mozilla.org/JavaScript:TraceMonkey
*** Chasing regressions

{|
|-
| <b>Blocking</b>
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=417131 417131] || igor@mir2.org || FIXED || JS Enumeration Allocation Consternation
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=421864 421864] || igor@mir2.org || review_brendan? || Interpreter creates too many doubles
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=433337 433337] || igor@mir2.org || FIXED || Reunify jsinterp.c on Windows
|-
|
|-
| <b>Wanted</b>
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=229756 229756] || graydon@mozilla.com || || Make SpiderMonkey's const extension JS2/ES4 compatible
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=445262 445262] || brendan@mozilla.org || || display closure optimizations for SpiderMonkey
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=260106 260106] || brendan@mozilla.org || wip-patch || elisions in array literals should not create properties (js1_5/Array/11.1.4.js)
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=312354 312354] || brendan@mozilla.org || FIXED || Assignment expressions have wrong type (ecma_3/Operators/11.13.1-002.js)
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=363534 363534] || brendan@mozilla.org || FIXED || Combine JSOP_LT and JSOP_IFEQ, etc., pairs
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=445893 445893] || brendan@mozilla.org || FIXED || Use the property cache for JSOP_NAMEINC, etc.
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=384244 384244] || crowder@fiverocks.com || FIXED || update jsdtoa with interesting pieces of more-recent dtoa
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=440473 440473] || crowder@fiverocks.com || FIXED || crash [@ Decompile][@ js_GetSrcNoteOffset] with firebug/jQuery
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=433351 433351] || crowder@fiverocks.com || review_mrbkap? || Implement Object.extend
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=442379 442379] || dmandelin@mozilla.com || wip-patch || try inline-threading, at least with GCC if not MSVC
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=305064 305064] || mike.kaplinskiy@gmail.com || checkin_needed || Add trim, ltrim, and rtrim features for javascript strings
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=352437 352437] || general@js.bugs || || string.link does not escape url
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=429507 429507] || general@js.bugs || || Function.prototype.bind
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=433336 433336] || graydon@mozilla.com || review_shaver? || array iteration optimization
|
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=411575 411575] || igor@mir2.org || FIXED || js_PutCallObject() is slow.
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=432881 432881] || igor@mir2.org || FIXED || SM: JSVAL_VOID as a pseudo-boolean
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=443746 443746] || igor@mir2.org || FIXED || Optimizing the enumeration state allocation
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=346749 346749] || mrbkap@gmail.com || FIXED || let declarations at top level are turned into var declarations
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=442358 442358] || mrbkap@gmail.com || FIXED || jsinterp control flow doesn't flow as specified
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=444787 444787] || mrbkap@gmail.com || FIXED || Object.getPrototypeOf
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=312116 312116] || nobody@mozilla.org || || should support catchall getters/setters
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=445178 445178] || rubys@intertwingly.net || || Decimal Support
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=419225 419225] || sayrer@gmail.com || wip-patch || refactor ExecuteREBytecode and SimpleMatch
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=430930 430930] || sayrer@gmail.com || || Date.parse cannot even parse "2008-04-26" (should understand ISO 8601)
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=419743 419743] || shaver@mozilla.org || wip-patch || JSOP_CONCATN for improved chained-concat performance
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=433335 433335] || shaver@mozilla.org || || mark sharp object avoidance
|}

=== Mobile 1.9.1 Update ===
* We now statically link jemalloc to xulrunner-stub {{bug|451193}}
* setting up mobile builds on a staging slave. Curious can follow along in {{bug|430200}}
* Need help with:
** Need a way to get paint notifications from a hidden browser window {{bug|450930}}
** Various graphics performance issues {{bug|451621}} {{bug|450400}} {{bug|450916}}
** Various focus issues {{bug|406837}} {{bug|441582}} {{bug|435446}}
** Working on better handling of low memory situations

* Expose Video / Camera {{ bug | 451674}}
* Geolocation. Updated to latest draft spec. Couple issues.

=== General 1.9.1 Updates ===
* offline cache, dcamp: {{bug|442806}} landed, {{bug|442812}} landing today, still working on {{bug|442813}}.
* localStorage, honzab:
* HTML5 drag-drop

=== Security ===
* Tracemonkey code walkthrough scheduling
* Core Security Bugs:
** {{bug|422283}}last touched in April

==== Security Reviews ====

See [[Firefox3.1/Security|the security review schedule]] page to get your review scheduled ASAP!
* Did the earlier reviews happen?
* Can there be a column on this page to indicate when the review is completed?

=== Roundtable ===

== mozilla-central ==

Platform/2008-08-20

2008-08-28T05:42:21Z

Taken: correct navigation

<small>[[Platform/2008-08-13|« previous week]] | [[Platform|index]] | [[Platform/2008-08-27|next week »]]</small>

=== Details ===

* Wednesdays - 11:00am Pacific, 2:00pm Eastern, 19:00 UTC
* Mozilla Building S - <script> conference room
* 650-903-0800 or 650-215-1282 x91 Conf# 8605 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 8605 (US)
* irc.mozilla.org #shiretoko for backchannel

=== Notices ===

* 1.9.1 Beta 1 Freeze Tuesday, Sep 9 @11:59PM PDT.
* Please take a look at the feature list and get things missing added, and update status for things you own: [[Firefox3.1/Features#Gecko_1.9.1]]

=== GFX 1.9.1 Update ===
* [http://tinyurl.com/5xfmvp GFX blocking 1.9.1+]
* [http://tinyurl.com/4zv2kn GFX wanted 1.9.1+]
* Performance:
** imglib caching improvements bounced (small lk, oops)
** CMS perf landed! ... But not turned on due to test failures. Our reftests in particular are colour-sensitive, still investigating.
* Downloadable fonts
** roc feels we should add a same-site origin restriction on downloadable fonts

=== Layout 1.9.1 Update ===
* [http://tinyurl.com/6zjp33 1.9.1 Layout Bugs]
* Video (roc/cdouble):
* Acid3: Roc or dbaron, status?
* SMIL (dholbert):
** Fixed some bugs to allow better & faster reftesting, & added a bunch of new reftests
** Fixed a bug that made acid3 test #76 fail occasionally with old patches. (There was a race condition between a short setTimeout in the test vs. the time before we take next frame of animation). Now it should always pass.
* SVG fonts - karlt: won't be in 1.9.1
* SVG CSS, roc:
* media queries (dbaron):
* CSS transforms - keith: under review (roc + dbaron)

=== Content 1.9.1 Update ===
* [http://tinyurl.com/5a8vc2 Content 1.9.1 Bugs]
''Last week'':
* Worker Threads:
* Cross-site XHR:
* XHR Upload and download progress events?
* Java/OJI bug:

=== JS 1.9.1 ===
*[http://tinyurl.com/5gmg8y JS 1.9.1 Bugs]
''Last week'':
* JS Tracing:
** Last week's status:
*** chasing bugs in [https://bugzilla.mozilla.org/show_bug.cgi?id=449436 449436]
*** very few regressions vs. interpreter left, some big wins
*** nested loop tracing / recursive function calls biggest performace problem near term
** This Week's Status:
*** going to land in m-c pref'd off

{|
|-
| <b>Blocking</b>
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=417131 417131] || igor@mir2.org || FIXED || JS Enumeration Allocation Consternation
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=421864 421864] || igor@mir2.org || review_brendan? || Interpreter creates too many doubles
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=433337 433337] || igor@mir2.org || FIXED || Reunify jsinterp.c on Windows
|-
|
|-
| <b>Wanted</b>
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=229756 229756] || graydon@mozilla.com || || Make SpiderMonkey's const extension JS2/ES4 compatible
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=445262 445262] || brendan@mozilla.org || || display closure optimizations for SpiderMonkey
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=260106 260106] || brendan@mozilla.org || wip-patch || elisions in array literals should not create properties (js1_5/Array/11.1.4.js)
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=312354 312354] || brendan@mozilla.org || FIXED || Assignment expressions have wrong type (ecma_3/Operators/11.13.1-002.js)
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=363534 363534] || brendan@mozilla.org || FIXED || Combine JSOP_LT and JSOP_IFEQ, etc., pairs
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=445893 445893] || brendan@mozilla.org || FIXED || Use the property cache for JSOP_NAMEINC, etc.
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=384244 384244] || crowder@fiverocks.com || FIXED || update jsdtoa with interesting pieces of more-recent dtoa
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=440473 440473] || crowder@fiverocks.com || FIXED || crash [@ Decompile][@ js_GetSrcNoteOffset] with firebug/jQuery
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=433351 433351] || crowder@fiverocks.com || review_mrbkap? || Implement Object.extend
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=442379 442379] || dmandelin@mozilla.com || wip-patch || try inline-threading, at least with GCC if not MSVC
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=305064 305064] || mike.kaplinskiy@gmail.com || checkin_needed || Add trim, ltrim, and rtrim features for javascript strings
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=352437 352437] || general@js.bugs || || string.link does not escape url
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=429507 429507] || general@js.bugs || || Function.prototype.bind
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=433336 433336] || graydon@mozilla.com || review_shaver? || array iteration optimization
|
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=411575 411575] || igor@mir2.org || FIXED || js_PutCallObject() is slow.
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=432881 432881] || igor@mir2.org || FIXED || SM: JSVAL_VOID as a pseudo-boolean
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=443746 443746] || igor@mir2.org || FIXED || Optimizing the enumeration state allocation
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=346749 346749] || mrbkap@gmail.com || FIXED || let declarations at top level are turned into var declarations
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=442358 442358] || mrbkap@gmail.com || FIXED || jsinterp control flow doesn't flow as specified
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=444787 444787] || mrbkap@gmail.com || FIXED || Object.getPrototypeOf
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=312116 312116] || nobody@mozilla.org || || should support catchall getters/setters
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=445178 445178] || rubys@intertwingly.net || || Decimal Support
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=419225 419225] || sayrer@gmail.com || wip-patch || refactor ExecuteREBytecode and SimpleMatch
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=430930 430930] || sayrer@gmail.com || || Date.parse cannot even parse "2008-04-26" (should understand ISO 8601)
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=419743 419743] || shaver@mozilla.org || wip-patch || JSOP_CONCATN for improved chained-concat performance
|-
|[https://bugzilla.mozilla.org/show_bug.cgi?id=433335 433335] || shaver@mozilla.org || || mark sharp object avoidance
|}

=== Mobile 1.9.1 Update ===
* setting up mobile builds on a staging slave. Curious can follow along in {{bug|430200}}

=== General 1.9.1 Updates ===
* offline cache, dcamp: Got first round of reviews last week, working through review comments this week.
* localStorage, honzab:
* HTML5 drag-drop

=== Security ===
* Security reviews! Two scheduled today, are they happening?
* Tracemonkey code walkthrough scheduling
* Core Security Bugs:
** {{bug|422283}}last touched in April

==== Security Reviews ====

See [[Firefox3.1/Security|the security review schedule]] page to get your review scheduled ASAP!
* Did the earlier reviews happen?
* Can there be a column on this page to indicate when the review is completed?

=== Roundtable ===
* {{bug|451264}} -- How can I (ctalbert) determine what it is about setPageMode that is causing this issue? Does anyone happen to know off the top of their head? This is blocking our testing for downloadable fonts and print selection.

== mozilla-central ==

Platform/Post1.9Planning

2008-04-26T07:58:56Z

Taken: added category, bug template

A rough list of what people would like to work on in the next 3-6 months. Please add descriptions, bug numbers, links to wiki pages, etc.
{| class="fullwidth-table"
| style="background:#efefef" | '''Name'''
| style="background:#efefef" | '''1.9.0.x'''
| style="background:#efefef" | '''1.9.next'''
| style="background:#efefef" | '''Moz2'''
|-
| Johnny Stenback
|-
| Jonas Sicking
|-
| Peter Van der Beken
|-
| Blake Kaplan
|-
| Ben Turner
|-
| Stan Shebs
|-
| Vladimir Vukicevic
|-
| Stuart Parmenter
|-
| John Daggett
|-
| Joe Drew
|-
| David Baron
|-
| Robert O'Callahan
|
| Some small SVG filter performance improvements
| Compositor
|-
| Boris Zbarsky
|-
| Daniel Holbert
|-
| Karl Tomlinson
|
| SVG fonts
|-
| Matthew Gregan
|
| Quicktime backend for <video>/<audio>
|-
| Igor Bukanov
|-
| Brian Crowder
|-
| Graydon Hoare
|-
| Jason Orendorff
|-
| Taras Glek
|-
| Dave Mandelin
|
| Strip obsolete OOM code ({{bug|427115}})
| Treehydra ({{bug|423898}})/Moz2 Analyses ({{bug|430328}})
|-
| Benjamin Smedberg
|
|
| XPCOMGC
|-
| Jim Blandy
|-
| Josh Aas
|-
| Stephen Michaud
|-
| Simon Montagu
|-
| Robert Sayre
|-
| Ted Mielczarek
|-
| Dave Camp
|-
| Chris Pearce
|
| DirectShow backend for <video>/<audio>
| Editor refactoring
|-
| Chris Double
|
| <video>/<audio>
|-
| Zachary Weinberg
|-
|}
[[Category:Mozilla 2]]

Gfx glue layer removal

2008-04-24T09:25:41Z

Taken: s/Cairo/cairo/, added Category:Mozilla 2

== Goal ==

* Eliminate the glue layer in <tt>gfx/src/thebes</tt>
* All code calls <tt>gfx/thebes</tt> interfaces directly
** mostly this is <tt>nsIFrame::Paint</tt> methods, but there are others
* Not possible to implement a non-cairo rendering backend anymore
** I believe this is already not possible; several <tt>nsIFrame::Paint</tt> methods already call <tt>gfx*</tt> interfaces directly
** Non-Thebes <tt>gfx/src/*</tt> backends should be deleted early in the process, to remove false hits from automated scans for code needing conversion
** I am unclear on whether <tt>gfx/src/psshared</tt> is still useful
** Code loose in <tt>gfx/src and gfx/src/shared</tt> needs to be dealt with case-by-case
* End point: should be possible to remove <tt>gfx/src</tt> altogether (perhaps <tt>gfx/thebes/src</tt> becomes <tt>gfx/src</tt>, <tt>gfx/thebes/public</tt> merged into gfx/public?)

== Plan ==

* Work out unit conversion issues (see next section)
* Identify and strip source files which are currently unused or can easily be made unused
* DeCOMtaminate where appropriate, eliminating nsI classes
* For each cluster of objects listed below under "Classes involved", refactor all code out of the non-<tt>gfx*</tt> classes, so that they are perfect wrappers or even typedefs for the <tt>gfx*</tt> classes
* Bubble use of <tt>gfx*</tt> direct interfaces upward into paint methods, layout class data members, etc. until all uses of the old interfaces are gone

== Unit conversion ==

Issues:

* layout should still do its work in <tt>nscoord</tt> units (1/60th of a CSS pixel), per offline discussion with dbaron
* gfx is expecting <tt>gfxFloat</tt> units (device pixels)
* we don't want to sprinkle conversions through every paint method
* because <tt>gfxFloat</tt> is a floating point type, changing the sequence of arithmetic operations may change what actually gets drawn (see {{bug|376180}} for an example of this)
* <tt>nsRenderingContextThebes</tt> currently has easy access to the nscoord-to-device conversion ratio (<tt>mP2A</tt> and the <tt>FROM_TWIPS</tt>[sic] macros), whereas it's somewhat awkward to get it from a paint method (<tt>PresContext()->AppUnitsPerDevPixel()</tt> is the best way I can find, and that expands to something like four pointer dereferences under the hood).
* There are several bugs relating to coordinate systems and behavior at overflow: {{bug|265084}}, {{bug|370006}}, {{bug|379616}}, (please add to this list...)

Possibilities:

* keep the conversions at the layout/gfx interface:
** define implicit conversion operators, so passing <tt>nscoord</tt> and related types to <tt>gfxContext</tt> functions makes the compiler generate conversion code in the paint method
*** for this to work, <tt>nscoord</tt> would have to be a class type
*** the conversion operators would need to know the conversion ratio; see above
** change <tt>gfx{Float,Point,Size,Rect}</tt> to take <tt>nscoord</tt>-family inputs and convert internally
*** for this to work, <tt>gfxFloat</tt> would have to be a class type
*** also, these types would need to know the conversion ratio, which might mean they need to be told what <tt>gfxContext</tt> they're being created for

* push the conversion down into gfx:
** overload all <tt>gfxContext</tt> methods to take <tt>nscoord</tt> family arguments, do the conversions in the thebes layer
*** ugly, exposes <tt>nscoord</tt> types in gfx
** make the cairo transformation matrix do all the work (so the thebes layer continues to use its own types, but the numbers are in the same units that layout uses)
*** facilitates replacing <tt>ns*</tt> types with <tt>gfx*</tt> types bubbling upward
*** could be error prone if anyone else messes with the matrix
** might not give the same rounding behavior as currently

* other ideas?

Overall I like "make the cairo transformation matrix do all the work"
best, but I'm worried about its getting messed with. Perhaps we can
enforce a use discipline similar to PDF's - you can save and restore
the current matrix, you can "concatenate" a transformation onto the
existing matrix, but you can't wipe out the existing matrix and start
over.

== Classes involved ==

Note that these lists were generated by a lot of staring at the output of a [[Dehydra]] script of dubious correctness. I may have missed things.

* Graphics objects: these come in clusters, either <tt>ns<thing></tt> and <tt>gfx<thing></tt> parallel implementations, or an <tt>nsI<thing></tt> interface, a <tt>nsThebes<thing></tt> shim, and (usually) a <tt>gfx<thing></tt> real implementation. In both cases the desired end point is that there is only <tt>gfx<thing></tt>.

:::: <tt>nsFont</tt>, <tt>gfxFont</tt>

:::: <tt>nsColor</tt>, <tt>gfxRGBA</tt>

:::: <tt>nsCoord</tt>, <tt>gfxFloat</tt>

:::: <tt>nsPoint</tt>, <tt>gfxPoint</tt>

:::: <tt>nsRect</tt>, <tt>gfxRect</tt>

:::: <tt>nsSize</tt>, <tt>gfxSize</tt>

:::: <tt>nsMargin</tt> (no equivalent?)

:::: <tt>nsTransform2D</tt>, <tt>gfxMatrix</tt>

:::: <tt>nsFontCache</tt>, <tt>gfxFontCache</tt>

:::: <tt>nsIFontMetrics</tt>, <tt>nsIThebesFontMetrics</tt>, <tt>nsThebesFontMetrics</tt>, <tt>nsBoundingMetrics</tt>, <tt>gfxFont::Metrics</tt>

:::: <tt>nsIImage</tt>, <tt>nsThebesImage</tt>, <tt>gfxIImageFrame</tt>, <tt>gfxImageFrame</tt>, <tt>gfx*Surface</tt> (?)

:::: <tt>nsIRegion</tt>, <tt>nsRegion</tt>, <tt>nsThebesRegion</tt>, <tt>nsIScriptableRegion</tt>, <tt>nsScriptableRegion</tt>

:::: <tt>nsTextDimensions</tt>, <tt>gfxGlyphExtents</tt> (?)

:::: <tt>nsIFontEnumerator</tt>, <tt>nsThebesFontEnumerator</tt>

* Context classes: like the graphics objects, they come in clusters, but I think we want to collapse all of these into one class, <tt>gfxContext</tt>. (If the distinction between device context and rendering context is useful - I have no hard evidence, though I suspect it isn't - we would want to keep <tt>nsRenderingContext</tt> too, but de-COM it.)

:::: <tt>nsIDeviceContext</tt>, <tt>DeviceContextImpl</tt>, <tt>nsThebesDeviceContext</tt>

:::: <tt>nsIRenderingContext</tt>, <tt>nsRenderingContextImpl</tt>, <tt>nsThebesRenderingContext</tt>

:::: <tt>gfxContext</tt>

* Thebes-only graphics objects: there is no nsI-level interface to these (that I found). Probably they can be left alone.

:::: <tt>gfxFlattenedPath</tt>, <tt>gfxFontGroup</tt>, <tt>gfxFontStyle</tt>, <tt>gfxMatrix</tt>, <tt>gfxPattern</tt>, <tt>gfxSkipChars</tt>, <tt>gfxSkipCharsBuilder</tt>, <tt>gfxSkipCharsIterator</tt>, <tt>gfxTextRun</tt>, <tt>gfxTextRunCache</tt>, <tt>gfxTextRunFactory</tt>, <tt>gfxTextRunWordCache</tt>

* Helper classes: probably do not need messing with except incidentally.

:::: <tt>gfxContextAutoSaveRestore</tt>, <tt>nsRegionRectIterator</tt>

* Thebes internal implementation and unit tests (I think). Again, probably do not need messing with except incidentally.

:::: <tt>gfxASurface</tt>, <tt>gfxImageSurface</tt>, <tt>gfxXlibSurface</tt>, <tt>gfxXlibNativeRenderer</tt>, other <tt>gfx*Surface</tt> and <tt>gfx*NativeRenderer</tt> classes not used under X11/gtk

:::: <tt>gfxFontNameList</tt>, <tt>gfxFontTestItem</tt>, <tt>gfxFontTestStore</tt>, <tt>gfxPangoFont</tt>, <tt>gfxPangoFontWrapper</tt>

:::: other <tt>gfx*Font*</tt> classes not used under X11/gtk; note that Pango has ATSUI and Uniscribe back ends, but using Pango universally, if desirable, should be a separate project

:::: <tt>gfxPlatform</tt>, <tt>gfxSparseBitSet</tt>

* Other things defined in gfx headers, whose role I am uncertain of:

:::: <tt>nsColorNames</tt>, <tt>nsCUPSShim</tt>, <tt>nsPSPrinterList</tt>, <tt>nsITheme</tt> (where is the implementation?)

[[Category:Mozilla 2]]

Releases/Firefox 3.0b5

2008-03-11T03:05:22Z

Taken: add |color| rule

<small>[[Releases|« Release Schedule]]</small>

<div style="border: thin dotted #aaa; background: InfoBackground; color: InfoText; padding: 10px;">'''Hi!''' You may have gotten here from a web page that tried to link to a release candidate of a Firefox beta. While we're happy that you're interested in our product, it's not quite ready for public release yet, as it hasn't been properly tested or vetted. When it's ready, you'll be able to download the beta at [http://www.mozilla.com/firefox/all-beta.html www.mozilla.com/firefox/all-beta.html]</div>

Tracking document for the release of Firefox 3 Beta 5. See also:
* [[Firefox_3.0b5:BuildNotes|Build Activities]]
* [[QA/Firefox3/TestResults/Beta5|QA Activities]]
* [[QA/Firefox3/TestResults/Beta5/Release_Notes|Beta 5 Release Note list]]
* [http://l10n.mozilla.org/dashboard/ l10n Status Dashboard]

== Who ==
* Overall lead: beltzner
* Dev lead: damons
* Build lead:
* QA lead: tchung
* Release Notes / Web lead: beltzner

== Release Tracking & Schedule ==
{| class="fullwidth-table"
| style="background:#efefef" | '''step'''
| style="background:#efefef" | '''date'''
| style="background:#efefef" | '''status'''
|-
| en-US string freeze
| March 7
|
|-
| tree closed for baking
| March 18
|
|-
| l10 code frozen
|
|
|-
| code hand-off to build
|
|
|-
| RCs built (en-US, locales, & updates)
|
|
|-
| QA tests of RCs
|
|
|-
| website changes on www-trunk.stage.m.c
|
|
|-
| QA tests update snippets (betatest)
|
|
|-
| QA & release driver handoff for release
|
|
|-
| Build pushes to mirrors
|
|
|-
| QA tests update snippets (releasetest)
|
|
|-
| QA tests website changes
|
|
|-
| website changes pushed live
|
|
|-
| QA tests website changes, download links & installers
|
|
|-
| Build enables updates
|
|
|-
| QA tests live snippets (beta)
|
|
|-
| release announced
|
|
|-
|}

Performance/Status Meetings/2007-July-25

2007-07-25T10:56:10Z

Taken: using bug template, shoter url

[[Performance/Status_Meetings|« Back to Status Meetings ]]

== Participants ==

== Agenda ==

== Infrastructure ==
* Generate reliable, relevant performance data (already underway as talos). Talos status update? http://tinderbox.mozilla.org/MozillaTest/
** running against hourly builds on trunk, see MozillaTest
** lots of crashes with historical runs, wondering if its doable.
** released branch points already available on 1.8 branch.
** '''AI:robcee/alice''' to start using smaller Tp set

* Discuss talos cpu usage metric
** cpu usage numbers... discussion on how cpu usage being calculated.
** going to ignore those numbers for now, no humans looking at them.
** '''AI:zach will merge changes'''

* Areas where help is needed
* expand the scope of performance testing beyond Ts/Tp/TXUL/TDHMTL

* reduce noise in tests
** reduce to ~1% (suggested by bz, not started)
** move perf tests to chrome, so we get more reliable results, and can test more than just content
** '''AI:vlad & dbaron to checkin hopefully today'''

* improve performance reporting and analyses:
** Better reports for sheriffs to easily spot perf regressions
** Tracking down specific performance issues
* stats change to track AUS usage by osversion. {{bug|382044}}. '''AI:justin'''

*Priorities for infra:
** Generate historical baselines
** General profile data regularly on builds
** Getting the perf numbers more stable
** Developing the graph server to display time spent in each module

* New ideas
** Question: How are we tracking perf bugs, specifically, and are we doing this the same way we are triaging security bugs? Can we do it the same way if not? ('''AI:damon''')

== Gecko: Perf discussion ==

* Perfathon update
** vlad has data

* pageload test rewrite ({{bug|387110}})
** since we have a chance at a clean break, we should look at how the composite scores are calculated
** do we still want to ignore the biggest value when computing the mean and stddev? (there is caching and stuff that happens during the first time a page is loaded that ends up beneficially effecting subsequent page loads)
** do we want to more cycle more intelligently?
*** e.g. do we want to keep cycling (up to some max) until the stddev drops below some number?
*** do we want to try to intelligently throw outliers out?

* update on [https://bugzilla.mozilla.org/show_bug.cgi?id=363258 timer resolution on windows] from Rob Arnold.
** Done, checked in earlier this week.

* Talos results
** What's it look like for 1.8 -> 1.9?

* Todo: verification of test results
** '''Fonts, valid rendering, etc.'''
** '''TODO: Stuart: verify that concerns about talos results are addressed'''

* probe update
** stan taking over mozilla/gecko side of probe work
*** will get Sun's dtrace patch as well as xp-probes checked in to new toplevel dir, then work on merging the two
** crowder taking spidermonkey side
*** will be dtrace only
** module owners should let stan know if they have any situations that they'd like to analyze, so that he has more information about how to structure the probe work.
*** for example, examining loading from network performance vs. loading from disk
** Sun guys will be here on Aug 30 to do a presentation on dtrace, followed by hands-on work with a smaller group of engineers

=== Previous weeks ===

* jrpof tinderbox

* synthetic tests (TODO)
** put specific tests into talos framework
** poach mochitest performance tests
** individual reftest-like items

* need to get a bunch of people looking at profiles (TODO)
** take up some of these meetings to sit down and look at profiles
** timer-based profiling is better (vtune/jprof/oprofile/etc., not quantify)
** TODO: vlad to generate profile for next week's meeting

* running without Fx chrome
** new pageloader stuff can do this

* examining default theme for performance issues

* Tp vs. Tp2
** new pageloader stuff avoids this problem
** Tp2 was flawed in some ways -- one big one is that it loaded pages in an iframe, so initial paint delay was never coming into play, and we were potentially reflowing more thannecessary

== Other Information ==

[[Performance/Status_Meetings/Related_Bugs|Related Bugs]]

Toolkit:Platform Specific Extension Components

2007-03-29T06:32:31Z

Taken: using delete template

{{Delete|Inappropriate for this wiki --[[User:Taken|Taken]] 23:32, 28 March 2007 (PDT)}}
----

<span style="font-weight: bold; font-style:italic; color: green;">Support for platform directories was checked in and is now documented at [[mdc:Bundles]] .</span>
--[[User:Jens.b|Jens.b]] 14:09, 8 Jun 2005 (PDT)

----

== Introduction ==

Some extensions are only intended for one platform, either because it uses things other platforms don't have (e.g. the Windows registry, like Linky does), or because they have binary components. Both the extension manager and services like http://addons.mozilla.org/ would benefit if extensions had some sort of [https://bugzilla.mozilla.org/show_bug.cgi?id=255619 platform-compatibility information as part of their metadata]. Note that themes are handled like extensions in some places, so they could include use such platform-compatibility information, too.

However, solving this issue is not enough, as two problems remain:

== Problem 1 ==

A growing number of Firefox and Thunderbird extensions use compiled, binary components. To keep the cross-platform nature Extensions usually have, you have to provide these binaries for each supported platform. Currently, all these are stuffed into the components/ directory. If you put binaries for several platforms into this components/ directory, you encounter the problem that Win32 loads not only .dll files, but also tries to load linux .so ones and fails with an error message.

The effect is that most extensions either
# are available in separate XPIs for each platform, posing problems for updating and http://addons.mozilla.org/
# include all platform binaries in one package and employ hacks to work around the problem

Needless to say, both alternatives aren't very appealing for extension authors.

Another problem is that binary components have to use the same [http://en.wikipedia.org/wiki/Application_binary_interface ABI] as the host application, or they won't work. Currently, there is no way to check or enforce this - when you install a linux-gcc2-built extension into a linux-gcc3-built application, things just break.

== Problem 2 ==

Some themes currently need a separate Macintosh version. While platform compatibility info as part of the metadata would make it impossible for a user to accidently install the wrong package, it would certainly be nice to be able to have one multi-platform theme package that includes some generic "base" files and some platform-specific ones.

== Conclusions ==

We need...
# components that are only loaded if they were compiled for the same platform AND using the same ABI as the host application (Firefox, Thunderbird)
# platform-specific theme jar files, default preferences, window icons and whatever ("this fileset for windows, that one for mac")

== The Solution ==

The notion of "platform file sets" is added by introducing a new subdirectory inside extension and theme packages: the '''platform''' directory. For each set of files that somehow depend on the target environment, it contains a directory named in one of the following ways:

* [OS_TARGET]
* [OS_TARGET]_[ABI]

'''OS_TARGET'''
: The platform the host application was compiled for, e.g. WINNT, Linux, Darwin (meaning Mac OS X)...
'''ABI'''
: The application binary interface the component was built with - e.g. gcc2, gcc3, mingw, msvc.

In each of these directories, the regular directory structure of the package (chrome, components, defaults for extensions, or the package dirs for themes) is repeated as needed.

The Extension Manager will install the package as usual - i.e. it extracts all files in the archive. The toolkit's nsXREDirProvider is enhanced so it automatically considers not only the extension's base directory, but also the matching platform directories.

A Firefox version built with MSVC for Windows would therefore try to load components and default preferences from directories listed below (if existing), and totally ignore any other subdirectories of platform/.
* components/
* defaults/preferences/
* platform/WINNT/components/
* platform/WINNT/defaults/preferences/
* platform/WINNT_msvc/components/
* platform/WINNT_msvc/defaults/preferences/

Older Firefox releases would also ignore everything in platform/.

== Example Extension Structure ==
myExt.xpi:
install.rdf
chrome/:
myExt.jar
defaults/:
preferences/:
myExt.js
platform/:
Linux_gcc2/:
components/:
mycomponent.so
Linux_gcc3/:
components/:
mycomponent.so
WINNT/:
defaults/:
preferences/:
myExt-win.js
WINNT_msvc/:
components/:
mycomponent.dll
WINNT_mingw/:
components/:
mycomponent.dll

== Resolved Issues ==

<dl>
<dt>What happens when we put chrome jar files in the platform directories - do they have to be listed in the main chrome.manifest? What if the current platform doesn't have that file, is it just ignored?

<dd> Each platform directory may have its own chrome.manifest:
<pre>chrome.manifest
platform/WINNT/chrome.manifest
platform/WINNT_msvc/chrome.manifest</pre>

<dt>What happens to preference files - what happens if two have the same name, in which sequence are they loaded, are prefs overwritten if specified in both the base prefs file and a platform-specific one?

<dd> Yes, we should read the "base" preferences first, then the platform-specific ones, and the pref system will automatically override any duplicate prefs.
</dl>

== Bug References ==

* https://bugzilla.mozilla.org/show_bug.cgi?id=253742<br>No way of installing platform specific XPCOM components (dll/so) based on user OS.
* https://bugzilla.mozilla.org/show_bug.cgi?id=294835<br>Need way of determining ABI in makefiles

Feature request for Mozilla 3

2007-03-29T06:23:52Z

Taken: Reverting my edit

== Feature request for Mozilla 3 ==

I would like Mozilla 3 to support user-controlled alternative style sheets.

Let us assume that there is some site that offer alternative style sheets for the WWW pages it serves to the public. Let us further assume the styles to be named 'default', 'alt1' and 'alt2'. It might happen that when a user visits the site, he/she/it (further on referred to as 'she') finds that the default style does not fit her needs, but that the style 'alt1' does.

In her Firefox (1.5.0.7) she picks the alternate style from 'View -> Page Style -> alt1' and all is well. Then, she follows a link to another WWW page on the site, and she once again gets the 'default style'.

This is very irritating. When she has picked an alternative style for the top level, she of course wants that to be in effect until she changes that - for example, for some sub-tree of the site, she wants alternative style 'alt2'. As it is today, she can't get that. Even worse, if she returns to the first page, she will get (you guessed it) the default style.

Below the request is written in coorporate project:

* Mozilla 3 shall support user controlled WWW page styles.
* The control shall be based on existing styles for a WWW page.
* It shall be possible to associate a WWW page address with a specific style.
* The association shall be done using regular expression.
* The regular expression shall be the extended perl-like regexps.
* In the case of multiple matches, the most specific (longest) match shall be used.
* A dialogue to set this up for a page shall be available from a page menu.
* The page menu shall be available from a sight-click using a three-button mouse.

Same Site Multiple Logins

2007-03-29T06:23:31Z

Taken: Revert my edit

Several accounts with different logins for the same site eg banks, share trading etc. With Firefox have to log out from one account the log in with another. Can't log in a second time either in a new tab or a new instance of Firefox. Different instances of IE allow different logins.

Toolbar customization

2007-03-29T06:21:04Z

Taken: Revert my edit

I'm really new to all this. I've just discovered Firefox. But already I've hit a big snag. There is no provision for rearranging tool bars, as in IE. After some reading, I found that there used to be "grippies" as they call them, for moving the tool bars around....and this feature was removed?? That baffles me....why would this most basic of features be removed?
Some more searching and I found an extension which claimed to be able to put this function back, but it's only compatible up to FF 1.5.
Well, I hope I put this suggestion in the right place. Please put this functionality back.

Debugging a hang on Mac OS X

2007-03-29T06:08:08Z

Taken: use delete template

{{Delete|Inappropriate for this wiki --[[User:Taken|Taken]] 23:08, 28 March 2007 (PDT)}}

Find out [[mdc:Debugging a hang on OS X|how to debug a hang, on Mozilla Developer Center]]

The autocomplete attribute and web documents using XHTML

2007-03-29T05:39:58Z

Taken:

{{Delete|Inappropriate for this wiki. Should move to mdc. --[[User:Taken|Taken]] 22:39, 28 March 2007 (PDT)}}

== Executive summary ==

Many important web content producers, including banks and Google, insist on using the non-standard HTML <code>autocomplete</code> attribute for either security or usability reasons. When writing HTML, such authors should declare and validate against a custom doctype including the <code>autocomplete</code> attribute ([http://www.benjaminhawkeslewis.com/legacymarkup/examples/html-4.01-strict-plus-autocomplete.html example HTML document]).

However, there is currently no way to trigger the same user agent functionality with an attribute in XHTML. This constitutes an unnecessary obstacle to the adoption of XML-based markup.

If the W3C adopts Web Forms 2.0 then this problem will be solved.

If that doesn't happen, by adopting my solution and supporting a small XHTML module and delimited <code>class</code> microformat, browsers could enable authors serving XHTML 1.0 as text/html to trigger the same behaviour with <code>class="fh disable_form_history"</code> ([http://www.benjaminhawkeslewis.com/legacymarkup/examples/xhtml-1.0-strict-plus-autocomplete-html-compatible.html example XHTML 1.0 document]) and authors serving XHTML properly as application/xhtml+xml to trigger the same behaviour with a namespaced attribute (<code>fh:form_history="off"</code>) ([http://www.benjaminhawkeslewis.com/legacymarkup/examples/xhtml-1.1-plus-formhistory-with-dtd-draft1.xhtml example modularized XHTML document]). Those authors who wish to serve both XHTML and HTML properly using an XSL transformation would could convert to the HTML <code>autocomplete</code> attribute with simple XSL rules.

== Background ==

When Microsoft introduced [http://msdn.microsoft.com/workshop/author/forms/autocomplete_ovr.asp form AutoComplete] to the web with Internet Explorer 5 in 1999, they also "extended" the
<code>form</code> and text and password <code>input</code> elements of HTML 3.2 with an [http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/autocomplete.asp <code>autocomplete</code> attribute] which allowed site authors to disable this feature on a case-by-case basis. Gecko-based browsers gained an autocomplete feature in 2000, and by 2001 they too were forced to support the <code>autocomplete</code> attribute ([http://devedge-temp.mozilla.org/viewsource/2003/form-autocompletion/index_en.html Netscape Devedge: How to Turn Off Form Autocompletion]). The primary motivation for the attribute at that time was that banks believed disabling autocomplete was a necessary security measure for the login information on their websites, and would bar from their services browsers that had autocomplete features without support for disabling them.

In practice, disabling autocomplete is not a particularly effective security measure. Even in the days of Internet Explorer 5, any machine could be compromised by keylogging that would of course be undeterred by a mere <code>autocomplete</code> attribute. Thanks to the rise of User-Agent spoofing, it became increasingly difficult to exclude browsers like Opera that support form history but ignore the <code>autocomplete</code> attribute by default ([http://www.opera.com/support/usingopera/operaini/index.dml Opera's Settings File Explained]), or browsers like ELinks and OmniWeb that have form history and ignore the attribute entirely. And now that web users increasing edit the content delivered to them from the server to suit their own preferences, circumventing the <code>autocomplete</code> attribute is trivial ([http://www.squarefree.com/bookmarklets/forms.html#remember_password Remember Password Bookmarklet]) even in Mozilla browsers that claim to support it "perfectly" ([http://developer.mozilla.org/en/docs/How_to_Turn_Off_Form_Autocompletion Mozilla Developer Center: How To Turn Off Form Autocompletion]). Nonetheless, even technical opinion is divided over whether <code>autocomplete</code> offers valuable protection against casual attackers or merely lulls users and web authors into a false sense of security, leaving them vulnerable to more determined assailants.

I don't know of a formal statement of the current attitude of banks towards <code>autocomplete</code>, but I suspect many still believe it to be an important safeguard, notwithstanding the flaws I've just mentioned. As late as November 2004, financial standards bodies like [http://www.apacs.org.uk/ APACS] were insisting that sensitive systems make use of the attribute and failure to use it could spell public relations disaster ([http://news.bbc.co.uk/1/hi/business/3995019.stm BBC News: Bank moves to close web loophole]). Security consultants like McAfee's Corey Benninger continue to recommend that site owners employ the <code>autocomplete</code> attribute ([http://www.internetnews.com/dev-news/article.php/3624796 Developer: Browser Cache: Goodies For Hackers]). The developers of the [http://whatwg.org/specs/web-forms/current-work/ Web Forms 2.0 specification] were forced to support the <code>autocomplete</code> attribute ([http://whatwg.org/specs/web-forms/current-work/#the-autocomplete Web Forms 2.0 Working Draft: The <code>autocomplete</code> attribute]) even though they do not believe it offers any genuine security benefits ([http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054 Lachlan Hunt kicking off an epic thread on the subject at the WHATWG mailing list]).

Here's a non-exhaustive list of major banking groups I've found currently making use of <code>autocomplete</code>:

* [http://www.citigroup.com/ Citigroup]
* [http://www.hsbc.com/ HSBC]
* [http://www.bankofamerica.com/ Bank of America]
* [http://www.jpmorganchase.com/ JPMorganChase]
* [http://www.compassweb.com/index.html Compass Bank]
* [http://www.rbs.com/ Royal Bank of Scotland]

In 2004, Kevin Gibb's [http://www.google.com/webhp?complete=1&hl=en Google Suggest] found a new use for the <code>autocomplete</code> attribute: disabling the browser's autocompletion in order to allow a website's own JavaScript autocompletion to begin with a blank <code>input</code> field. Although it is possible to achieve a similar effect without the attribute, Google has set a precendent and now such non-standard code is churned out by Ajax developers, libraries, and toolsets everywhere. For example, Ruby on Rails's autocomplete helpers use it.

In summary, it seems that despite being non-standard, having known security flaws, being replicable with alternate techniques, and suffering from limited browser support, <code>autocomplete</code> is here to stay.

== The Problem ==

1. Mainstream web development should be based on common markup based on some sort of standards.

2. When serving content is important to be accurate about what standard you are following (hence need for the Vary HTTP header, MIME types, document types, XML schema, microformats, etc), or the standards themselves become depreciated.

2. The web is gradually transitioning from HTML to XML-based markup, helped by minority browsers that can parse the application/xhtml+xml internet media type correctly.

3. When writing HTML, it is trivial to express the <code>autocomplete</code> attribute using the SGML standard by creating a custom DTD and using that as your doctype. You can create such a DTD by importing an HTML DTD and then simply adding the following line:

<blockquote><code><!ATTLIST (form|input) autocomplete (on,off) #IMPLIED></code></blockquote>

I've put up some example DTDs at my site:

* [http://www.benjaminhawkeslewis.com/legacymarkup/dtd/html-4.01-frameset-plus-autocomplete.dtd HTML 4.01 Frameset plus autocomplete]

* [http://www.benjaminhawkeslewis.com/legacymarkup/dtd/html-4.01-transitional-plus-autocomplete.dtd HTML 4.01 Transitional plus autocomplete]

* [http://www.benjaminhawkeslewis.com/legacymarkup/dtd/html-4.01-strict-plus-autocomplete.dtd HTML 4.01 Strict plus autocomplete]

* [http://www.benjaminhawkeslewis.com/legacymarkup/dtd/iso-html-15445-2000-plus-autocomplete.dtd ISO/IEC 15445:2000 HTML plus autocomplete]

To use such as custom doctype, simply declare it like so:

<!DOCTYPE html SYSTEM "http://www.benjaminhawkeslewis.com/legacymarkup/dtd/html-4.01-strict-plus-autocomplete.dtd">

Contrary to common misapprehensions, declaring a custom DTD in this way does '''not''' trigger Quirks mode, not even in IE 5/Mac. Unrecognized doctypes with a URI are interpreted in full Standards mode. See:

* [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp#cssenhancements_topic2 MSDN: CSS Enhancements in Internet Explorer 6]

* [http://www.opera.com/docs/specs/doctype/ The Opera 9 DOCTYPE Switches]

* [http://developer.apple.com/internet/bestwebdev.html Apple Developer Connection: Web Development Best Practices]

* [http://developer.mozilla.org/en/docs/Mozilla's_DOCTYPE_sniffing Mozilla Developer Center: Mozilla's DOCTYPE Switching]

* [http://www.ericmeyeroncss.com/bonus/render-mode.html Eric Meyer on CSS: Picking a Rendering Mode]

I've added an [http://www.benjaminhawkeslewis.com/legacymarkup/examples/html-4.01-strict-plus-autocomplete.html example document using the Strict version] to my site.

4. The X in XHTML stands for "extensible". But because all elements and attributes are namespaced in XML and the W3C jealously guard their XHTML namespace from extension by others, a site author may not do the same with XHTML-based markup. While it is certainly possible to build a custom XML DTD to include an <code>autocomplete</code>, the act would be meaningless as the W3C have made it clear they would not regard documents extending the XHTML namespace in this way as even using XHTML at all ([http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform XHTML Modularization 1.1: Working Draft: Conformance Definition], also see [http://alistapart.com/articles/customdtds2/ A List Apart: More About Custom DTDs]).

5. Therefore there is no current way to use a simple markup attribute to turn off autocompletion when using XHTML.

== A solution? ==

Whichever solution is adopted, it is at present only important for Mozilla, KHTML, and WebKit developers to recognize it, as (AFAIK) only browsers based on their engines both correctly parse application/xhtml+xml ''and'' claim to allow form history to be disabled by site authors.

=== The options ===

1. The very best solution would be to radically overhaul XHTML and JavaScript to make it easy to write secure web applications. [http://www.webappsec.org/lists/websecurity/archive/2006-08/msg00011.html Andrew van der Stock has some pointers over at the Web Application Security Mailing List.] However, that will likely take years and will still leave the problem of legacy browsers. Would-be XHTML authors need a solution to this problem now.

2. ''If'' we agree that <code>autocomplete</code> is ultimately detrimental to security, the next-best solution would be to persuade the web and financial communities to employ other techniques. Good luck with that.

3. Failing that, a good solution would be to persuade the W3C to include the autocomplete attribute in an XHTML module similar to the [http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_Legacy Legacy module]. When I originally drafted this proposal, I thought that would never happen, but it looks like there's a fighting chance Web Forms 2.0 (which comes in HTML and XML flavours) will be adopted by the W3C - and Web Forms 2.0 includes the "autocomplete" attribute. :) See [http://my.opera.com/community/forums/topic.dml?id=153013&t=1155219050 my discussion with Opera's Anne van Kesteren] and keep an eye out for Web Forms 2.0 news in September!

4. Still let's not count our chickens until they've hatched. Failing that, we could add browser support for a <code>formhistory</code> attribute in a vendor neutral URI such as <nowiki>http://www.legacymarkup.org/xmlns/formhistory</nowiki>, and implement it in a simple XHTML module. When serving the same resource as HTML following content negotiation, the XSL transformation to HTML would be trivial:

<blockquote><pre>
<xsl:template match="@formhistory:formhistory='on'">

<xsl:attribute name="autocomplete">on</xsl:attribute>
</xsl:template>

<xsl:template match="@formhistory:formhistory='off'">

<xsl:attribute name="autocomplete">off</xsl:attribute>
</xsl:template>
</pre></blockquote>

(N.B. This should work, but needs testing anyhow.)

Remember however, that (properly) HTML used in this way must use a custom doctype, as described above. Indeed, following the example of embedded XHTML accessibility roles ([http://www.w3.org/WAI/PF/adaptable/HTML4/embedding-20060318.html Embedding Accessibility Role and State Metadata in HTML Documents: Working Draft]), we could create an associated microformat ([http://microformats.org/wiki/introduction Microformats Wiki: Introduction to Microformats]) that would overload the <code>class</code> attribute. Accessibility uses "axs" as a delimiter to prevent namespace collision; we could use "fh". So we'd end up supporting:

<blockquote><code>class="some_css_class some_other_css_class fh disable_form_history"</code></blockquote>

and

<blockquote><code>class="fh enable_form_history"</code></blockquote>
The two variations are necessary because an input might have autocomplete enabled within a form that generally wants autocomplete disabled (hat tip to Richard Moore).

Microformatted (X)HTML could still be converted to custom HTML comprehensible to older, non-supporting user agents with an XSL transformation, something along the lines of:

<blockquote><pre>
<xsl:template match="xhtml:input[contains(@class,'disable_form_history')]">
<xsl:element name="{local-name()}">

<xsl:apply-templates select="@*"/>

<xsl:attribute name="autocomplete">off</xsl:attribute>
</xsl:element>
</xsl:template>
</pre></blockquote>

(N.B. This XSL definitely needs testing.)

5. Other alternatives might involve using proprietary extensions, such as XUL/XBL. I suspect any implementation would be dependent on JavaScript, which would not satisfy those using <code>autocomplete</code> for putative security reasons. It would also be inferior to a cross-browser solution. However, such extensions might prove useful for backporting support for namespaced or microformated autocompletion instructions to old versions of browsers, whether Mozilla (with extensions or XUL/XBL), Konqueror (with [http://developer.kde.org/documentation/tutorials/kparts/ KParts]), or even to Internet Explorer (with [http://msdn.microsoft.com/workshop/components/htc/reference/htcref.asp HTC]). For an inspiring example of what can be achieved with such extensions, have a look at [http://w3future.com/weblog/gems/xhtml2.xml Sjoerd Visscher's XHTML 2 page at W3Future], which uses proprietary Opera CSS, XBL, and HTC to mimic XHTML 2 on current user agents.

=== Conclusion ===

At present the most practical option is 4, hopefully aided by 5.

(As a sidenote, if we went down the namespaced route, we might like to create a more general <nowiki>http://www.legacymarkup.org/xmlns/legacyml</nowiki> namespace as a retirement home for all sorts of legacy markup that the W3C would, admirably but somewhat impractically, ignore.)

== How would Option 4 help web authors if implemented? ==

Option 4 would affect web authors differently depending on what sort of markup and internet media (MIME) type they are using.

=== Authors who want to use ''only'' HTML ===

If they declare that they are authoring according to a W3C HTML doctype, but use the <code>autocomplete</code> attribute then they are simply generating junk markup (as has always been the case). What they should do is use a custom DTD (as described above). Because of browser support, this is the best option for those who want to use <code>autocomplete</code> for security.

My suggestion would allow developers to author HTML according to W3C DTDs and disable autocompletion in supporting browsers, using a namespaced class like so:

<blockquote><pre><INPUT TYPE="text" CLASS="fh disable_form_history" NAME="sensitive ID="sensitive"></pre></blockquote>

This would be a great option for people creating Ajax applications like Google Suggest.

=== Authors who want to use ''only'' XHTML ===

I cannot emphasize enough that the use of the <code>autocomplete</code> attribute is currently utterly ''impossible'' in XHTML documents. With my proposal implemented, authors could at last use an attribute that does the same thing as the <code>autocomplete</code> attribute. Browser support would be less widespread, but browser support for XHTML as a whole is less common and browser support for the attribute is patchy in the first place (e.g. Opera, ELinks, etc.).

Using my attribute would require the import of a namespace (and ideally a suitable doctype). Such imports are common in the XHTML world, as they are required to mix in goodies like SVG, MathML, and XForms. Here's what such a document might look like:

<blockquote><pre>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC
"-//LegacyMarkup//DTD W3C XHTML 1.1 plus FormHistory"
"http://www.legacymarkup.org/2006/08/xhtml-formhistory/xhtml-formhistory.dtd">
<html xml:lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:fh="http://www.legacymarkup.org/xmlns/formhistory">
<head>
<title>Example document</title>
</head>

<body>

<form action="http://www.example.com/someaction" method="post">
<div>

<label for="non_sensitive">Your non-sensitive data:</label>

<input type="text" name="non_sensitive" id="non_sensitive"/>

<label for="sensitive">Your sensitive data:</label>

<input type="text" fh:formhistory="off" name="sensitive" id="sensitive" />

</div>
</form>

</body>

</html>
</pre></blockquote>

=== Authors who want to write XHTML 1.0, but use content negotiation to serve XHTML 1.0 as text/html (i.e. tag soup) to user agents that don't support XHTML ===

This group *must not* use the existing autocomplete attribute when serving as text/html (because it's not XHTML), and (I think) *must not* use the proposed namespaced attribute (because it's not HTML). But it is trivial for them to use the proposed microformat in ordinary XHTML 1.0, just like this:

<blockquote><pre>
<input type="text" class="fh disable_form_history" name="sensitive id="sensitive" />
</pre></blockquote>

=== Authors who want to write XHTML, but use content negotiation to serve HTML as text/html to user agents that don't support XHTML ===
This is the group to whom the XSL transformations are relevant. Serving ''both'' XHTML and HTML requires a transformation, usually using XSL. My suggestion would require one additional template rule. Given such authors will often be transforming not only vanilla XHTML, but XForms, SVG, etc. to HTML equivalents, such a template rule is but a drop in an ocean of XSL complexity. (I expect such complexity to be increasingly standardized as XHTML is more widely adopted.)

== Appendix A: What about WHATWG? ==

Update: If Web Forms 2.0 is adopted by the W3C, then the namespace issues I discuss below will disappear.

I welcome and support the work of WHATWG on Web Forms 2.0 and Web Applications 1.0. When Web Forms 2.0 is finalized, it seems set to become a welcome addition to the HTML armoury. Unfortunately, I do not believe it currently offers much to help XHTML authors. Unlike my microformat, Web Forms 2.0 offers nothing at all to authors of XHTML 1.0: there is no way to incorporate its <code>autocomplete</code> attribute in their markup. And unlike my namespaced attribute, its <code>autocomplete</code> currently cannot be legitimately included in an modular XHTML document, as far as I can tell. Although Web Forms 2.0 claims to be XHTML as well as HTML, it seems incompatible with the W3C's specifications for XML markup, according to which only the W3C alone is allowed to extend the "http://www.w3.org/1999/xhtml" namespace. [http://whatwg.org/specs/web-forms/current-work/#xhtml-module-def The Web Forms 2.0 XHTML Module] is at present an only a curiosity. By extending this namespace, it violates the [http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/conformance.html#s_conform_module W3C's own specification for XHTML Family Modules]: "The module definition's elements and attributes must be part of an XML namespace [XMLNAMES]. If the module is defined by an organization other than the W3C, this namespace must NOT be the same as the namespace in which other W3C modules are defined." Nor, judging by the [http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_module Working Draft for the next version of the Modularization specification], is that requirement likely to change in the future. So Web Forms cannot be part of a conforming XHTML host language or XHTML integration set document - that is, it cannot claim XHTML conformance of any sort that would currently be recognized by the W3C.

The [http://www.w3.org/Submission/2005/02/Comment W3C Team Comment on Web Forms 2.0 Submission] shows no sign of the W3C budging on this issue. Conversely, WHATWG have so far rejected pleas to place WHATWG elements and attributes in an XML namespace other than "http://www.w3.org/1999/xhtml". This perhaps isn't terribly surprising, given that WHATWG arose in the context of an [http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html Opera and Mozilla position paper] openly critical of namespace overuse. See also the following threads on the WHATWG mailing list:

1. [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-June/000286.html Is this introducing incompatibilities with future W3C work? (June 2004)]

2. [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/001267.html clear naming for WHAT work (July 2004)]

It is not yet clear whether this divergence between the W3C and WHATWG on namespacing in XHTML modularization should matter. But clearly for those to whom it does matter, Web Forms offers no solution to the problem addressed by this proposal.

Having said that, I think there is a strong case for implementations of Option 4 to allow room to adapt any changes by Web Forms 2.0 to the <code>autocomplete</code> attribute to the XHTML world. One question for discussion is whether Option 4 should mimic Web Forms's requirement that: "Support for the attribute should be enabled by default, and the ability to disable support should not be trivially accessible, as there are significant security implications for the user if support for this attribute is disabled." Notably, Opera currently disables support by default, and the ability to enable support is not trivially accessible.

== Appendix B: Autocomplete alternatives ==

Some readers may be interested in what else is possible with present technology and markup.

=== Security ===

1. You could try educating your users in the dangers of public and unsecured machines, and in how to use their browser's autocompletion functionality selectively. In particular, warn them of the dangers even from from acquaintances and family, who are the perpetrators in around 11% of UK identify fraud ([http://www.cifas.org.uk/reports_what_about_the_victim.asp CIFAS Research: Identify Fraud -- What About the Victim?]). Unfortunately, your users are unlikely to have the same interest in the subject that you have -- until their identity is compromised. Even if they're interested, the majority of internet users are a poor match for more technically sophisticated crooks. This, ultimately, is a serious practical flaw in the argument advanced by Lachlan Hunt and others that site authors have no "right" to restrict web clients' use of autocompletion.

2. Instead of an <code>autocomplete</code> attribute, consider using a [http://en.wikipedia.org/wiki/Nonce nonce (Wikipedia)].

Let's say you have a field like:

<blockquote><pre>
<input type="text" name="my_sensitive_data" autocomplete="off" />
</pre></blockquote>

You could replace that with:

<blockquote><pre>
<input type="hidden" name="my_nonce" value="dLafr5aCo0pH7eyo" />
<input type="text" name="dLafr5aCo0pH7eyo" />
</pre></blockquote>

Here "dLafr5aCo0pH7eyo" is a value generated randomly server-side for each request of the form. On submission, the server simply reads the value of the field named "dLafr5aCo0pH7eyo" into "my_sensitive_data". While form data will be remembered by the browser, it will never be used for autocompletion because the name of the relevant field is different each time. This method has the advantage of being fully compatible with the W3C's HTML and XHTML specification and it does protect the user from their sensitive data simply appearing in fields when someone else uses their computer. However, it obviously offers no protection against someone able to read their stored personal data.

3. Consider using a two-factor system including a one-shot password, as with [http://en.wikipedia.org/wiki/TAN_(banking) TAN (Wikipedia)], which might be distributed via a list, SMS, or a custom hardware device like [http://www.securecomputing.com/index.cfm?skey=21 SafeWord]. Be aware that to some extent this merely converts an electronic security problem into a physical one, and that some users will run a mile when faced with the need for yet another gadget.

=== JavaScript autocompletion ===

The nonce method described above is a good candidate here.

Although Google Suggest does use the <code>autocomplete</code> attribute, there are Ajax libraries that achieve similar effects without it.

Mozilla Prototypes

2007-03-29T05:19:44Z

Taken: add link to mozilla labs

== Goals ==

The goal of Mozilla Labs ("[[Labs]]" for short) is to augment the existing product development process by offering a low-barrier-to-entry environment for discussion, creation and proof-of-concept testing for Mozilla technologies. Labs will be operated as an advanced technology group with a heavy implementation and usability focus rather than a pure research laboratory. It will be a public showcase for some of the innovation emanating from Mozilla and the community.

Labs will be mostly a web site and a brand of Mozilla where experimentation is valued. It will host extensions, experimental builds, and potentially new packagings or new products, so that interested users can obtain and use them, and, just as important, a forum for collecting feedback, suggestions, etc. Mozilla Labs will be mostly virtual, in that there won't be a cadre of researchers here at Mozilla doing the work (at least not for now), and we'll be working with partners to do experiments that we think are relevant and warrant consideration for building into future product releases.

== Background ==

The Mozilla Foundation and Corporation have established goals of promoting choice and innovation on the Internet. The current set of products and technologies that Mozilla offers are incredible feats of engineering but are often encumbered by schedules and deadlines, backwards compatibility, time to market, feature design inertia, project and product risk, etc...

Labs will offer Mozilla employees, community members and interested startup/corporate partners the ability to suggest, experiment, innovate and try out new concepts in Internet technologies. This will be done "off" the current product development cycle and will not be tied to upcoming releases and their schedules.

== Model ==

There are lots of different models for how R&D labs can be run.
* Google has the 20% time for engineers and selected projects make it to [http://labs.google.com Google Labs] for external visibility and testing. Google presents the offerings in either alpha or beta state.
* Yahoo! offers [http://next.yahoo.com/ Yahoo! Next] to showcase beta offerings, Idea Factory for idea submission, and Hack! (Yahoo-Internal access only) for internal experiments.
* AOL has recently introduced [http://greenhouse.aol.com/ Greenhouse] for internally developed previews and prototypes.

There are Mozilla-related project sites such as [http://mozdev.org/ MozDev] and [http://sourceforge.net/ SourceForge] and existing extensions sites such as [https://addons.mozilla.org/ Mozilla Add-ons].

We expect the model for Mozilla Labs to evolve over time but the current thinking is that it will be a hybrid of Google Labs & SourceForge. A limited set of focused projects (determined by Mozilla) with associated discussion and source code (when appropriate) available for review.

It will mostly be mostly a virtual "organization" and hosted online.

== Process ==

Ideas and projects can be thought of as being in a pipeline. Some can be at the concept or idea stage being formed, others are thought out enough that a mockup can be developed, others can be prototyped, while others are ready for user testing.

A set of tools will be introduced to facilitate the discussion of potential ideas and projects. Then, a small set of projects will be initiated and run for a fixed durations. After the fixed duration, an evaluation is conducted to determine if the project should be continued for another run, be modified with new directions for investigation, graduated as a candidate feature for Firefox (or other product), or documented, archived and terminated. Multiple projects can be run simultaneously but likely no more than 5 at any one time.

The scope of the projects can include a wide variety of interest areas for Mozilla. For example:
* Core Firefox features (e.g. Yahoo Frecency experiments, social and remote bookmarking experiments, microformat display/parsing)
* Services Integration (e.g. What does a eBay/Amazon-enabled browser look like?)
* Mozilla Web Services (e.g. online storage for extensions)
* Local Storage (e.g. experiments with SQL Lite - local AJAX)
* Visual Identity (e.g. What should the next generation of Firefox browser look like?)
* Non-PC Devices (e.g. Minimo, Firefox on TV/10-foot UI)
* Presence (e.g. how should online presence be reflected in the browser?)
* Platform technologies (e.g. Should Mozilla offer an API to XYZ?)
* User Privacy & Identity (e.g. Should Mozilla promote initiatives such as AttentionRecorder? OpenID?)
* Media Integration (Is there a new UI we can introduce for sharing, discovering videos, photos?)
* etc...

In this process, we expect to learn a lot from both the successful and unsuccessful projects. The feedback will be documented incorporated as lessons into the product development process. The proposed evaluation process will ensure that we do not over-invest in an area without a clear outcome.

== Tools ==

It is recommended that a separate operating environment be setup so as to not encumber existing production tools and codebases.

* Mini website (labs.mozilla.org) with overview, current projects, project pages, relevant links, downloads?
* Forum/newsgroup for discussion of new project ideas, proposals, current projects, etc...
* Wiki for project lists, project pages, permanent and evolving documentation
* Private CVS/Subversion tree for collaborative development
* Bugzilla instance for project-specific bug tracking, feature requests, etc...

== Timing & Staffing ==

The intention is to launch in time with the release of Firefox 2.0 and support the innovation and platform messaging.

For staffing:
* Basil Hashem for overall process management
* Startup/corporate fractional participation
* Fractional time from Mozilla engineers, IT, Release/Build, QA, marketing, executive
* Rely on existing shared IT services for Mozilla
* Potential engineering new hires

== Oversight & MetaWork ==

* Monthly and on-demand status reports will be generated for project tracking, highlighting accomplishments and documenting learnings
* Some PR & marketing needs to be done in order to drive traffic to the new site and get momentum

== Technical Process ==

'''''Stage 1: Sourcing ideas'''''

Mozilla "Prototypes" will be completely open for sourcing of ideas. They can come from anywhere including Mozilla employees, community contributors, startups/corporates, universities, marketing partners, research labs, the extended Mozilla circle, users, etc... The ideas will be documented and categorized onto a wiki or suggestion box application. This is a continuous process.

A rating system will be introduced in order to bubble up the most interesting ideas to the top.

Ideally, a project should be documented as a proposal that include a hypothesis that need to be tested, an idea that needs to be validated (or refuted), a technical feasibility, a design that need to be created, a comparison of alterate designs or approaches, or a question that needs to be answered. Projects should not be completely "open ended".

'''''Stage 2: Launching and Running Projects'''''

Labs will evaluate the project proposals and based on staffing and strategic interests select a handful of projects to be run simultaneously. The project proposal will be refined, staffing and duration will be set and necessary infrastructure (wiki, bugzilla, cvs, etc...) for each project will be created.

Here are some notes from mconnor on guidelines for how work on Firefox might flow:
* Form a small team - 2-3 hackers, 0.5 UI person, 0.5 visual/graphics person, and a triage/QA helper (optional)
* Firefox-related projects will not be run on the mainline or the trunk.
* Base work on most recent Firefox release branch, use build-config magic to replace Firefox pieces with forked bits.
* High risk/high reward work that doesn't belong on the main dev path (distracting from mainline development and testing)
* New features have a shelf life, either they are good enough for n+1 or they're not. If they're not, they get dropped aggressively.
* Little to no build team resources needed (tinderbox/nightly builds, milestones are just nightlies)
* Focus on rapid iteration over clean code (we can reimplement cleanly if the idea pans out)
* Successful features get ported to the product by the mainline team at the appropriate times

For UI-focused projects:
* Build prototypes using tools
* Draw information models and user task/data flow diagrams
* Consider user testing in a focus group

'''''Stage 3: Project Evaluation'''''

At the end of a project, the evaluation will take place to determine the lessons learned and future fate of a project.

== Mantras & Cautions ==
* "Ideas are nice but code and working prototypes rock!"
* "Don't show unfinished prototypes to stupid people"
* How to deal with current business feasibility constraints for an experiment?
* How to ensure that we focus on building and testing the solution rather than how to package it, clean it up and sell it to the organization

__NOTOC__

Fixing transparent PNGs

2007-03-29T05:08:48Z

Taken:

{{Delete|This page is inappropriate for this wiki.How about [http://en.wikibooks.org/ Wikibooks] --[[User:Taken|Taken]] 22:08, 28 March 2007 (PDT)}}

Sadly, a large percentage of Internet users use Internet Explorer for Windows as their primary web browser. Among other problems, this browser doesn't properly support [[w:en:Portable Network Graphics|PNG]] images with alpha channel transparency. This has given rise to the myth that ''IE doesn't support transparent PNGs''.

IE ''does'' support transparency in indexed-color PNG images in which a color is reserved for transparency: in most cases this is going to mean saving as 8-bit rather than 24-bit. This method forces sharp edges to the transparency, just like in transparent GIFs, but you'll feel more virtuous using PNGs instead of GIFs (which are still patent-encumbered in a few parts of the world, and are also generally a little bit larger in filesize.).

IE can also display full PNG transparency using the AlphaImageLoader. There is a cross-browser example of this at [http://www.nrkn.com/alpha/ http://www.nrkn.com/alpha/].

== Fixing PNGs with the Gimp ==

[http://www.gimp.org/ The Gimp] is a [[w:en:Free software|free program]] for manipulating digital images; it's available for Linux and Unix (including Mac OS X) and Windows.

If you're stuck with a 24-bit transparent PNG with an alpha channel and want it to be Internet Explorer-friendly, you can load it up in the Gimp and convert it to indexed mode. (Under the "Image" menu, highlight "Mode" and then select "Indexed...". The default settings of the window that pops up should be okay; hit "OK" and then save your new file.)

=== Nasty edges ===

Often this will produce ugly harsh edges, which you don't want. You want ''smooth pretty'' edges.

You can fake this for most purposes as long as you know what kind of backgrounds the image will cover; an icon or logo for a MediaWiki site will usually only sit over backgrounds of white, light grey, or light yellow. Before converting to indexed color, force the image to have a solid background by creating a new layer; fill it with color #eeeeee (light gray), and flatten the image. Use the select by color tool to select the gray and clear it to transparency (you might have to add an alpha channel first, I forget).

Now there are harsh edges between transparency and the very light gray halo around your pretty logo... when superimposed on the expected backgrounds this will look ''good enough''. It's not perfect, but hey.

Convert to indexed color and save.

''Note that these same steps work for making a GIF if you really want to. But, y'know, GIFs are bad or something.''

'''Alternatively''', with the Gimp you can make a normal (unindexed, RGB image with alpha channel) PNG and select the option to save the background-color. This way IE will display the saved background color while better browsers will display transparency as intended.

==Fixing PNGs with Paint Shop Pro==
These directions only apply for PSP v. 8. And maybe 7. I'm not really sure about that one, though. Load up the transparent PNG, and just like in the GIMP, create a #cccccc layer underneath. Then (this is the easy part) go to ''File''/''Export''/'''PNG Optimizer'''. Select "Palette-based", and then select the "Optimized Octree" palette, and then in the Transparency tab, select "Single-color transparency", and select "Areas that match this color". Make sure tolerance is 0. Click the colored box, and enter "#CCCCCC" in the HTML code box. Then, depending on the size of the file, you can choose to interlace it or not (your choice, but big files would be better smaller), and then save it to the location of your choice. Upload it to a wiki.

''Note:'' if a wiki has a different background color on their imageboxes, use it in the HTML code box rather than "#CCCCCC"

=== Optimizing download size ===

An 8-bit PNG (or GIF) will usually be about half the size of a 24-bit truecolor PNG of the same image. That's good!

You can also optimize download size by reducing the number of colors in the output and disabling dithering in the conversion, though don't do it at the expense of the picture looking good.

== Fixing PNGs in Photoshop ==

Well, I wouldn't. Photoshop screws up PNG output with things like bad gamma.

The only way to save an 8 bit png from photoshop is to use the export for web feature:
: ''File -> Save for Web'' (Control-Alt-Shift-S)

Otherwise, Photoshop insists on saving a 24 bit image, with an alpha channel if you use transparency.

In general, from Photoshop, whatever format you save to, it is a good idea to use Save for Web if the image is intended for the web.

QA/TDAI/Inventory

2007-03-29T04:56:08Z

Taken:

{{draft}}

=== Suites? Harnesses? Tests? ===

We all want quality to happen. How can we help? What is being run? What can I run something with? What does any of this mean? Not all questions are answered, but some.

This document has three sections:

# Test Harnesses - tools, designed to run tests. A harness may be targeted to a specific set of tests, or general to many kinds of tests. What test do you want to see run? Different harnesses could be used to run a given test. Which harness is better for which kinds of testing? <i>kinds of testing?</i>
# Test Suites - arbitrary groupings of test cases, roughly organized by functional area
# Test Infrastructure - the environments the test tools and test cases run in. This includes machine, operating system and physical location (ex: QA farm vs QA lab vs someone's desktop)

There are questions to be answered about any of our tests. If anyone has information or suggestions, please [mailto:rkiddy@mozilla.com let us know].

# What tests do we have now, how current are they and how they should be run? Should they be expected to pass?
# What features or modules need tests to be written for them? What are the requirements of the testing that should happen?
# What tools do we have now that can be used to write tests? What tools outside of mozilla have people used to build tests and test tools.
# Of the tests currently in existence, which of them are outside the "mozilla.org" umbrella? Which use resources from outside? What is the reliability and accessibility of these resources? Are there issues which keep us from keeping local copies?

Any questions and suggestions are welcome!

=== Criteria for Colors ===

<div class="note">'''NOTE''': that judgments are subjective and not "hard and fast". Caring enough to discuss will change a rating. Not caring enough to discuss is explanation enough.</div>

* Green: Generously defined now. Info is current or findable. Something is buildable and runnable by someone. There may still be obvious improvements needed.
* Yellow: Little may be known. Probably not completely broken. Work to bring current is unknown.
* Red: Obviously broken or missing. Info not findable. People not locatable.

= Test Harnesses =

{| class="fullwidth-table"
!Test Harness Name
!Brief Description
!Language Used
!Status of Harness
!Notes
|-
| MochiTest
| built by [mailto:sayrer@gmail.com sayrer] using the [http://www.mochikit.com MochiKit] framework
| JavaScript
| Automation being set up on QA Farm. Exec by community is possible.
| [[mdc:Writing MochiTest-based unit tests|mochitest]]
|-
| reftest
| comparison of two pages, via JavaScript and Canvas, for visual equivalency
| JavaScript
| runnable on built trunk. There is a list of [[mdc:reftest opportunities files|reftest opportunities]], but it is not clear if we want to use them.
| [[mdc:Creating reftest-based unit tests|reftest]]
|-
| xpcshell
| used by 40+ tests, plans for use by many more
| JavaScript
| recent care and feeding, very usable
| [[mdc:Writing_xpcshell-based_unit_tests|xpcshell]]
|-
| eggplant
|
| uses VNC for device-level visual comparisons
| Being used for automation of Smoke Tests suites in [http://litmus.mozilla.org litmus]
| [http://www.redstonesoftware.com/ redstone]
|-
| litmus
| Catalog of manual test cases. [[Litmus|Being developed]] to allow community to [http://litmus.mozilla.org/run_tests.cgi run] the manual smoke tests, BFT, FFT and L10n tests. [http://litmus.mozilla.org/search_results.cgi GUI to capture results] and provide feedback to the QA team. Reporting function to check test and platform coverage.
| English, German, French, etc.
| The place to be on Community Test Day! Still in refinement by [mailto:zlipton@mozilla.com zlipton] and [mailto:ccooper@deadsquid.com coop]. 2445 test cases, 1994 tester accounts with 845 active
| [http://litmus.mozilla.org litmus]
|-
| T*
| perf tests, runs in tinderbox
|
| running, passing, run by tinderbox
| [[MozillaQualityAssurance:Performance_Testing|wiki]]
|-
| test.js
| custom harnesses
| JavaScript
| an opportunity for consolidation
| [http://lxr.mozilla.org/mozilla/source/toolkit/components/feeds/test/test.js] [http://lxr.mozilla.org/mozilla/source/suite/common/history/history-test.js] [http://lxr.mozilla.org/mozilla/source/webtools/lxr/tests/syntax-highlighting/test.js] [http://lxr.mozilla.org/mozilla/source/intl/strres/tests/strres-test.js] [http://lxr.mozilla.org/mozilla/source/content/xslt/tests/buster/buster-test.js] [http://lxr.mozilla.org/mozilla/source/content/xslt/tests/XSLTMark/XSLTMark-test.js] [http://lxr.mozilla.org/mozilla/source/cck/muc/test/test.js] [http://lxr.mozilla.org/mozilla/source/js2/tests/js/dinkytest.js] [http://lxr.mozilla.org/mozilla/source/layout/tools/reftest/reftest.js] [http://lxr.mozilla.org/mozilla/source/js/tests/js1_2/regexp/test.js] [http://lxr.mozilla.org/mozilla/source/js/jsdj/test/jsdb.bat] [http://lxr.mozilla.org/mozilla/source/js/jsd/jsdb/test.js] [http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/tests/js/old/simpletest.js] [http://lxr.mozilla.org/mozilla/source/js/rhino/toolsrc/org/mozilla/javascript/tools/debugger/test.js] [http://lxr.mozilla.org/mozilla/source/extensions/webservices/interfaceinfo/tests/ifaceinfotest.js] [http://lxr.mozilla.org/mozilla/source/extensions/sql/sqltest/sqltest.js]
|-
| Spider
| crawls a site to specified depth, loading CSS, executing JS along the way.
| JavaScript
| used only for the [http://lxr.mozilla.org/mozilla/source/js/tests js/tests] by [mailto:bc@mozilla.com bc], et al, for JS testing
| [http://bclary.com/projects/spider/ bc]
|-
| build/make
| a [[Creating_StandAlone_Executable_Tests|standard for invoking stand-alone test executables]], and for integrating invocation of other harnesses into MoCo automated systems
|
| "make check" is accepted standard, being integrated with buildbot
| [http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaTest tinderbox]
|-
| XULUnit
| "XulUnit is a simple, yet powerful and easy to use framework for Unit Testing in XUL applications (XPFE)."
|
| any info known? please [mailto:rkiddy@mozilla.com share].
| [http://xulunit.mozdev.org xulunit.m.o]
|}

= Test Suites =

{| class="fullwidth-table"
!
!Test Suite Name
!Brief Description
!Test Harness(es)
!Status
!Last Info
|-
| style="background:#00ff00" |
| [http://lxr.mozilla.org/mozilla/source/js/tests/ js/tests]
| [http://www.mozilla.org/js/tests/library.html well-developed suite] of tests of the JavaScript language in [http://lxr.mozilla.org/mozilla/source/js/tests/ js/tests]
| [http://bclary.com/projects/spider/ SpiderMonkey] Runs on QA Farm. Stable and not necessary to use or share.
| Semi-automated. Plans to fully automate with Alice and Rob's help in Q1 2007
| Info is current. See [mailto:bc@mozilla.com bc], [mailto:alice@mozilla.com alice], [mailto:rcampbell@mozilla.com robcee].
|-
| style="background:#00ff00" |
| Security tests
|
| Custom framework. Runs on QA Farm. When bugs were filed, regression test cases are usually added.
| Semi-automated. Plans to fully automate with Eggplant in Q1 2007
| Info is current. See [mailto:bc@mozilla.com bc], [mailto:jruderman@gmail.com jruderman]. Definite opportunity to mine bugs for test cases.
|-
| style="background:#00ff00" |
| Automated Smoke Tests
| A "Smoke Test" is a quick, basic qualification.
| Eggplant. Runs on Tracy's machines. Tests for FFx 1.5 and 2.0
| Fully automated. Completed porting to Mac and Linux in Q4 2006. Plan to move execution to QA Farm in Q1 2007
| Info is current. See [mailto:twalker@mozilla.com tracy].
|-
| style="background:#00ff00" |
| Basic Functionality Tests (BFT)
| 130+ manual test cases, broadly covering major features
| litmus for [http://litmus.mozilla.org/show_test.cgi?searchType=by_category&product_id=1&testgroup_id=7 1.5] and [http://litmus.mozilla.org/show_test.cgi?searchType=by_category&product_id=1&testgroup_id=25 2.0]
| will be updated for FF3
| Info is current. See [mailto:marcia@mozilla.org marcia], [mailto:timr@mozilla.com timr].
|-
| style="background:#00ff00" |
| Full Functionality Tests (FFT)
| approx. 280 manual test cases, covering most features
| litmus for [http://litmus.mozilla.org/show_test.cgi?searchType=by_category&product_id=1&testgroup_id=2 1.0], [http://litmus.mozilla.org/show_test.cgi?searchType=by_category&product_id=1&testgroup_id=26 1.5] and [http://litmus.mozilla.org/show_test.cgi?searchType=by_category&product_id=1&testgroup_id=27 2.0]
| will be updated for FF3
| Info is current. See [mailto:marcia@mozilla.org marcia], [mailto:timr@mozilla.com timr].
|-
| style="background:#00ff00" |
| Localization Tests
| 15 test cases
| litmus for [http://litmus.mozilla.org/show_test.cgi?searchType=by_category&product_id=1&testgroup_id=10 1.5] and [http://litmus.mozilla.org/show_test.cgi?searchType=by_category&product_id=1&testgroup_id=39 2.0]
| engaged and open to design
| Info is current. Proposed designs and issues current in newsgroups. See [mailto:axel@mozilla.com axel]
|-
| style="background:#00ff00" |
| Software Update Suite
| approx. 50 tests, targeted to update process itself
| [http://litmus.mozilla.org/show_test.cgi?searchType=by_category&product_id=1&testgroup_id=38 litmus]
|
| Info is current. See [mailto:bc@mozilla.com bc].
|-
| style="background:#00ff00" |
| T*
| includes Tdhtml, Ts, Txul, [[Trender]] (aka Tgfx), Z, and mZ, [[Performance:Tinderbox_Tests|wiki for most T]]
|
| running, but not growing
| Info is current. Tests need transition to buildbot. See [mailto:rcampbell@mozilla.com robcee], [mailto:timr@mozilla.com timr].
|-
| style="background:#00ff00" |
| Accessibility
| [[Accessibility/qa]]
|
| Info is current. A lot is going on, but opportunities to automate are not as developed as they could be. See [mailto:aaronleventhal@moonset.net Aaron Leventhal].
|
|-
| style="background:#00ff00" |
| Update Checker
| validity of update mar files
| currently automated on release machines, moving to buildbot, [[MozillaQualityAssurance:Update_Checker|wiki]]
|
| Info is out of date. See [mailto:rhelmer@mozilla.com rhelmer].
|-
| style="background:#00ff00" |
| L10n checker/metadiff
| verify that :<ul><li>en-US build matches locale build</li><li>ensure no read-only files</li><li>show differences from last release</li>
|
| currently automated on release machines, moving to buildbot, [[MozillaQualityAssurance:MetaDiff|wiki]]
| Info is out of date. See [mailto:rhelmer@mozilla.com rhelmer].
|-
| style="background:#00ff00" |
| Tp2
| new page load tests
| "make check"/buildbot
| nearing complete automation
| Info is current. Being integrated into automation. See [mailto:alice@mozilla.com alice], [mailto:rcampbell@mozilla.com robcee].
|-
| style="background:#00ff00" |
| Download Checker
| verify integrity of major released
| manual, [[MozillaQualityAssurance:Download_Checker|wiki]]
| runnable, passing
| Info is current. See [mailto:bc@mozilla.com bc].
|-
| style="background:#00ff00" |
| L10N Search Verifier
|
| manual, [[MozillaQualityAssurance:l10n_Search_Verifier|wiki]]
| runnable, passing
| Info is current, but current plans are unclear.
|-
| style="background:#00ff00" |
| [http://lxr.mozilla.org/mozilla/source/content/xslt/tests/buster content/xslt/tests/buster]
| re-purposing of the Adobe Xalan tests.
| [[Custom Test Executables|custom executable/C++]]
| Driver is in mozilla, but test content is at Apache.
| Info is current, but current run occasionally. Need automation.
|-
| style="background:#00ff00" |
| DOM
| being transitioned into MochiTest
| browser and eyeballs?
|
| Info is currrent. More tests to be transitioned. See [mailto:robert@ocallahan.org roc], [mailto:rcampbell@mozilla.com robcee].
|-
| style="background:#00ff00" |
| CSS
| verify spec compliance
| reftest
| running, passing, needing much to be added
| Info is current. More tests needed. See [mailto:rcampbell@mozilla.com robcee], [mailto:dbaron@mozilla.com dbaron].
|-
| style="background:#ffff00" |
| XBL2
| [[MozillaQualityAssurance:Test_Development_Projects#Platform_Content_Area|wiki]]
|
| XBL2 still in design
| Info is current. [mailto:jonas@sicking.cc jonas]
|-
| style="background:#ffff00" |
| Browser/Content
| May be transitioned to reftest or MochiTest, as appropriate.
| [[Custom Test Executables|custom executable/C++]]
|
| Info is current. Several groups of tests need to be seperated, given TLC, automation.
|-
| style="background:#ffff00" |
| Embedding
| Tests seem fairly current but not building, why?
| [[Custom Test Executables|custom executable/C++]]
|
| Info is in source, but not sure of source for more info.
|-
| style="background:#ffff00" |
| Extensions
|
| [[Custom Test Executables|custom executable/C++]]
|
| Info is in source, but not sure of source for more info.
|-
| style="background:#ffff00" |
| Java Applets
| list suggested by Java team at Apple
| browser and eyeballs, [[MozillaQualityAssurance:Test_JavaApplets|wiki]]
| Just a list. No automation is currently in process.
| Info is current. See [mailto:rkiddy@mozilla.com ray].
|-
| style="background:#ffff00" |
| I18N
|
| [[Custom Test Executables|custom executable/C++]]
|
| Info is current, but not sure of approach to automation plans.
|-
| style="background:#ffff00" |
| Graphics
|
| [[Custom Test Executables|custom executable/C++]]
|
| Info is current, but tests will need to be made current. Match to external Cairo testing for relevance.
|-
| style="background:#00ff00" |
| HTML Parsing
| Will need to deal with WHATWG/html5lib tests {{bug|366936}}. The htmlparser/tests/html test vs a baseline, but a baseline has not been stored.
| [[Custom Test Executables|custom executable/C++]]
|
| Info is in source. Other source of info is unclear (perhaps [mailto:mrbkap@mozilla.com mrbkap]?)
|-
| style="background:#00ff00" |
| Acid2
| compliance tests from outside standards "watcher"
| manually executed, [http://www.webstandards.org/action/acid2/ Acid2 Browser Test]
| currently passing
| Info is current. See [mailto:timr@mozilla.com timr].
|-
| style="background:#ffff00" |
| XPConnect
| TestXPC -> "FAILED to get a JSRuntime"
| [[Custom Test Executables|custom executable/C++]]
|
| Info is in source, but not sure of source for more info.
|-
| style="background:#00ff00" |
| Layout/HTML
| 1800+ files. These can be transitioned, probably to reftest. HTML file groups: CellMapTest, FrameSetNav, SlideShow, attributes, block, css, formctls, frameset, printer, style, table, tags, xbl.
| "the old regression test suite" and reftest. Older tests will go to reftest.
|
| Info is current, but a lot of tests need TLC, automation.
|-
| style="background:#ffff00" |
| MathML
| Do mathematical glyphs display correctly on all platforms?
| "browsers and eyeballs"
| also using w3c.org site content
| Info is current, May be able to automate with reftest.
|-
| style="background:#ffff00" |
| Plugins
|
|
| Not known
| Info is in source, but not sure of source for more info.
|-
| style="background:#ffff00" |
| Java Plugin
|
|
| not current, dev may feel out of loop
| Info is current, but not sure of approach to automation plans.
|-
| style="background:#00ff00" |
| Networking
| 25 test executables, but all must be given parameters
| [[Custom Test Executables|custom executable/C++]]
|
| Info is in source, but not sure of source for more info.
|-
| style="background:#ffff00" |
| NSPR
| approx 150 test executables, most pass.
| custom executable/c
|
| Info is in source, but not sure of source for more info.
|-
| style="background:#ffff00" |
| RDF
|
| [[Custom Test Executables|custom executable/C++]]
| dsds (not being built), rdfcat, rdfpoll, triplescat (doc for invoke?)
| Info is in source, but not sure of source for more info.
|-
| style="background:#00ff00" |
| Security/NSS
| 26 tests, but not runnable without info
| [[Custom Test Executables|custom executable/C++]] and "make check"
|
| Info is current. NSS tests run externally. Need tests relevant to MoCo.
|-
| style="background:#00ff00" |
| XPCOM
| 28 custom executables, most pass, can be better documented, xpcom/tests/unit/test_pipe.js (xpcshell)
| [[Custom Test Executables|custom executable/C++]]
|
| Info is current, but not sure of source for more info.
|-
| style="background:#ffff00" |
| XPFE
| winopen.xul, runs but does not show final results
|
|
| Info is in source, but not sure of source for more info.
|-
| style="background:#ffff00" |
| XPInstall
| pre_checkin_trigger.html, runs in browser, passes
|
|
| Info is in source, but not sure of source for more info.
|}

= Test Infrastructures =

{| class="fullwidth-table"
!Test Infrastructure Name
!Brief Description
!Harnesses and Test Suites in the Infrastructure
!Status of the Instructure
!Notes
|-
| tinderboxen
| Continuous build engine for Mozilla source, much chronicled in song and fable.
| "make check", the results of which may not be verified
| see dynamic [http://tinderbox.mozilla.org/showbuilds.cgi Tinderbox] display
|
|-
| buildbots
| Continuous build engines, written in Python, cycling rapidly based on Bonsai checkins.
| "make check", reftest and MochiTest
| reported via [http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox Firefox] tinderbox
|-
| QA Farm
| some number of Windows, Linux and Macs. Details are not important. They should be a black box resource for developers to say "test this".
| "make check", reftest and MochiTest
|
|
|}

Community:MUGs

2007-03-29T04:36:01Z

Taken: use bug template

This is a discussion page for the idea of supporting Mozilla User Groups, that could be similar to groups like the Perl Mongers and such.

See related mozilla.org bug {{bug|327774}}

Commmunity:MUGs Mozilla User Groups

2007-03-29T04:34:40Z

Taken:

{{Delete|This page is not neede}}

#REDIRECT [[Commmunity:MUGs]]

Commmunity:MUGs

2007-03-29T04:33:48Z

Taken:

{{Delete|This page is not needed}}

#REDIRECT [[Community:MUGs]]

Firefox:3.0 Mac Performance

2007-03-29T04:30:34Z

Taken:

= Items =

* Fast [[JS Components]] (~10% mac startup? per shark)
* Incorporate [[Quartz]] (using work done by [[camino]])
* Fix the silly processor spike bug when a click is held

=== Comments [[User:Bugmenot]] ===

* Support for CoreImage
* Quartz through [http://cairograhics.org cairo], which will free us from maintaining ugly platform specific code and allows acceleration on [[linux]] with glitz as well as acceleration on windows with GDI+. Cairo is also LGPL/MPL licensed.

Mozilla2:GFXEvolution

2007-03-29T04:28:54Z

Taken:

''This was the plan in 2005''; see [[Mozilla2:GraphicsPlan]] for actual development in 2006.

Some can be done in parallel.

# Wrap [http://cairographics.org cairo] in "Thebes", thin [[Mozilla2:NewGFXAPIs|C++ wrappers]] over cairo APIs which can be used by advanced rendering customers --- [[SVG]], view manager --- when gfx/cairo is in use.
# Get gfx/cairo (an implementation of our current gfx interfaces based on Thebes) into working order.
# Work on gfx/cairo performance until it performs as well as gfx/win, gfx/mac and gfx/gtk on our normal Web workloads on modest machines (e.g., without GPUs). Will require significant work on cairo itself.
# Wherever possible, drop platform gfx implementations in favor of using gfx/cairo on the platform. Ideally we'll end up with just gfx/cairo and possibly some gfx implementation for embedded devices.
# With only one or two gfx implementations to deal with, clean up the legacy gfx interfaces, either by moving functionality to the new API wrappers, or by modifying the legacy interfaces in place.

The goal here is to be incremental but also tackle the riskiest, most questionable issues as early as possible (IMHO getting cairo to perform well on our platforms and workloads). Also as soon as we complete step 2 we can work on rich [[SVG]]/HTML/XUL integration with a unified rendering pipeline. Getting super-cool demos working soon is very important.

Bugs

2007-03-29T04:23:04Z

Taken:

{{Delete|Inappropriate for this wiki}}
Bugs should be reported via https://bugzilla.mozilla.org, a system which also will publish your email address and make it available to spammers.

==Possible bugs==
Below there are some possible bugs that users where unwilling to reported via bugzilla.

*firefox javascript [[mdc:Core_JavaScript_1.5_Reference:Global_Objects:Date:UTC]]
alert ( Date.UTC(2006, 5, 31) - Date.UTC(2006, 6, 01));
FF1.5.0.3 returns 0;

==See also==
*[[Bugzilla]]

Firefox:Development Integration

2007-03-29T04:16:57Z

Taken: link to XUL Planet directly instead of via a mozilla wiki article.

== Using Mozilla's JVM Development Platform to integrate XUL script support ==

*For those who have not been reading the Mozilla developers news, they want their end-users to be able to learn how and to create their own themes/extensions themselves for Mozilla products. Of course you can't do this without knowing basic Java and Mozilla's own XUL language based for the T-Bird Inbox, Mozilla, and Firefox web browsers. If we created it either internally to the application itself or as an XPI plugin extension creating a text based WYSIWYG editor for those who want to be able to create there own extensions/themes (although I would suggest making this an extension seeing not everyone is going to use this). We need to develope in the package itself (for those developing extensions), a pre-made template that will already load a blank app so that the user doesn't have to develope from scratch, currently what I'm already doing (as suggested by Mozilla) is to download an existing extension and/or theme and just recreate the XUL & JS files, then just re-package the XPI/JAR.

*Obviously the integration of this development package would not be for everyone, those who would want to create their own theme would need a program such as Photoshop, some basic knowledge of CSS, and even a little XUL for the .rdf/.xul files with those extensions.

*For those just beginning in XUL or who want to further their knowledge and know how, this is the best site I have found covering all and I mean ALL documentation on the XUL language. [http://www.xulplanet.com/references/elemref/ XUL Planet]

*So where does the JVM Development Platform (JavaScript Console Tool) come in?? Using a similar app like the one that we already have in the Mozilla and Firefox web browsers for editing JavaScript files is a great example what we could use for our XUL file creation tool. Sense we would be using Java and XUL we could even possibly integrate the two somehow.

*I will create diagrams and post them up here or something, as this may sound confusing being a text edit.

(This is just a brain storming idea, I don't have everything rock solid. I will start the architecture and development layout as for anyone who would like to help please feel free posting more replies. Again, this is just brain storming. Ideas of course are greatly accepted! I would be happy to work with anyone on this project!!)

--[[User:Mclark|Mclark]] 16:35, 22 Aug 2005 (PDT)Mike Clark mailto:mr_snazypants2006@hotmail.com

Firefox Development Integration

2007-03-29T04:15:02Z

Taken: redirect to Firefox:Development Integration

#REDIRECT [[Firefox:Development Integration]]

Template:Delete

2007-03-29T04:09:52Z

Taken:

<div style="border:1px solid orange;background-color:#FFFACD;padding:7px;">
This page is proposed for [[MozillaWiki:Requests for deletion|deletion]]: {{{1}}}.
</div>

<includeonly>[[Category:Delete]]</includeonly>

Template:Delete

2007-03-29T04:08:51Z

Taken:

<div style="border:1px solid orange;background-color:#FFFACD;padding:7px;">
This page is proposed for [[MozillaWiki:Requests for deletion|deletion]]: {{{$1}}}.
</div>

<includeonly>[[Category:Delete]]</includeonly>

Same Site Multiple Logins

2007-03-29T03:53:18Z

Taken: not suitable for wiki.mozilla.org

Feature request for Mozilla 3

2007-03-29T03:47:47Z

Taken: wrong page/place

Toolkit:Platform Specific Extension Components

2007-03-29T03:44:01Z

Taken: redirect to MDC

#REDIRECT [[MDC:Bundles]]

----

<span style="font-weight: bold; font-style:italic; color: green;">Support for platform directories was checked in and is now documented at http://developer-test.mozilla.org/en/docs/Bundles .</span>
--[[User:Jens.b|Jens.b]] 14:09, 8 Jun 2005 (PDT)

----

== Introduction ==

Some extensions are only intended for one platform, either because it uses things other platforms don't have (e.g. the Windows registry, like Linky does), or because they have binary components. Both the extension manager and services like http://addons.mozilla.org/ would benefit if extensions had some sort of [https://bugzilla.mozilla.org/show_bug.cgi?id=255619 platform-compatibility information as part of their metadata]. Note that themes are handled like extensions in some places, so they could include use such platform-compatibility information, too.

However, solving this issue is not enough, as two problems remain:

== Problem 1 ==

A growing number of Firefox and Thunderbird extensions use compiled, binary components. To keep the cross-platform nature Extensions usually have, you have to provide these binaries for each supported platform. Currently, all these are stuffed into the components/ directory. If you put binaries for several platforms into this components/ directory, you encounter the problem that Win32 loads not only .dll files, but also tries to load linux .so ones and fails with an error message.

The effect is that most extensions either
# are available in separate XPIs for each platform, posing problems for updating and http://addons.mozilla.org/
# include all platform binaries in one package and employ hacks to work around the problem

Needless to say, both alternatives aren't very appealing for extension authors.

Another problem is that binary components have to use the same [http://en.wikipedia.org/wiki/Application_binary_interface ABI] as the host application, or they won't work. Currently, there is no way to check or enforce this - when you install a linux-gcc2-built extension into a linux-gcc3-built application, things just break.

== Problem 2 ==

Some themes currently need a separate Macintosh version. While platform compatibility info as part of the metadata would make it impossible for a user to accidently install the wrong package, it would certainly be nice to be able to have one multi-platform theme package that includes some generic "base" files and some platform-specific ones.

== Conclusions ==

We need...
# components that are only loaded if they were compiled for the same platform AND using the same ABI as the host application (Firefox, Thunderbird)
# platform-specific theme jar files, default preferences, window icons and whatever ("this fileset for windows, that one for mac")

== The Solution ==

The notion of "platform file sets" is added by introducing a new subdirectory inside extension and theme packages: the '''platform''' directory. For each set of files that somehow depend on the target environment, it contains a directory named in one of the following ways:

* [OS_TARGET]
* [OS_TARGET]_[ABI]

'''OS_TARGET'''
: The platform the host application was compiled for, e.g. WINNT, Linux, Darwin (meaning Mac OS X)...
'''ABI'''
: The application binary interface the component was built with - e.g. gcc2, gcc3, mingw, msvc.

In each of these directories, the regular directory structure of the package (chrome, components, defaults for extensions, or the package dirs for themes) is repeated as needed.

The Extension Manager will install the package as usual - i.e. it extracts all files in the archive. The toolkit's nsXREDirProvider is enhanced so it automatically considers not only the extension's base directory, but also the matching platform directories.

A Firefox version built with MSVC for Windows would therefore try to load components and default preferences from directories listed below (if existing), and totally ignore any other subdirectories of platform/.
* components/
* defaults/preferences/
* platform/WINNT/components/
* platform/WINNT/defaults/preferences/
* platform/WINNT_msvc/components/
* platform/WINNT_msvc/defaults/preferences/

Older Firefox releases would also ignore everything in platform/.

== Example Extension Structure ==
myExt.xpi:
install.rdf
chrome/:
myExt.jar
defaults/:
preferences/:
myExt.js
platform/:
Linux_gcc2/:
components/:
mycomponent.so
Linux_gcc3/:
components/:
mycomponent.so
WINNT/:
defaults/:
preferences/:
myExt-win.js
WINNT_msvc/:
components/:
mycomponent.dll
WINNT_mingw/:
components/:
mycomponent.dll

== Resolved Issues ==

<dl>
<dt>What happens when we put chrome jar files in the platform directories - do they have to be listed in the main chrome.manifest? What if the current platform doesn't have that file, is it just ignored?

<dd> Each platform directory may have its own chrome.manifest:
<pre>chrome.manifest
platform/WINNT/chrome.manifest
platform/WINNT_msvc/chrome.manifest</pre>

<dt>What happens to preference files - what happens if two have the same name, in which sequence are they loaded, are prefs overwritten if specified in both the base prefs file and a platform-specific one?

<dd> Yes, we should read the "base" preferences first, then the platform-specific ones, and the pref system will automatically override any duplicate prefs.
</dl>

== Bug References ==

* https://bugzilla.mozilla.org/show_bug.cgi?id=253742<br>No way of installing platform specific XPCOM components (dll/so) based on user OS.
* https://bugzilla.mozilla.org/show_bug.cgi?id=294835<br>Need way of determining ABI in makefiles

[[Category:Junk]]

Toolbar customization

2007-03-29T03:30:09Z

Taken: wron

E4X

2007-03-29T03:06:32Z

Taken: correct a link to mdc and its description

This page is for material helpful to implementors of the E4X specification. As such, it is not intended to be a tutorial on E4X. For more information intended for users of E4X, see the Mozilla Developer Center [[MDC:E4X|E4X page]].

ECMA-357 2nd edition, the current version of the standard, can be downloaded from [http://www.ecma-international.org/publications/standards/Ecma-357.htm ECMA's site].

= Whitespace in literals =

I had a question about the handling of whitespace in E4X code, when XML.ignoreWhitespace is false. This came up when attempting to pass the Mozilla conformance test relating to the normalize() method [http://lxr.mozilla.org/mozilla/source/js/tests/e4x/XML/13.4.4.26.js (LXR version of test)].

: The testcase is buggy -- see {{bug|368459}}.

The conformance test constructs an XML object (which is specified by ECMA357 11.1.4). According to 11.1.4, we're using the production XMLElement, which contains XMLElementContent, which contains { Expression }, XMLMarkup, XMLText, and/or XMLElement. Now, XMLText contains (back to 8.3) SourceCharacters (minus { and < characters). SourceCharacters is defined to be a 1+ string of SourceCharacter, which refers back to ECMA262 5.1, which defines it as "any Unicode character."

According to 13.4.3.4, "If ignoreWhitespace is true, insignificant whitespace characters are ignored when processing constructing new XML objects." Nothing is said about false, but presumably those characters are ''not'' ignored in that case.

: Do note that even if it's not explicitly stated (might be, but I don't feel like rereading the E4X spec intro), the prose here is more intended to be informative than normative. (In other words, the numbered steps are the better guide here.) The only place XML.ignoreWhitespace is mentioned is in MapInfoItemToXML, which is pretty clear about its effects.

Since XMLText can contain whitespace (any Unicode character), I'd say this means that an XML literal initialized when XML.ignoreWhitespace = false can contain whitespace and therefore will contain text nodes consisting of only whitespace characters.

: Correct.

If that's right, the conformance test is wrong as I see it, because it deletes any nodes consisting solely of whitespace (which, as far as I can tell, means that they did not exist after the initializer executed). And as I see it, when ignoreWhitespace is false, those text nodes exist in the resulting document.

One thing I don't like about my interpretation is that it means that platform effects come into play. Because, as I understand it, ECMAScript allows theoretically any combination of CR/LF to signal the end of a line (along with some more obscure terminators with which I am not familiar; see ECMA262 7.3), it means that our XML document would contain CR/LF in JavaScript composed on a DOS platform, CR if composed on a Mac OS 9, and LF if composed on *nix.

: Normal linebreak processing doesn't occur in E4X literals -- a CR is a CR, an LF is an LF, etc. Yes, tho, the platform on which a script is written thus does affect the script's semantics when using E4X literals containing line breaks -- those who care often might not need to adapt (you might want CRLF endings precisely because you're on Windows), and since white space isn't a typical task to be attacked by XML-using programmers, it probably wasn't worth the effort to invent some hack to make whitespace not affect semantics.

As LF is the most XML-ish, my implementation currently converts the underlying terminators to LF (I think; I should check). I think most XML parsers do this as well, but I should check that as well.

: I seem to recall something about LF never appearing in an XML document unless inserted with an entity, but I could be wrong.

So what's the right answer here? --[[User:Inonit|Inonit]] 11:58, 23 October 2006 (PDT)

: Anyway, the problem you describe is with the testcase and is being handled in {{bug|368459}}. --[[User:Waldo|Waldo]] 22:02, 27 January 2007 (PST)

Accessibility/Firefox3

2007-03-29T03:02:11Z

Taken: add backlink

< [[Accessibility]]

Meta bugs we (very ambitiously) want to address for [[Firefox3]].

To use these meta bugs, you have several choices:
# Go to http://bugzilla.mozilla.org and use the meta bug alias instead of a number when you search for a bug. The aliases are listed below and are much easier to remember.
# Just use the supplied link on this chart
# Use the Firefox 3 meta bug ([https://bugzilla.mozilla.org/showdependencytree.cgi?id=fox3access&hide_resolved=1 fox3access]) and you will see the other meta bugs (HTML, XUL, ATK, etc.) listed under that.

{| class="standard-table"
! Alias
! Descirption
|-
| [https://bugzilla.mozilla.org/showdependencytree.cgi?id=fox3access&hide_resolved=1 fox3access]
| Firefox 3 accessibility bugs (contains all the other meta bugs listed below)
|-
| [https://bugzilla.mozilla.org/showdependencytree.cgi?id=atk&hide_resolved=1 atk]
| ATK specific bugs
|-
| [https://bugzilla.mozilla.org/showdependencytree.cgi?id=ia2&hide_resolved=1 ia2]
| IAccessible2 bugs
|-
| [https://bugzilla.mozilla.org/showdependencytree.cgi?id=htmla11y&hide_resolved=1 htmla11y]
| HTML accessibility bugs
|-
| [https://bugzilla.mozilla.org/showdependencytree.cgi?id=texta11y&hide_resolved=1 texta11y]
| Accessible text, hypertext and editable text bugs
|-
| [https://bugzilla.mozilla.org/showdependencytree.cgi?id=dhtmla11y&hide_resolved=1 dhtmla11y]
| DHTML accessibility (ARIA support)
|-
| [https://bugzilla.mozilla.org/showdependencytree.cgi?id=xula11y&hide_resolved=1 xula11y]
| XUL accessibility bugs
|-
| [https://bugzilla.mozilla.org/showdependencytree.cgi?id=chromea11y&hide_resolved=1 chromea11y]
| Firefox UI accessibility bugs
|-
| [https://bugzilla.mozilla.org/showdependencytree.cgi?id=themea11y&hide_resolved=1 themea11y]
| High contrast theme bugs
|-
| [https://bugzilla.mozilla.org/showdependencytree.cgi?id=fox3key&hide_resolved=1 fox3key]
| Key navigation and focus bugs
|}

Accessibility

2007-03-29T03:01:50Z

Taken: /* Mozilla Accessibility Wiki */ add link to Accessibility/Firefox3

= Mozilla Accessibility Wiki =

*[[Accessibility/Attributes|AT-SPI Attributes]] - proposed AT-SPI attribute support.
*[[Accessibility/Datatypes|ARIA Type Attributes]] -- proposed ARIA data type attributes to object attribute mapping
*[[Accessibility/AT-Windows-API|Gecko Info for Windows Accessibility Vendors]] - this FAQ explains how makers of Windows screen readers, voice dictation packages and magnification software can support Gecko-based software.
*[[Accessibility/IA2ToGecko|Mapping IAccessible2 to Gecko]]
*[[Accessibility/XForms|XForms Accessibility]] - AT API support for XForms elements.
*[[Accessibility/csun2007|CSUN 2007]] - Mozilla CSUN 2007 Activities
*[[Testing Mozilla applications for Accessibility]] - Specification for mozilla Accessibility Testing
*[[Accessibility/Firefox3|Firefox3]]

Deployment:Deploying Firefox

2007-03-29T02:54:01Z

Taken: add backlink

< [[Deployment]]

== Deploying Firefox ==

Many people are using Firefox at home, and many also want to use it at work or see it on public computers such as at libraries or Internet Cafes. This article provides links and references to issues that might come up when considering or executing a Firefox deployment plan. It describes a wide variety of tools and features available that can be to deploy Firefox and centrally manage and control the use of Firefox in enterprise, business, education, and a variety of large and small organizational settings.

== The Rational for Deploying Firefox inside Organizations and Institutions ==

*It is interesting to note that Firefox market share in corporate environments appears to be pretty closely tracking with the increased use of Firefox in the general internet population. Firefox use inside many organization often starts with IT, web development teams, and engineering departments and then spreads to other departments and individual users.
*Concerns about security is a strategic reason some organizations move to Firefox exclusively, or set up support support for multiple browsers.
* Many users choose Firefox when it is offered inside their organization, or go around IT policies because it makes them more efficient and more productive in accessing information on the web. They take advantage of firefox features such as tab browsing, rss feeds, and integrated search to get more done, faster.
* Some organization also chose Firefox as a tool to assist in ensuring development of internal applications and documents comply with web standards, and that the organizations do not get locked into proprietarty document formats that could become difficult or costly to support. If your applications and content works in Firefox its highly likely they will work in other browsers, and open up possibilities that ensure your internal organizational content is searchable and useful with other applications that support standards.
* Firefox can also be customized and extended to meet specific needs of your organization by creating addon extensions or building on the Firefox platform.

== Marketshare in the Enterprise and Business ==

July 06 Marketshare among IT workers visiting Janco
http://www.e-janco.com/browser.htm

<br>October 30, 2006 - The New Browser Wars: Firefox vs. Internet Explorer
<br>http://www.newsfactor.com/story.xhtml?story_id=13200C4PLUMO
"Jupiter survey showed that 26 percent of companies with more than 250 employees allowed their employees to install Firefox in 2005. By 2006, that number had jumped to 44 percent."

February 13, 2006 - Deployments at IBM, Boeing and Fidelity Investments
http://www.computerworld.com/softwaretopics/software/story/0,10801,108622p3,00.html
http://www.computerworld.com.au/index.php/id;453717301;fp;2;fpid;2
14% of Surveyed IT Managers had multi browser deployments going on in there companies.

March 22, 2005 Firefox explorers
This expansive article covers the advantages of using open source and Firefox software for business. When Bill Robertson decided last year to switch 450 workers and 100 desktops at De Bortoli Wines to the open source Firefox web browser, he had the company's future in mind.
http://www.theage.com.au/articles/2005/03/21/1111253920087.html?oneclick=true

== Security ==

<br>Independent Security Research teams such as US-CERT (US Dept. of Homeland Security) have for several years suggested supporting and using Firefox and other browsers as protection measure and response to critical problems with Internet Explorer. Here are a variety of references:

<br>June 2004 https://www.kb.cert.org/vuls/id/713878
<br>http://www.cert.org/tech_tips/securing_browser/
<br>http://www.cbsnews.com/stories/2004/07/05/scitech/pcanswer/main627500.shtml
<br>http://news.zdnet.com/2100-1009_22-5250697.html
<br>http://www.washingtonpost.com/wp-dyn/articles/A6746-2004Jun25.html

<br>http://www.sans.org/top20/?portal=1563ee22b1a8bd138f0f420caec8d02c -- "...Exploit code for many of the critical Internet Explorer flaws are publicly available. In addition, Internet Explorer has been leveraged to exploit vulnerabilities in other core Windows components such as HTML Help and Graphics Rendering Engine. Vulnerabilities in ActiveX controls installed by Microsoft or other vendor software are also being exploited via Internet Explorer... "How to Protect against These Vulnerabilities?... Consider using other browsers such as Mozilla Firefox that do not support ActiveX technology...."

<br>November 6, 2006 - Attackers dig into [IE] zero-day flaw
<br>http://news.com.com/Attackers+dig+into+zero-day+flaw/2100-1002_3-6133028.html

03 Jan 2006 Open source's speed, Firefox's security wows Fidelity
http://searchopensource.techtarget.com/originalContent/0,289142,sid39_gci1155599,00.html
<br> "The Mozilla Firefox browser was an eye-opener, added Mike Askew, who also works in the technology center. A head-to-head comparison of Firefox and Internet Explorer showed that both had about the same level of security vulnerability, but ''the time needed to fix vulnerabilities in Firefox was much less,'' Askew said. That experience led Fidelity to look at open source more intently."
--also prediction of Open Source used in 25% of business software investments by 2010

<b>Evaluating days of Vulnerability as the best metric for assessing risk in browsers.</b>

Several independent studies have shown that Firefox keeps users at risk of serious browser exploits a smaller amount of time than with Internet Explorer. For more than 3 years Mozilla and Firefox have a consistent track record for delivering security fixes faster than other browser vendors and reducing the risk to users.

2004

A Year Of Bugs http://bcheck.scanit.be/bcheck/page.php?name=STATS2004&page=1

Executive Summary
http://bcheck.scanit.be/bcheck/page.php?name=STATS2004&page=5
004 was pretty hard for Internet Explorer users. The domination of Internet Explorer made it a preferred target for both malware writers and security researchers, creating a steady stream of vulnerabilities. Windows XP Service Pack 2 released on August 9, 2004 did not seem to alter this trend.

In 2004 Mozilla had the shortest "exposure period" of the three browsers compared. The growing popularity of Mozilla and Firefox was at least to some extent due to better security it currently provides to its users. However as Mozilla browsers become more common they are bound to attract attention of malware writers. It would be interesting to see how well Mozilla will do security-wise when its user base approaches that of Internet Explorer.

http://bcheck.scanit.be/bcheck/page.php?name=stats2004
http://bcheck.scanit.be/bcheck/page.php?name=STATS2004&page=3
http://bcheck.scanit.be/bcheck/page.php?name=STATS2004&page=4

2005

Mozilla averaged about 21 days before it issued fixes for flaws in Firefox, compared with the 135 days it took for Microsoft to address problems in Internet Explorer.
Web Browser Vulnerabilities Calendar
Click the image for a look at the length of time Firefox and IE were vulnerable to known flaws in 2005.

For at least 38 days in 2005, IE was vulnerable to unpatched critical security flaws that were being exploited actively by viruses, worms and spyware. For at least 256 days last year, Internet Explorer contained unpatched vulnerabilities where the exploit method had been publicly disclosed but was not necessarily being used.
http://blog.washingtonpost.com/securityfix/2006/02/2005_patch_times_for_firefox_a.html
http://www.washingtonpost.com/wp-srv/technology/interactives/browsers/

2006

For a total 284 days in 2006 (or more than nine months out of the year), exploit code for known, unpatched critical flaws in pre-IE7 versions of the browser was publicly available on the Internet. Likewise, there were at least 98 days last year in which no software fixes from Microsoft were available to fix IE flaws that criminals were actively using to steal personal and financial data from users.

In contrast, Internet Explorer's closest competitor in terms of market share -- Mozilla's Firefox browser -- experienced a single period lasting just nine days last year in which exploit code for a serious security hole was posted online before Mozilla shipped a patch to remedy the problem.

http://blog.washingtonpost.com/securityfix/2007/01/internet_explorer_unsafe_for_2.html
http://www.washingtonpost.com/wp-srv/technology/daily/graphics/index20070104.html
Mozilla's Firefox browser -- experienced a single period lasting just nine days last year in which exploit code for a serious security hole was posted online before Mozilla shipped a patch to remedy the problem.

<b>Security Features</b>

Datamation’s readers have taken notice, choosing Firefox – narrowly – to win its Product of the Year award in the Anti-Spam category.

http://itmanagement.earthweb.com/article.php/3662741

== Extending Firefox for Enhanced Productivity ==

<br>The Very Best Firefox Extensions for Entrepreneurs
<br>http://www.greatbigpodcast.com/2006/10/05/very-best-firefox-extensions-for-entrepreneurs/

== Firefox Customization (CCK and Repackaging Tools) ==

The Firefox Client Customization Kit (CCK) was designed as a successor to two Netscape products, CCK, and Mission Control Desktop (MCD). These two products were used to customize Netscape browsers for deployment for ISPs (CCK) and enterprises (MCD).

The goal of the Firefox CCK is to provide an extension that can be deployed with Firefox that does most basic customizations.

More information is available at http://www.mozilla.org/projects/cck/firefox.

Information on the release repackaging tool is available here http://benjamin.smedbergs.us/release-repackager/

== Centralized Settings Management and Control==

The core technology in Firefox and Thunderbird contains a feature called "Mission Control Desktop/Auto Config" that can be used to centrally manage Browser and Mail configuation settings for the client software that is deployed across and organization. More documenation on this feature can be found at: http://developer.mozilla.org/en/docs/MCD%2C_Mission_Control_Desktop_AKA_AutoConfig and http://developer.mozilla.org/en/docs/Automatic_Mozilla_Configurator:Locked_config_settings

Most of the controls are carried out via the preference system. An overview of the this system can be found at http://www.mozilla.org/catalog/end-user/customizing/briefprefs.html
http://www.xulplanet.com/tutorials/xulqa/q_prefs.html

Extensive lists of preferences can be found at:
http://preferential.mozdev.org/preferences.html

Some customization ideas can be found here
http://www.mozilla.org/support/firefox/tips

This article also talks about controlling other features such as bookmarks and history and an approach to "Securing Mozilla in the Public Library": http://tln.lib.mi.us/~amutch/pro/mozilla/

== Installer Options ==

Large Oranizations have a variety of software deployment systems. In most cases the Firefox installation package can be wrapped inside these deployment systems.
Some groups have packaged the firefox installer inside a MSI package to do their deployments. The firefox installation program can be wrapped inside these deployment systems. Two installer options are valuable in these set ups.

FirefoxSetup.exe /ms (for mode-silent)

or

FirefoxSetup.exe /ma (auto-mode, hands-free but visible)

Another installation option ( /ira ) might be useful in these scenarios as it keeps the program from running after the install has completed.

Some changes were made in Firefox 2 to modify installer command line options. Information on those changes is here: http://wiki.mozilla.org/Installer:Command_Line_Arguments

== Deployment Tools ==
Automated deployment of Firefox with extensions, themes, and pre-configuration
http://firefox.dbltree.com/

Firefox ADM (Active Directory deployment)
Manage Firefox settings through Group Policy and Active Directory.
http://homepages.ed.ac.uk/mcs/FirefoxADM/Readme.htm

== Software Update ==

Mozilla offers automated updates of security patches and bug fixes for Firefox and Thunderbird though its software update system. You can choose to use this system or modify the firefox configuration to turn software updates off and gain more control over the update process. An overview of the software update system can be found at http://wiki.mozilla.org/Software_Update

== Companies ==
List of companies and contacts who can help with your evaluation, pilot projects, and deployment of Firefox or Thunderbird across your organization is provided below.

[http://www.wayforth.co.uk Wayforth] - London, UK
<br>
[http://www.browsergarage.com Browser Garage] - Mountain View, CA
<br>
[http://www.ibm.com IBM] - Austin, TX - contact [mailto:mkaply@us.ibm.com Michael Kaply]

We are also interested in hearing about your success stories or problems at partners@mozilla.org

== Licensing/Distribution Terms and Conditions ==

The Firefox End User License can be found here:
http://www.mozilla.com/en-US/legal/eula/

and more information about logo and trademark use can be found here: http://www.mozilla.org/foundation/trademarks/

== Export Control Information ==

Companies looking to provide Mozilla Software outside the United States often ask about Export Control provisions.

The Export Notice can be found at
http://ftp.mozilla.org/pub/mozilla.org/security/export-notice

In addition, the CCATS number makes it easier for companies to file when they included NSS or Mozilla Applications like Firefox, which use NSS. This CCATS filing covers all the crypto operations used in the Mozilla code base, including SSL and S/MIME.

The reference number for export filings is CCATS G023895. Strictly speaking, we did not have to file for a CCATS number because the NSS crypto code is "publicly available" and the binaries are built from purely open source software. More information on exporting products made from Open Source can be found here https://www.bis.doc.gov/encryption/enc.htm and here http://www.access.gpo.gov/bis/ear/ear_data.html - Part 740. Section §740.13(e) is on page 30 of the PDF.

We strongly caution you not to act on your personal reading of export regulations. They are complex and loaded with history, precedent, and context which often require interpretation from a qualified attorney.

Most questions about features provided by Mozilla's security library are contained in this document
http://www.mozilla.org/projects/security/pki/nss/nss-3.9/nss-3.9-algorithms.html

== Other Links ==

Collection of other random thoughts, press, and other articles on Firefox Deployments in Enterprise and Large Organizations

<br>http://del.icio.us/chofmann/enterprise
<br>http://del.icio.us/chofmann/firefox-deployments
<br>http://mozillaenterprise.mozdev.org/information.html
<br>http://wiki.mozilla.org/Firefox:1.5_Institutional_Deployment
<br>http://www.sanduskycomputers.com/downloads/fxcorp/
<br>http://fxcorp.sanduskycomputers.com/
<br>http://corporatefirefox.blogspot.com/
<br>http://firefox.dbltree.com/
<br>http://varun21.blogspot.com/
<br>http://www.frontmotion.com/Firefox/

[[Category:Firefox]]

Download Size

2007-03-29T02:50:24Z

Taken: add backlink

< [[Firefox#Firefox 2.0 (Bon Echo) Plan|Firefox]]

= Download Size =

== Background ==

Download size is an important factor in adoption. Keeping the download size small, especially below a mental barrier like 5.0 MB keeps Firefox in the class as "simple utility applications" and is downloaded without as much hesitation by users. It also allows clever marketing ala Asa's "It's like downloading an MP3"

To maintain a trim download size as new features and compiler requirements arrive, we must develop strategies to make our existing code better and cleaner.

Keeping a compact download size should be on the mind of every engineer on the Firefox project, just like accessibility and internationalization.

== Studies ==

== Strategies ==

* trim down InternetSearchService
* remove unnecessary developer-only components (DOM inspector, JS console)
* remove unnecessary xpinstall components
* better 7zip tuning
* trim the installer (currently rather bloated)
* xulrunner installer that downloads firefox.xap
* remove more unnecessary chrome and xpfe cruft (e.g. browserinstance)
* etc.

Debugging a hang on Mac OS X

2007-03-29T02:43:59Z

Taken: redirect to MDC

#REDIRECT [[MDC:Debugging_a_hang_on_OS_X]]

[[Category:Junk]]

Mozilla 2:Obsolete APIs

2007-03-29T02:28:06Z

Taken: + Category:Mozilla 2, Mozilla 2

< [[Mozilla 2]]

See [[Gecko:Obsolete API]], for APIs that are already considered obsolete. We should aspire to remove these from [[Mozilla 2]].

==== Process Goals ====

A lightweight [http://en.wikipedia.org/wiki/Request_for_Comments Request For Comments] protocol seems appropriate given the wide audience of Mozilla platform developers. We need to reach out to hackers whose work is hosted at [http://addons.mozilla.org AMO], [http://mozdev.org mozdev.org], and other such sites. We should try to reach the [http://weblogs.mozillazine.org/roc/archives/2006/12/xul_dark_matter.html XUL Dark Matter] bodies out there on the galactic rim. The goal should be to propose and discuss with plenty of time for two-way communication leading to consensus on which APIs go away, what their replacements are, and what new APIs are needed that we haven't already planned.

Comments and contributions welcome.

[[User:Brendan|/be]]

[[Category:Mozilla 2]]

Mozilla 2:Embedding APIs

2007-03-29T02:26:42Z

Taken: + Category:Mozilla 2, + link Mozilla 2

< [[Mozilla 2]]

==== Choices ====

# Use OS-default or otherwise dominant embedding APIs
## Epiphany's Gecko GTK widget for Gnome
## WebKit/WebCore APIs for Mac OS X
## MSHTML COM APIs for Windows, or .NET equivalents if necessary (we should strive to maintain, and even to extend, [http://www.iol.ie/~locka/mozilla/mozilla.htm Adam Lock's work]).

# Use a cross-platform embedding API
## Our own XPCOM-based API set
## WebKit/WebCore APIs
## MSHTML? Non-starter on non-Windows, I think

# Hybrid approaches, e.g.
## Use MSHTML COM APIs for embedding, navigation, etc. but use standard DOM (XP)COM APIs for the DOM.

Contributions welcome here, please start and cite (with Google Groups links) newsgroup threads as needed.

[[User:Brendan|/be]]

===Notes===
Using the OS-Default may also have the benefit of easier development for embedders. For example, on Windows, C++ APIs are not the easiest to work with anymore. C# and .NET languages would favor .NET wrapper or COM wrapper.
[[User:MarkFinkle|MarkFinkle]] 22:19, 9 March 2007 (PST)

[[Category:Mozilla 2]]

Mozilla 2

2007-03-29T02:21:21Z

Taken: + Category:Mozilla 2

(See [[Mozilla2:Home_Page | the 2004-era Mozilla 2 pages]] for older ideas.)

=== Ends ===

Current thinking on goals, initially pitched in [[User:Brendan | Brendan]]'s [http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozilla_2.html Mozilla 2 blog item], consists of these major bullet items:

* Clean up our APIs to be fewer, better, and "on the outside" of Gecko, with symbol visibility strictly limited to public APIs.
* Based on these APIs and supported embedding scenarios, support intentional Gecko embedding in a first-class way.
* Simplify the Mozilla codebase to make it smaller, faster, and easier to approach and maintain.
* Take advantage of standard C++ features and fast paths instead of XPCOM and ad hoc code.
* Develop [http://developer.mozilla.org/es4/ JS2] with Adobe folks on top of [http://weblogs.mozillazine.org/roadmap/archives/2006/11/project_tamarin.html Tamarin].
* Optimization including JIT compilation for JS2 with very fast DOM access and low memory costs.
* Tool-time and runtime enforcement of important safety properties including memory safety and confidentiality properties for both XUL and the Web.

What these mean in detail is mostly "to be decided", but we should try to say what we don't mean:

* We won't rewrite the Mozilla codebase by hand.
* We won't gratuitously break API compatibility ("some of our APIs are fine, thank you").
* We won't drop XPCOM completely; we may even have configurable Mozilla 1 XPCOM compatibility.
* We won't bring up Mozilla 2 on mobile devices (but volunteers are welcome to port early and often; Mozilla 2 will fit on such devices much more easily than Mozilla 1 code does).

The goals boil down to competing more effectively with ourselves, with [http://webkit.org Webkit], and even with IE and Opera, for all three of the Web, XUL (or equivalent "widget" or "rich client platform" comparable), and C++ embeddable HTML rendering engine platforms. We should aspire to beat the competition on major time, space, and ease-of-use axes, not just show or place.

=== Means ===

The goals are ambitious, and unrealistic without new tools and approaches to the code. Here are some of the major levers we will use to move mountains.

==== Tasklist ====

* Import final dirlist into Hg (Q107)
** Benjamin/Brendan
* Begin refactoring work/DeCOM/API work (Q107)
** Get tools good enough for broad use (Taras)
** Develop hitlist of areas to refactor (Taras/Brendan)
** Plan for refactoring DOM APIs (JST)
* Complete ES4 spec and ref impl (Q207):
** Graydon+Brendan
* Begin Tamarin/SM integration (Q307)
** Extract GC from Tamarin (e.g. remove all fp dependencies) (??)
** Ensure GC/Taramin compiles/runs on all platforms
* Rich Graphics Plan (Q207)
** Video Prototypes (Chris D)
** SVG/Canvas Plan (??)
** Accelerated Graphics Plan (??)
** OpenText Improvements Plan (Pav)
* Security Plan (Q207)
* Layout Plan (Q207)
* <del>Finalize choice of VCS and implement</del>

==== Timeline ====

* Q107 - Kickoff of project
** VCS up and ready for checkins
** Major areas of focus identified
** Owners for each area identified
* Q207
** ES4 Spec and Ref Impl Complete
** Plans flushed out for each major task area
** Refactoring checked in
* Q307
** Tamarin GC Building on all major platforms
** First prototype of Tamarin
** Design/Prototypes done for each major area
* Q407
** First Alpha of Moz2/Gecko2/Fx4 released
* Q108
** Fx4 Alphas
** All Major design work done
* Q208
** First Fx4/Moz2 Beta
* Q308
** Betas
* Q408
** Moz2/Fx4 Ship

==== A Better VCS (Brendan/Preed) ====

See [[VersionControlSummit2006|the great Version Control System shoot-out]]. We need a better VCS because Mozilla 2 will require more sweeping changes, and more experiments which must be run in parallel, than anything we've done so far. So we need at least

* better, cheaper branching
* better merge algorithms for updating and landing branches
* decentralized operation (no master repository with slave workareas)
* good merge-from-CVS capability to track the Mozilla 1.9 trunk where possible
* great performance on Windows (this rules out cygwin-ported Linux VCSes)

See [http://weblogs.mozillazine.org/preed/2006/11/version_control_system_shootou.html preed's Mortal Kombat] salute and look for news on his blog.

An important aspect to get straight is the branching topology. We will have many unstable branches running concurrently during Moz2 development. Generally for each task you want sub-task branches (possibly per-author or per-feature) plus a task-integration branch that your group tries to keep building and working most of the time. The ability to chain a new branch to a new buildbot, with a minimum of fuss, is very helpful.

==== ES4 ====

* Ref implementation complete June 07
* Merge Tamarin in existing JS APIs
* Tamarin Performance Improvements (see above)
* JS Trust labels

By combining APIs, code, and ideas from [http://lxr.mozilla.org/mozilla/source/js/src SpiderMonkey] and [http://lxr.mozilla.org/mozilla/source/js/tamarin Tamarin], we will build a [http://developer.mozilla.org/es4 JS2] virtual machine as part of Mozilla 2. The Tamarin code contribution is a big boost to this effort, and we intend to extend it, not copy code from it. But we need more that today's Tamarin in order to avoid certain pitfalls. We will probably need all of these:

* Dynamic optimizations for untyped JS (both Web and XUL JS -- we won't require all XUL JS to be annotated with types).
* Profile-directed Ahead Of Time compilation for critical methods (in lieu of XUL FastLoad, to avoid taking a startup performance hit).
* Fresh thinking and hacking for VM-based security, learning from [[Security:Bibliography|recent security research]].

We hope to self-host a JS2 compiler on the VM, but if performance can't match or beat the competition (including today's SpiderMonkey), we will have to consider:

* Native compiler front end.

While "it would be nice" (sincerely; but also, these are famous last words) to optimize the VM such that the self-hosted compiler beats a C or C++ hand-crafted compiler, we cannot put purity ahead of performance. The trade-off for Tamarin's embedding in the Flash Player is different: offline compilation via the Flex SDK is the rule there, and the self-hosted compiler need only be fast enough for <code>eval</code> requirements (which will be novel to Flash in a future release).

Current DOM security checks use the [[Security:Scattered Security Checks]] model. For Mozilla 2, in order to JIT DOM calls efficiently, we need either [[Security:Security Checks In Glue]] or [[Security:Wrapper-based Checks]]. To support "mashups in the browser" and [http://www.w3.org/TR/XBL XBL2], we may need to support data-tainting with static flow analysis as well as dynamic taint propagation.

==== Semi-automated refactoring work/Oink ====

[[Static Analysis]] via [[FirefoxSummit/2006/ProposedSessions/Oink|Oink]] will play an important role, we think, in partially or fully automating

* deCOMtamination, including getting XPCOM completely out of the middle of Gecko
* static data-tainting checks to uphold confidentiality properties
* conversion to exception-safe code, and holding the line on exception safety
* conversion to C++ exceptions, possibly including a new XPCOM C++ binding
* identification of C++ ripe for conversion to JS2.
* conversion from ad-hoc or Mozilla-private APIs to standard C++ APIs
* simple metrics of code complexity, to be regularly compared to other open source projects

Other good ideas for Oink-based tools should be noted on [[Static Analysis]]. The "conversion" items above will use the to-be-written (but proven-in-concept) pattern-matching patch-generating tool discussed at [http://weblogs.mozillazine.org/roadmap/archives/2006/11/oinkbased_patch_generation.html another this blog post].

==== Embedding API Design ====

* [[Mozilla 2:Embedding APIs]]
* [[Mozilla 2:Obsolete APIs]]

==== Rendering Performance ====

==== Graphics/Advanced Rendering ====

* Get rid of remnants of old gfx
** convert all paint methods to take gfxContext instead of nsIRenderingContext
** optimize API usage, e.g. take advantage of new clipping/transform capabilities
* Add optional acceleration using OpenGL (or Direct3D)
** Involves work to make widget layer 3D-aware
* Add video capabilities to platform, combined with hw accel and complex transform capability
* Make 3D a first-class citizen of platform
** any 2D element should render correctly under an arbitrary 2D transform
* Tighter integration between image decoding and rendering
** decode-on-render
** SVG as image

==== Security ====

[[Category:Mozilla 2]]

Mozilla 2

2007-03-29T02:16:09Z

Taken: markup improvment, no content change

CycleCollector/CCStatus-2007-03-16

2007-03-26T12:26:45Z

Taken: correct navigation link

<small>[[CycleCollector/CCStatus-2007-03-07|« previous meeting]] | [[CycleCollector/Status_Meetings|index]] | [[CycleCollector/CCStatus-2007-03-23|next meeting »]]</small>

=== Agenda ===
* Update from most recent discovery and patch to reduce leas by peterv.
* Update from graydon on landing {{bug|368869}}.
* Update from jst on CC timing code.
* Update from dbaron on debugging tools.

* Discuss next steps.

=== Leak Numbers ===

peterv: Patch ({{bug|374096}} ) was landed today. Leaks dropped from 700k to 6k. Catches most of it, but there's some tuning to due.

jst: Has a patch for CC timing. Will create a bug and attach patch for review. No update on the XPConnect stuff yet.

dbaron: Nothing of interest. Going to do some lower level leak tests. Seeing the usual mess of font config junk.

=== Status of Pending CC Code in Bugzilla ===

* [https://bugzilla.mozilla.org/show_bug.cgi?id=372713 Add cycle collection to RDF datasources]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=372960 Make XPConnect traverse more JS edges]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=368774 Support cycle collection of refcounted non-xpcom objects (aka, the XBL patch)]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=368869 Make cycle collection suspect all native wrapper roots]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=372766 cycle collector shutdown dump based on known should-have-been-freed objects]

=== Next Steps ===

* Performance: Boris has filed two bugs ({{bug|373693}} (addref) and {{bug|373694}} (release) ) because of address/release. Need to look at these items. David has been doing some analysis of collection of why he's seeing slow down.
* Collectively look for performance enhancements.
* The tinderbox doesn't show major leaks, but maybe we should go through all the leaks tests.
* Peterv will look at both of the bugs above for next week.
* jst will land the CC timing code ({{bug|374239}}).

=== Audio of This Meeting ===

* [http://shotoku.sicore.org:8080/file-access/default/mozilla/podcasts/Cycle_Collector_Meeting_2007-03-16_11_30am_PST.mp3 MP3 Format 10.6 MB]
* You can subscribe to these meetings as a podcast using [http://shotoku.sicore.org:8080/feeds/mozilla/podcasts/rss2 this RSS2 link]. (Accountability Disclaimer: I didn't test this podcast to make sure it is compatible with anything other than iTunes. Sorry. :] )

CycleCollector/CCStatus-2007-03-23

2007-03-26T12:25:41Z

Taken: using templates, adding navigation links

<small>[[CycleCollector/CCStatus-2007-03-16|« previous meeting]] | [[CycleCollector/Status_Meetings|index]]</small>

=== Agenda ===
* Discuss performance: Boris has filed two bugs ({{bug|373693}} (addref) and {{bug|373694}} (release). Status?
* dbaron on slow down he was encountering.
* Performance in general.
* Outcome of leaks tests?
* jst on status of landing the CC timing code ({{bug|374239}}).
* Discuss next steps.

=== Leak Numbers ===
Peterv:
Not much changed from last week. Found one JS edge that was keeping XBL global objects alive. Also wrote a patch to make the cycle collector itself not leak on shutdown. These should drop shutdown leaks a little bit.
* {{bug|375063}} (Leaking nsJSContexts and nsXBLDocGlobalObjects at shutdown)
* {{bug|375075}} (Stop leaking the cycle collector on shutdown)

Tried to reland patch for {{bug|372960}} (Make XPConnect traverse more JS edges), but Tinderbox is still going orange. Will probably back out again, seems related to CC performance issue. Tried to turn on jst's timing code, but that made Tinderbox go green so can't debug the issue then.

Made new patch for {{bug|372713}} (Add cycle collection to RDF datasources) to address r- comments.

Worked a little bit on {{bug|373693}} (Cycle collector makes AddRef about 6x slower) and {{bug|373694}} (Cycle collector makes Release about 11x slower), not done yet.

=== Status of Pending CC Code in Bugzilla ===

* [https://bugzilla.mozilla.org/show_bug.cgi?id=372713 Add cycle collection to RDF datasources]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=372960 Make XPConnect traverse more JS edges]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=368774 Support cycle collection of refcounted non-xpcom objects (aka, the XBL patch)]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=368869 Make cycle collection suspect all native wrapper roots]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=372766 cycle collector shutdown dump based on known should-have-been-freed objects]

=== Next Steps ===

=== Audio of This Meeting ===

* [http://shotoku.sicore.org:8080/file-access/default/mozilla/podcasts/Cycle_Collector_Meeting_2007-03-16_11_30am_PST.mp3 *NOT YET AVAILABLE* MP3 Format 10.6 MB]
* You can subscribe to these meetings as a podcast using [http://shotoku.sicore.org:8080/feeds/mozilla/podcasts/rss2 this RSS2 link]. (Accountability Disclaimer: I didn't test this podcast to make sure it is compatible with anything other than iTunes. Sorry. :] )

CycleCollector/CCStatus-2007-03-16

2007-03-26T12:23:29Z

Taken: adding navigation links

<small>[[CycleCollector/CCStatus-2007-03-16|« previous meeting]] | [[CycleCollector/Status_Meetings|index]] | [[CycleCollector/CCStatus-2007-03-23|next meeting »]]</small>

=== Agenda ===
* Update from most recent discovery and patch to reduce leas by peterv.
* Update from graydon on landing {{bug|368869}}.
* Update from jst on CC timing code.
* Update from dbaron on debugging tools.

* Discuss next steps.

=== Leak Numbers ===

peterv: Patch ({{bug|374096}} ) was landed today. Leaks dropped from 700k to 6k. Catches most of it, but there's some tuning to due.

jst: Has a patch for CC timing. Will create a bug and attach patch for review. No update on the XPConnect stuff yet.

dbaron: Nothing of interest. Going to do some lower level leak tests. Seeing the usual mess of font config junk.

=== Status of Pending CC Code in Bugzilla ===

* [https://bugzilla.mozilla.org/show_bug.cgi?id=372713 Add cycle collection to RDF datasources]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=372960 Make XPConnect traverse more JS edges]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=368774 Support cycle collection of refcounted non-xpcom objects (aka, the XBL patch)]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=368869 Make cycle collection suspect all native wrapper roots]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=372766 cycle collector shutdown dump based on known should-have-been-freed objects]

=== Next Steps ===

* Performance: Boris has filed two bugs ({{bug|373693}} (addref) and {{bug|373694}} (release) ) because of address/release. Need to look at these items. David has been doing some analysis of collection of why he's seeing slow down.
* Collectively look for performance enhancements.
* The tinderbox doesn't show major leaks, but maybe we should go through all the leaks tests.
* Peterv will look at both of the bugs above for next week.
* jst will land the CC timing code ({{bug|374239}}).

=== Audio of This Meeting ===

* [http://shotoku.sicore.org:8080/file-access/default/mozilla/podcasts/Cycle_Collector_Meeting_2007-03-16_11_30am_PST.mp3 MP3 Format 10.6 MB]
* You can subscribe to these meetings as a podcast using [http://shotoku.sicore.org:8080/feeds/mozilla/podcasts/rss2 this RSS2 link]. (Accountability Disclaimer: I didn't test this podcast to make sure it is compatible with anything other than iTunes. Sorry. :] )

CycleCollector/CCStatus-2007-03-07

2007-03-26T12:19:09Z

Taken: use bug template, add navigation link

<small>[[CycleCollector/Status_Meetings|index]] | [[CycleCollector/CCStatus-2007-03-16|next meeting »]]</small>

=== Agenda ===
* Update on current leakage numbers.
* Update from peterv.
* Status of pending CC code in Bugzilla.
* Status update from sicking regarding review of peterv's patch.
* Update from dbaron on debugging tools.
* Update from jst on xpconnect mysteries.
* Discuss next steps.

=== Leak Numbers ===

* Tinderbox didn't show that much of an improvement; however, our builds are showing improvements.
* There are conflicting numbers.
* SeaMonkey shows a drop, peterv's local shows a drop, but the Firefox build doesn't show improvements.

Jonas: I will take the XBL patch and see if that has an impact.

dbaron: Worried about a situation with the current code base where he [http://groups.google.com/group/mozilla.dev.performance/msg/7b2b326d0ed08889 sees his CPU pegged for several seconds] before responsiveness returns. It was suggested that we start recording CC times.

=== Status of Pending CC Code in Bugzilla ===

* [https://bugzilla.mozilla.org/show_bug.cgi?id=372713 Add cycle collection to RDF datasources]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=372960 Make XPConnect traverse more JS edges]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=368774 Support cycle collection of refcounted non-xpcom objects (aka, the XBL patch)]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=368869 Make cycle collection suspect all native wrapper roots]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=372766 cycle collector shutdown dump based on known should-have-been-freed objects]

=== Next Steps ===

* Johnny will add CC timing printfs:
** Cycle collection graph call times.
** JS GC times.
* dbaron is going to land a patch related to debugging ({{bug|372766}} above).
* Sicking is going to drive the XML patch in as well as the patch from peterv (adding more content objects).
* jst will continue with xpconnect.
* Graydon will land {{bug|368869}}.

peterv suggestion: We should try to get to a point were we can start and stop without leaking.

=== Audio of This Meeting ===

* [[Media:Cycle_Collector_Meeting_2007-03-09_11_30am_PST.mp3|MP3 Format 33 MB]]
* [[Media:Cycle_Collector_Meeting_2007-03-09_11_30am_PST.ogg|Ogg Vorbis 11.4 MB]]
* You can subscribe to these meetings as a podcast using [http://shotoku.sicore.org:8080/feeds/mozilla/podcasts/rss2 this RSS2 link]. (Accountability Disclaimer: I didn't test this podcast to make sure it is compatible with anything other than iTunes. Sorry. :] )

CycleCollector/CCStatus-2007-03-16

2007-03-26T12:13:22Z

Taken: use bug template

=== Agenda ===
* Update from most recent discovery and patch to reduce leaks by peterv.
* Update from graydon on landing {{bug|368869}}.
* Update from jst on CC timing code.
* Update from dbaron on debugging tools.

* Discuss next steps.

=== Leak Numbers ===

peterv: Patch ({{bug|374096}} ) was landed today. Leaks dropped from 700k to 6k. Catches most of it, but there's some tuning to due.

jst: Has a patch for CC timing. Will create a bug and attach patch for review. No update on the XPConnect stuff yet.

dbaron: Nothing of interest. Going to do some lower level leak tests. Seeing the usual mess of font config junk.

=== Status of Pending CC Code in Bugzilla ===

* [https://bugzilla.mozilla.org/show_bug.cgi?id=372713 Add cycle collection to RDF datasources]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=372960 Make XPConnect traverse more JS edges]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=368774 Support cycle collection of refcounted non-xpcom objects (aka, the XBL patch)]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=368869 Make cycle collection suspect all native wrapper roots]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=372766 cycle collector shutdown dump based on known should-have-been-freed objects]

=== Next Steps ===

* Performance: Boris has filed two bugs ({{bug|373693}} (addref) and {{bug|373694}} (release) ) because of address/release. Need to look at these items. David has been doing some analysis of collection of why he's seeing slow down.
* Collectively look for performance enhancements.
* The tinderbox doesn't show major leaks, but maybe we should go through all the leaks tests.
* Peterv will look at both of the bugs above for next week.
* jst will land the CC timing code ({{bug|374239}}).

=== Audio of This Meeting ===

* [http://shotoku.sicore.org:8080/file-access/default/mozilla/podcasts/Cycle_Collector_Meeting_2007-03-16_11_30am_PST.mp3 MP3 Format 10.6 MB]
* You can subscribe to these meetings as a podcast using [http://shotoku.sicore.org:8080/feeds/mozilla/podcasts/rss2 this RSS2 link]. (Accountability Disclaimer: I didn't test this podcast to make sure it is compatible with anything other than iTunes. Sorry. :] )

Community:SummerOfCode07

2007-03-26T11:19:34Z

Taken: use standard table

This page lists all the Google Summer of Code 2007 projects with confirmed mentors, and which have been approved by the SoC administrator. Please do not edit this page; new suggestions can be made on [[Community:SummerOfCode07:Brainstorming|the Brainstorming page]].

'''Potential students''': you may choose from the list below, from [[Community:SummerOfCode07:Brainstorming|the Brainstorming page]], or submit your own proposal. Be wary when choosing from the Brainstorming page; there is often a good reason why the ideas haven't made it to this page.

If the idea has no mentor (or the person who has volunteered is unsuitable) then we would need to find a mentor; you will increase your chances of success if you find one for yourself and submit their name with your application. A mentor should generally be a respected Mozilla project contributor with expertise in the relevant field; projects involving integration with other code could be mentored by someone with expertise in the other codebase. However, lack of a mentor should not be a deterrent - please, still apply even if you don't have one.

You may wish to consider [http://weblogs.mozillazine.org/gerv/archives/2006/05/how_not_to_apply_for_summer_of.html How Not To Apply For Summer Of Code] before making your application. Then [http://code.google.com/soc/student_step1.html apply here] (you'll need a Google Account).

==Firefox/Gecko==

{| class="standard-table"
|-
!Title
!Abstract - links to details/bugs/etc
!Reporter
!Mentor(s)
!Comments
|-
| valign="top" | Implement link fingerprints
| valign="top" | Link fingerprints are a method of making an HTTP or HTTPS URL reference not only a particular resource, but a particular version of that resource, in a way that the fetching client can validate. This would make it harder (not impossible) for crackers to change downloadable software packages without any user (and the site owner) noticing it. Further details can be found in [http://www.gerv.net/security/link-fingerprints/ the proposal by Gervase Markham], Gerv's [http://weblogs.mozillazine.org/gerv/archives/2007/03/wordpress_download_tarball_com.html blog post about the recent Wordpress tarball attack] and [https://bugzilla.mozilla.org/show_bug.cgi?id=292481 bug 292481]
| valign="top" | [[User:Jens.b|Jens.b]]
| valign="top" | Gerv
| valign="top" | This is similar to Heikki's proposal above and could be done as part of that larger activity, but I think it deserves separate mention as its scope is specified more precisely, and it might be faster to implement. - Jens<br><br>There is already an extension which does some of this; a proper patch for the trunk would be required, and then the writing up of the idea as an RFC - Gerv
|-
| valign="top" | Firefox automation & Tinderbox integration
| valign="top" | Firefox 3 automated smoke-testing using Linux Desktop Testing Project; Tinderbox integration of LDTP results.
| valign="top" | [[User:NagappanAlagappan|Nagappan]]
| valign="top" | [[User:NagappanAlagappan|Nagappan]] and Emily Chen
| valign="top" | Once the system is integrated with Tinderbox, then we can extend it to use for Thunderbird automation testing too.

|-
| valign="top" | SMIL Animation
| valign="top" | Work on extending and polishing the [https://bugzilla.mozilla.org/show_bug.cgi?id=216462 existing patch] by [http://brian.sol1.net/svg/ Brian Birtles] which adds a SMIL animation to mozilla and hosts it in SVG.
| valign="top" | tor
| valign="top" | tor
| valign="top" |
|-
| valign="top" | SVG Fonts
| valign="top" | Add the ability to [http://www.w3.org/TR/SVG11/fonts.html define a font with SVG] to mozilla's SVG implementation. Doing the "basic" style fonts that handle the "d" attribute, as used by SVG Tiny, should be fairly straightforward once [http://lists.freedesktop.org/archives/cairo/2007-February/009539.html cairo adds a user font API].
| valign="top" | tor
| valign="top" | tor
| valign="top" |
|-
| valign="top" | rich content microsummaries
| valign="top" | [https://bugzilla.mozilla.org/show_bug.cgi?id=341347 bug 341347]<br>[http://blog.mozilla.com/faaborg/2006/12/06/tufte-and-graphical-microsummaries/ Tufte and Graphical Live Titles]<br>[http://wiki.mozilla.org/GraphicalMicrosummaries Graphical Microsummaries]
| valign="top" | MykMelez
| valign="top" | MykMelez
| valign="top" | As Tufte notes, it can be very useful to pack a lot of information in a small space. Microsummaries are targeted at that kind of information presentation. But microsummaries can only display characters at the moment, which severely limits how much information they can display and how well they can display it.

In fact, the most dramatically informative microsummaries (like a graph of the day's activity for a stock, or a graphical depiction of the next five day's weather) are currently impossible to implement. But if sites could provide rich content (i.e. HTML or image) microsummaries, then these would be possible.
|-
| valign="top" | microsummary builder
| valign="top" | [https://addons.mozilla.org/firefox/3741/ Microsummary Generator Builder extension]
| valign="top" | MykMelez
| valign="top" | MykMelez
| valign="top" | For sites that don't provide microsummaries, it's useful to be able to extract your own. But building one from scratch requires knowledge of XSLT, XPath, and other technologies that even computer-savvy users and software engineers may lack. And even for folks who do have that knowledge, it's much harder than it should be to extract a microsummary from a web page.

Tools could significant improve this situation, and [https://addons.mozilla.org/firefox/3741/ one such tool] is already available, but there's still a lot more that can be done in two directions: for regular users, we could have a tool that made extracting a microsummary super-simple. In fact, it could start as simple as clicking an element on a web page and dragging it to the bookmarks toolbar. We could then build on that basic functionality with additional simple mechanisms for massaging the information to be summarized.

For developers, we could have a tool that couples those simple mechanisms for average users with more sophisticated functions for inspecting and manipulating the microsummary generator. For example, we might provide an editable "source" view of the generator. And we might enable more complicated UI gestures for things like anchoring an XPath that retrieves some informatino to a non-root node (f.e. to the node that labels that information, whose relationship to the information is less likely to change over time than the relationship of that information node to the root node).
|-
| valign="top" | microsummary generator web service
| valign="top" | [http://userstyles.org/livetitle User Styles' Live Titles repository]
| valign="top" | MykMelez
| valign="top" | MykMelez
| valign="top" | userstyles.org has set up a repository for microsummary generators, which is a great first step in distributing the generators, but it would be much more useful if users didn't have to browse the repository and install a generator to use it on a site.

Imagine an extension (or an enhancement to an extension like [https://addons.mozilla.org/firefox/3639/ Microsummary Buddy] or [https://addons.mozilla.org/firefox/4248/ Microsummary Manager]) that automatically notifies users when a generator is available for a page they're browsing and shows them the microsummary it generates. Then, if users decide they want to use the microrsummary, the extension installs the generator automatically and creates the microsummary-enabled bookmark for the user. And all the user has to do is something simple like clicking on the "microsummary available" notification icon or dragging it to the bookmarks toolbar.
|-
| valign="top" | JPEG 2000
| valign="top" | [https://bugzilla.mozilla.org/show_bug.cgi?id=36351 Add JPEG 2000 support to Mozilla]
| valign="top" | schapel
| valign="top" | pavlov (maybe)
| valign="top" | This would be done as an extension, perhaps as described in [https://bugzilla.mozilla.org/show_bug.cgi?id=18574#c672 this Bugzilla comment]
|-
| valign="top" | SVG as an image format
| valign="top" | One of the possibilities that having a native SVG implementation in the browser provides is being able to use SVG in contexts where normally a raster image would be used, such as <html:img> and CSS properties that accept images.

Someone interested in taking this on as a SoC project would need to be pretty familiar with the Mozilla codebase, as this involves getting bits of code that weren't originally planned to work with one another to play nicely together.
| valign="top" | tor
| valign="top" | tor
| valign="top" |
|}

==Thunderbird==

{| class="standard-table"
|-
!Title
!Abstract - links to details/bugs/etc
!Reporter
!Mentor(s)
!Comments
|-
| valign="top" | Add tabbed messages support for Thunderbird
| valign="top" | Tabbed message reading is a highly demanded feature for Thunderbird and was on the planned feature list for version 2, but missed the bus and currently there is nobody working on it. Having to change the selected folder and/or message or opening a new window decreases productivity (increases waste of time). The new message pane should also be available for the tabbed view. See [https://bugzilla.mozilla.org/show_bug.cgi?id=297379 Bug 297379] and [https://bugzilla.mozilla.org/show_bug.cgi?id=218999 Bug 218999]
| valign="top" | Archaeopteryx
| valign="top" | mscott
| valign="top" | There had been experimental builds by Myk in the past, so there are already some concepts.
|-
| valign="top" | Thunderbird: Vista Desktop Search Integration
| valign="top" | Implement Vista Desktop Search for Thunderbird mail messages as described in [https://bugzilla.mozilla.org/show_bug.cgi?id=369283 bug 369283]
| valign="top" | [[User:Bienvenu|Bienvenu]]
| valign="top" | [[User:Bienvenu|Bienvenu]]
| valign="top" | There is a lot of code in the Spotlight integration code that could be re-used for the Vista search integration.
|-
| valign="top" | Thunderbird and Firefox Integration Points
| valign="top" | Make using Thunderbird and Firefox together a better user experience.
| valign="top" | [[User:mscott|mscott]]
| valign="top" | [[User:mscott|mscott]]
| valign="top" | Add some integration hooks between Firefox and Thunderbird such as: adding a url to Thunderbird could autocomplete against Firefox bookmark and history urls. Filling out an address form in Firefox could extract the address data from your Thunderbird address book. I'm sure there are other ideas that could be explored here too.
|-
| valign="top" | Improve Thunderbird mail filters
| valign="top" | Thunderbird's (and SeaMonkey's) mail filter system lacks features present in other clients. Implementing some of them (and new, unique features) would make it much more useful to advanced users, and could increase the user base.<ul><li>Allow to define filters for outgoing messages (e.g. file messages to folders based on found keywords), [https://bugzilla.mozilla.org/show_bug.cgi?id=11039 bug 11039]</li><li>Allow filtering on whether sender is in certain addressbook groups, [https://bugzilla.mozilla.org/show_bug.cgi?id=180013 bug 180013]</li><li>Add ability to filter by attachment presence or file names (e.g. file extension), [https://bugzilla.mozilla.org/show_bug.cgi?id=224392 bug 224392], [https://bugzilla.mozilla.org/show_bug.cgi?id=105169 bug 105169]</li><li>Allow extensions to tie in to filters (filter actions implemented in JS / XPCOM), [https://bugzilla.mozilla.org/show_bug.cgi?id=366094 bug 366094]</li></ul>The exact set of bugs fixed as part of SoC activity would be determined by the mentor and the participant. More ideas can be found in [https://bugzilla.mozilla.org/showdependencytree.cgi?id=66425&hide_resolved=1 meta bug 66425]
| valign="top" | [[User:Jens.b|Jens.b]]
| valign="top" | bienvenu
| valign="top" |
|}

==Camino==

{| class="standard-table"
|-
!Title
!Abstract - links to details/bugs/etc
!Reporter
!Mentor(s)
!Comments
|-
| valign="top" | Camino: Tabspose
| valign="top" | Expose for tabs, but in the browser window ({{bug|312007}})
| valign="top" | pinkerton
| valign="top" | pinkerton
| valign="top" | I've wanted to do this for years...
|-
| valign="top" | Camino AppleScript Support
| valign="top" | Camino currently has very little AppleScript support. One of the most useful commands for a browser, "do javascript", remains unimplemented. Several other bugs separate Camino from parity with Safari's and OmniWeb's scripting support. Filed bugs include {{bug|178917}}, {{bug|160106}}, {{bug|314061}}, {{bug|253486}}, and {{bug|156078}}. Those bugs cover a lot of ground, including the ability to refer to tabs.
| valign="top" | Peter Jaros ([[User:Peeja|Peeja]], Bard College)
| valign="top" | [[User:Pinkerton|Mike Pinkerton]]
| valign="top" |
|}

==SeaMonkey==

{| class="standard-table"
|-
!Title
!Abstract - links to details/bugs/etc
!Reporter
!Mentor(s)
!Comments
|-
| valign="top" | Make SeaMonkey Not Suck As A News Reader
| valign="top" | Basically, get some traction on some of the highlights of {{bug|176238}}/{{bug|12699}} , in particular: "clickable references" ({{bug|62033}}) and headers in general ({{bug|23114}}), a more usable subscribe dialog ({{bug|40260}}), reordering of the folder pane ({{bug|150274}}, maybe even hierarchical?). For bonus points, a correct implementation of the nntp/news protocols ({{bug|89939}}) would be really cool!
| valign="top" | Mnyromyr
| valign="top" | Mnyromyr
| valign="top" | UI stuff would be for SeaMonkey, but should be portable to Thunderbird easily. Both would profit from backend fixes.
|-
| valign="top" | Real Mail Templates
| valign="top" | Currently, mail templates are too static, their interaction with mails you respond to etc. is almost zero ({{bug|21210}}, {{bug|107876}} and others). It would be an enourmous progress if we could have variables like $$EMailAddress$$, $$QuotedBody$$, $$Date$$, $$CustomVariable(with Parameter)$$ in a template which get filled in when replying or composing.
| valign="top" | Mnyromyr
| valign="top" | Mnyromyr
| valign="top" | UI stuff would be for SeaMonkey, but should be portable to Thunderbird easily. Both would profit from backend fixes.
|-
| valign="top" | Score Filter
| valign="top" | A score filter ({{bug|151622}}) would associate an integer with every message. This integer could then be changed by filter actions like "Increase by x", "Set to Y", etc. and have itself filter criteria like "If score is lower than A", "If score has value B", etc. Several other message properties alterable by filter actions (like isJunk or isThread) would need to be made usable as filter criteria for that for full points. In toto, this would allow for very fine-grained message control.
| valign="top" | Mnyromyr
| valign="top" | Mnyromyr
| valign="top" | UI stuff would be for SeaMonkey, but should be portable to Thunderbird easily. Both would profit from backend fixes.
|}

==Bugzilla==

{| class="standard-table"
|-
!Title
!Abstract - links to details/bugs/etc
!Reporter
!Mentor(s)
!Comments
|-
| valign="top" | Bugzilla: Plugin System
| valign="top" | [https://bugzilla.mozilla.org/show_bug.cgi?id=371333 bug 371333]: Bugzilla has many methods for being extended, but they are not always clearly documented or coordinated. There is also no central repository for downloading plugins, or a standard way to install them. This task would be to make it easy for developers to write plugins, make it easy for administrators to install them, and write a useful sample plugin that demonstrates all of this.
| valign="top" | [[User:MaxKanatAlexander|mkanat]]
| valign="top" | [[User:MaxKanatAlexander|mkanat]]
| valign="top" |
|-
| valign="top" | Bugzilla: Overhaul Charting System
| valign="top" | Bugzilla currently has two charting systems, the Old Charts and the New Charts. Old Charts are very simple, and work. New Charts are very complex, and the code has been abandoned for several years. However, charting is a feature that many users want in a bug-tracking system.

This task would be to implement a charting system that is simple to use, respects Bugzilla's built-in security, and provides the flexibility that administrators want. In particular, the ability to go "back in time" and chart data about the past would be very welcome. (Our current system only starts charting data as soon as you set up a chart, so you can't find out anything about last month, or even yesterday.)
| valign="top" | [[User:MaxKanatAlexander|mkanat]]
| valign="top" | Gerv
| valign="top" | There may be some questions about importing data from the old systems. I think that New Charts are not in much use, since they aren't complete. The system would have to be able to import Old Charts, but the New Charts system could be entirely replaced by the system built in this project. (However, any left-over New Charts would have to be exported as CSV so that users wouldn't lose their data.)
|-
| valign="top" | Bugzilla: Duplicate Bug Detection
| valign="top" | Implement a system in Bugzilla that detects automatically that the user has likely entered a bug that is a duplicate of another bug, and display a list of bugs that this bug might be a duplicate of.
| valign="top" | [[User:MaxKanatAlexander|mkanat]]
| valign="top" | vladd
| valign="top" | [https://launchpad.net/malone Malone] can do this now, although I'm not certain its code is actually open source. (Anyhow, GPL'ed code can't be included in Bugzilla, which uses the MPL.)
|}

==L10n==

{| class="standard-table"
|-
!Title
!Abstract - links to details/bugs/etc
!Reporter
!Mentor(s)
!Comments
|-
| valign="top" | Easing the way for localizers
| valign="top" |
* fixing .label/.accesskey combination in the whole codebase, so that automatic tools have a chance to catch them all.
* Step by step documentations for new localizers.
* A script to align Mozilla Translator files to en-US files.
| valign="top" | Abdulkadir Topal
| valign="top" | pike
| valign="top" |
|-
| valign="top" | Merge the two existing French spelling dictionaries
| valign="top" | There are currently [https://addons.mozilla.org/thunderbird/dictionaries/?lang=fr two French spelling dictionaries] for MySpell. The first was made available from a former ISpell dictionary, and it was later "enhanced" by another group wanting to support new spellings only (1990 reform), although those are not mandatory. As a result, we have two dictionaries, but none of practical use (the first is outdated, the other is underlining perfectly valid words).

A possible implementation of this project would be to take the new dictionary, re-add the hundreds of words that were removed from the old one, and enhance it in other ways (for example, HunSpell allows you to remove some words from the spelling suggestions without underlining them). It might looks like a trivial task, but it is not the case. There were structural changes in the affix dictionary file which can't be resolved by a simple diff.
| valign="top" | Benoit / [http://frenchmozilla.sourceforge.net/ The FrenchMozilla team]
| valign="top" |
| valign="top" |

|-
| valign="top" | Create a new French dictionary (HunSpell) from scratch
| valign="top" | No matter how good the French spelling dictionary may become, it can't be shipped with Firefox or Thunderbird because of licensing issues (It's GPL only, Mozilla products are tri-licensed)[http://frenchmozilla.sourceforge.net/blog/index.php/2006/02/02/21-correction-orthographique-et-logiciels-mozilla explanation in French].
This proposal is to build a new French dictionary from scratch, taking advantage of the new features in [http://sourceforge.net/docman/display_doc.php?docid=29374&group_id=143754 HunSpell]

Someone interested in taking this on as a SoC project would probably need to have a strong background in linguistics or a similar field.
| valign="top" | Benoit / [http://frenchmozilla.sourceforge.net/ The FrenchMozilla team]
| valign="top" |
| valign="top" |
|}

Firefox3/StatusMeetings/2007-01-03

2007-01-05T08:43:44Z

Taken: wiki markup

<small>[[Firefox3/StatusMeetings/2006-12-13|« previous week]] | [[Firefox3/StatusMeetings|index]] | [[Firefox3/StatusMeetings/2007-01-10|next week »]]</small>

'''Meeting Details'''
* 11:00am PST (19:00 UTC)
* Mozilla HQ, 1st floor conference table
* 650-903-0800 x91 Conf# 217 (US/INTL)
* 1-866-879-4799 (pin 369) Conf# 217 (US)
* join irc.mozilla.org #granparadiso for backchannel

= Agenda =
* Action items
* Firefox 3
* Gecko 1.9 Alpha 2 Planning
* Gecko 1.9 Roundtable
* Any other business

= Firefox 3 =

* Documents and status next week. For real this time.

= Gecko 1.9 Alpha 2 Planning =

* Linux ref platform
** needs build/release to do tinderbox setup

* view manager linking ({{bug|130078}})
** bad interaction with view mgr update batching
** won't happen for a2
** still need to evaluate if it can happen for 1.9

* units unification ({{bug|177805}})
** needs testing builds, Martijn already doing some testing
** roc will review
** will try to land for a2

* cycle collector
** updated to trunk, fixed some glaring performance problems
** should be within 10% speed penalty on Tp2 for win32
** will land for a2, reevaluate after a2
** graydon to work with jst to try to find a better place to trigger collection other than main event loop

* new textframe code ({{bug|333659}})
** partial landing will happen for 1.9a2 (new textrun, just not new textframe)

= Gecko 1.9 Roundtable =

* color management - [http://www.littlecms.com/ lcms] inclusion (footprint, security, {{bug|16769}})
** main issues
*** printing (no worse than before, just different)
*** color matching with CSS content (Safari already does color correction, and it seems to work ok)
** need to talk to library author
** will try to get external help to do fuzztesting and add code for input validation as necessary

= Any other business =

* EV certs discussion
** Friday 11am

* Testing/Perf Infrastructure
** should be able to add new tests within a week

Places/StatusMeetings

2006-12-10T05:28:29Z

Taken:

[[Places|« Back to Places]]

Status meetings for the Places effort on Firefox 3 are held every Thursday at 4pm Pacific time in [http://irc.mozilla.org/ #places].

'''IRC Logs'''
* [[Places/StatusMeetings/2006-10-05|October 5th, 2006]]
* [[Places/StatusMeetings/2006-10-12|October 12th, 2006]]
* [[Places/StatusMeetings/2006-10-19|October 19th, 2006]]
* [[Places/StatusMeetings/2006-10-26 and 2006-10-27|October 26th and 27th, 2006]]
* [[Places/StatusMeetings/2006-11-09|November 9th, 2006]]
* No meeting on November 16th, 2006, due to [[FirefoxSummit/2006/Schedule|Firefox Summit]], but see the [[Places/2006SummitNotes|notes]] from the Places meeting at the summit
* No meeting on November 23th, 2006, due to Thanksgiving
* [[Places/StatusMeetings/2006-11-29|November 29th, 2006]]
* [[Places/StatusMeetings/2006-12-07|December 7th, 2006]]

Places/StatusMeetings/2006-10-19

2006-12-10T05:20:20Z

Taken:

<small>[[Places/StatusMeetings/2006-10-12| « previous week]] | [[Places/StatusMeetings|index]] | [[Places/StatusMeetings/2006-10-26 and 2006-10-27|next week »]]</small>

== Places meeting: 2006-10-19 4pm PST ==
dietrich i put up some bookmarks recommendations here: http://wiki.mozilla.org/Places:BookmarksComments
thunder I skimmed it last night
dietrich if anyone has had a chance to look through it, it'd be great to get feedback
thunder it looked pretty good overall
* thunder opens it up now
sspitzer dietrich: I haven't had a chance to read it yet, my apologies. I'll do some reading today and put comment on the discussion page.
dietrich some of the changes are sync-related, but stuff like unique IDs for bookmarks seem like a must-have
dietrich sspitzer: cool, thx
sspitzer I'm also behind on reading dan's perf results
thunder dietrich: one thing that did come to mind, though
thunder is that "singleton model" doesn't necessarily exclude us from having *non-special-cased* metadata such as titles or anything else
thunder that was just one proposal
thunder ne could work out a data model in which URIs are unique, but there are multiple other bits of data (e.g., bookmarks) which point to each URI
thunder s/^/O/
dietrich hm, that sound like what i said. maybe i'm not understanding :)
thunder dietrich: not sure if I'm making sense?
dietrich s/sound/sounds/
dietrich so, in the framework i proposed, you'd have this:
thunder well, it sounded like, to provide for multiple bookmarks, we'd do away with "the singleton model" entirely
sayrer thunder: that makes sense, but then the URI is a JOIN (by reference). not sure that is good for sync
dietrich URI1 -> BookmarkURI1 -> title
thunder but we'd realistically *want* that, for history
dietrich and URI1 -> BookmarkURI2 -> title
thunder sayrer: a bookmark URI, you mean?
thunder (if so, yes)
sayrer yeah, if the bookmarked link over in a history table, that could be bad for sync
thunder though it could be made reasonably speedy, perhaps - I don't know
thunder oh, not speed concerns. sync. hm
sspitzer sayrer: what do you mean by: "if the bookmarked link over in a history table"
thunder I don't think I understand
thunder the bookmark would be a unique object, but not unique-by-url
dietrich thunder: all i proposed really, was another level of indirection between the singletone URI in history, and bookmark properties
thunder ah!
thunder okay
dietrich not to gut the existing places history arch
sayrer if the string is somewhere not in the bookmark table, and multiple bookmarks can join on it, that could get hairy I think. that's all
thunder then we are pretty much in full agreement
thunder sayrer: for e.g. deletion?
sayrer yeah. I think people who want to JOIN on bookmarks should do "WHERE bmks.URI == history.URI"
thunder (addition is pretty easy)
sayrer that is all from me :)
thunder right.
sspitzer dietrich: so you want to add another level of indirection to solve this problem, what's the new singleton?
sspitzer can you give an example that I can wrap my head around?
thunder sspitzer: history rows are stil unique by url
thunder sspitzer: there is a new bookmarks table where multiple rows can reuse the same history row
dietrich sspitzer: a URI for each bookmark
dietrich sspitzer: like the example in scrollback
thunder well, rather, have their own uri
thunder but I think we'd want to also link to the history table where possible
dietrich HistURI1 -> BookmkURI1 -> title
sayrer someone willing to take an action to draw a strawman table?
thunder I can write what I'm thinking more or less in the discussion tab of that page
dietrich thunder: yeah, each bookmark would likely have a FK back to the history table
thunder I don't know if it's really what dietrich had in mind
thunder dietrich: well, not every boomkmark, unfortunately
dietrich thunder: yeah please expand on what i have, or explain another approach
thunder since it's possible (and I think should continue to be possible) to have a bookmark that points to a place you've never been to
thunder which is unfortunate for the data model
dietrich thunder: so, the moz_history table is ill-named
brettw it should probably be moz_urls or something
dietrich yep
thunder yeah
dietrich sayrer: yes, i'll create a new schema for what i proposed
dietrich and put it on the wiki
thunder so basically a bookmark has a moz_url_id field, which can be null
sayrer sounds good. (I don't like discussion pages, fwiw. people should add and edit each other's text)
dietrich sayrer: i'm fine w/ that
thunder where null == user has never (as far as history goes) been to that uri
brettw why bother with that
brettw why not just join on the URI?
brettw that sounds like too much extra bookkeeping
thunder hm. true. is it as fast?
brettw and it makes expiration slower
brettw should be fast enough
brettw especially since you don't usually do thousands of bookmark operations
dietrich thunder: no, a bookmark has a moz_url_id field which can't be null, and there are no entries in moz_historyvisits table for that id
sayrer I think we could write pretty naive code and not notice perf on bookmarks stuff
dietrich brettw: what sounds like extra bookkeeping?
brettw keeping track of the bookmark URL and a separate link to history
brettw wait, I changed my mind
brettw I agree with dietrich, why not keep it the way it is now
brettw ?
thunder dietrich: er, which can't be null? what would it be set to when the url is not visited?
brettw thunder: currently, it always refers to the history table
brettw if it isn't visited, it's still in the history table
brettw but has no visit records
brettw this way URL storage is centralized
thunder okay, sure.
thunder hence the rename
sspitzer history table == moz_history, which we agree should be renamed to moz_urls?
thunder of the table
thunder it's really "urls we know about"
dietrich sspitzer: yes, i 2nd that
sspitzer (I'm just trying to make sure I understand brettw's comment)
brettw sspitzer: right
brettw even fake URLs like place: URIs
thunder er, maybe moz_uris then :)
brettw speaking of which, those cause problems
dietrich brettw: like what?
brettw dietrich: you can set a bookmark folder's favicon using it's canonical place: URI
brettw this is great
brettw the problem is with expiration
brettw there needs to be special logic to link this URI to the bookmark folder
brettw so when you delete the folder, the history row is unlocked
brettw I guess the bookmarks system should just do this
brettw not really a big problem, just a minor bug
brettw currently place: URIs never get deleted
dietrich brettw: yeah that sounds like bkmk service bookeeping
dietrich ah that's good to know about
sspitzer brettw: never deleted from moz_history (aka moz_urls)?
brettw sspitzer: right
brettw there's a bug on that somwehere
thunder so, with the current model, deleting history seems like it would be rather slow
thunder is it?
brettw it's highly optimized
brettw so no :)
thunder okay :)
brettw we do a little at a time, so it never ends up being too much work
dietrich anyone else have items to discuss?
thunder anyone have any comments on the perf stuff?
dietrich thunder: at the fx3 meeting today, someone mentioned a canonical page set for Tp tests
dietrich might be useful for testing places perf
thunder yeah
thunder definitely
dietrich i didn't catch the name of who was making it tho
thunder I used a zip file that vlad gave me
thunder which has stuff like cnn.com, apple.com, slashdot, etc -- from like 6 years ago ;)
dietrich haha i think that's the page set we use now
thunder yeah
sspitzer on my end: I have to do some cleanup, per dietrich, on my patch
brettw it's not necessary to worry about the exact contents of pages
brettw only the number of links
brettw and the number of iframes
brettw places doesn't care about anything else
thunder brettw: what about the relative percentage of visited/not visited links?
brettw thunder: yes, that's true too, but the testing set doesn't affect that
brettw and in the general case, only like 2 links are ever visited
brettw on average
thunder right, we were discussing having multiple testing sets
thunder I thought about writing a little script to pull all the urls from the testing set and add them all to the history table
sspitzer brettw: where does that general case come from?
brettw my ass
sspitzer :)
thunder a fine location for urls
thunder I'm sure
sspitzer moz_brettw_ass
dietrich places:folder=brett's_ass
brettw I believe there are 200 links per page in the PLT on average
brettw and for my history the average URL length is 100 bytes
brettw but that's because I use gmail :/
brettw for normal people it will be smaller
brettw gmail accounts for like 75% of my historyu
thunder so, to clarify, you think that the number of history rows more or less eclipses anything else?
thunder I guess I'm asking, is it worth spending time creating different test cases where we have a lot of visited links, etc
brettw not sure
thunder ok
thunder I guess it might be worth doing at least once, then
brettw I'd look at the numbers I posted on that bug
thunder nod
sspitzer on my end: I have made some progress with the history sidebar, but I want to finish that MOZ_PLACES_BOOKMARKS patch first, to unblock jminta and others.
thunder sspitzer: sounds good
sspitzer about the bookmarks UI, I think everyone is ok with starting to re-implement the Fx 2.0 UI on top of what we have now (the places backend) and adjusting as needed.
dietrich i have to go afk, back in 5
sspitzer jminta was asking around for 3 - 5 day tasks.
sspitzer s/for/for a
thunder I have nothing else. half of my time this week has been on something else :-/
sspitzer I'm out of updates as well, as I've been chasing some 1.5.0.8 / Fx20 gremilns for part of the week.
sspitzer sayrer has a big patch for livemarks
thunder woo gremlins
thunder I haven't seen that in ages
thunder so, are we done-ish?
sayrer sspitzer has a big review for livemarks ;)
thunder ha :)
sspitzer your patch is in, but needs a second pair of eyeballs, right?
sspitzer (sorry for the delay!)
sayrer yeah, mconnor and bsmedberg want more eyes
sspitzer https://bugzilla.mozilla.org/show_bug.cgi?id=353434 for those playing at home
sayrer not that they should be crying for the loss of the old feed parser
sayrer the places stuff is a pretty straight port
sspitzer so one take away from today was:
sspitzer dietrich proposal
sspitzer robert asked: someone willing to take an action to draw a strawman table
sspitzer I'll ping dietrich to see if he doesn't mind adding that to http://wiki.mozilla.org/Places:BookmarksComments
sspitzer the other take away is I owe sayrer a review
sspitzer and I need to finish my patch to get some r= from dietrich.
sspitzer I'm all out for today. same bat time, same bat channel next week?
sspitzer thanks again to brettw (and sayrer) for showing up to these meetings.
dietrich yeah thanks everybody
dietrich my one request is for people to take a look at my bookmarks recommendations to see if they make sense
sspitzer dietrich: will do, sorry for lagging.
dietrich so we can make decisions and move forward
thunder nod
thunder dietrich: will do
dietrich feel free to comment in the discussion page, or just edit the page itself

Places/StatusMeetings/2006-10-12

2006-12-10T05:19:56Z

Taken:

<small>[[Places/StatusMeetings/2006-10-05| « previous week]] | [[Places/StatusMeetings|index]] | [[Places/StatusMeetings/2006-10-19|next week »]]</small>

== Places meeting: 2006-10-12 4pm PST ==
sspitzer dietrich / v_thunder: should we start?
dietrich yep!
dietrich i don't have anything tangible to report yet
dietrich i've been working on fleshing out the requirements and scenarios for sync
dietrich and other integration methods
dietrich i'll try to blog w/ more details soon
sspitzer I have been going through the code, figuring out what pieces of MOZ_PLACES are bookmarks related, and turning them off with MOZ_PLACES_BOOKMARKS and keeping the history stuff as MOZ_PLACES
sspitzer so that if you build with MOZ_PLACES you'd get history only.
sspitzer I'm still working on that.
sspitzer about blogging, I think it would be good to blog about what we're doing, just so interested observers can find out.
sspitzer mconnor has suggested this, and so I've set up a blog for myself at blogs.mozilla.com. will you be blogging there, or on your personal blog?
dietrich http://dietrich.ganx4.com/
sherman That would be good.
sspitzer ok, cool. any objection to me linking that off the places wiki page, for under the "Team" section?
dietrich nope
sherman nope
dietrich sspitzer: is there a bug for the build-fu parts you're working on?
sherman speaking of places wiki...
sherman should it be cleaned up?
sspitzer sherman: probably, are you thinking of something in particular?
sspitzer dietrich: I'll log a bug, and make it block the meta history bug.
dietrich sherman: yes, i made a few minor updates to the main page, but we'll need to update it as we make design/api changes
sspitzer dietrich: and attach my patch there, when it is ready for primetime.
dietrich sherman: afaict, the only major problem with the current wiki docs is that some of the pages are not yet written
dietrich but the docs there *seem* to correspond w/ the current state of the code
dietrich sherman: one thing i would like to do at some point, and maybe you can help with it:
dietrich as we develop the Fx3 feature list, figure out which items are places related
dietrich so we can take those into account in our design discussions
dietrich sspitzer: once the build options are in place, i'll be glad to go in and turn off bookmarks code
dietrich if you have a WIP patch, feel free to send it over
sspitzer dietrich: my patch, once completed, should mean that when you build with --enable-places, you'll get 2.0 bookmarks ui and places history UI.
dietrich ah ok
sspitzer when I have a WIP patch, I'll attach to the bug
sspitzer what were you thinking?
sspitzer turning of BM code within places backend?
sspitzer or did I misunderstand?
dietrich if turning off BM code was a grueling task, that if you had the build options set up, i'd help out there
dietrich but it sounds like that's not the case?
sspitzer so far not the case. (what is slowing me down is some 1.5.0.8 distractions.)
sspitzer but that is out of the way now.
sspitzer dietrich: is now an OK time to chat about the "moz_anno" thing?
sspitzer or should that be in a blog or newsgroup?
dietrich sure
sspitzer actually, before we start that, I had another topic, which was: the big picture goal for places.
dietrich i think here is fine, the log goes on the wiki, which is probably enough
dietrich sspitzer: i.e. beyond getting 2.0 front-end on places backend?
sspitzer exactly
sspitzer is that our Fx 3 goal? or the first milestone for Fx 3?
sspitzer from http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/bc2c4214179d651e/c55ad92dec30e195#c55ad92dec30e195
sspitzer I listed our initial goals as:
sspitzer * ensure that we have the right APIs, data model, and architecture to
sspitzer allow for synchronization, remote bookmarks and future work in both core
sspitzer Firefox and add-ons (such as Google's Browser Sync, Foxmarks as well as
sspitzer add-ons that integrate with social bookmarking services, such as
sspitzer del.icio.us)
sspitzer * implement the FF2 UI on top the Places backend, starting with the
sspitzer History UI [1]
sspitzer * write some functional and performance tests that can be integrated
sspitzer into "make check" and into Tinderbox
sherman Should we be making an distinction between *initial* goals and *release* goals?
dietrich sherman: yes definitely
dietrich sspitzer: yeah, those sound like good first milestone (whenever that is)
sherman Also looking at the goals outlined on the wiki page... http://wiki.mozilla.org/Places
sspitzer release goals, for Fx3, and beyond.
sspitzer I think those are good starting points, but what about our ultimate goal? Sort of a places (bookmarks/history/more = tags) roadmap is what I was thinking.
dietrich but the release goals will likely be guided by the results of the fx3 product dev thats ramping up
dietrich eg: http://wiki.mozilla.org/Firefox/Feature_Brainstorming
dietrich We should make sure that whatever goals we have, outside of that list, get added
sherman An interesting discussion might center around whether or not the places backend could be repurposed for different types of content.
sherman i.e. hCards, hCalendars, hReviews, etc.
dietrich then we'd have to rename "places" to "places n' stuff"
dietrich ;)
sherman Perhaps!
dietrich i'd like to have an extensible data model so that moving forward we don't have to keep creating silo code for each "next big thing"
dietrich however, that's the trap of RDF
dietrich the kitchen sink
dietrich i'm sure i can convert any of those formats into sets of triples ;)
sspitzer triplets!
sspitzer about the extesible data model, this is what I was getting at with moz_anno. as we discussed privately, I'd like there to be an easy way to add arbitrary data (and then search on it.)
dietrich sspitzer: per bookmark?
dietrich right now, annotations are URI-centric IIRC
sherman Batch anno would be cool.
sherman Don't know how mainstream it would be however... sorry, thinking aloud.
dietrich sherman: what do you mean by batch?
dietrich sspitzer: i mention that because the scenarios you brought up were about bookmarks, IIRC
sherman In bookmarks manager, I don't have the ability to select multiple bookmarks and attach a keyword to them.
dietrich but i guess the places data model does blur the distinction :)
dietrich sherman: ah, right
sherman I guess the place where I make the most annotations is in iTunes.
dietrich like the any music metadata editor can do
dietrich right
sherman I download a lot of live music which forces me to do batch annos, the UI is pretty good.
dietrich sherman: yeah, i totally agree, it's a required feature for music
dietrich do any of the web 2.0 social bookmarking services have that feature?
sherman I think what's cool about the social bookmarking services is tag suggest.
sherman So based upon the URL that I'm bookmarking, what did everyone else use as a tag?
sspitzer what I was getting at was the ability, for add on developers and ourselves, to annotate items. I'm not limiting it to just a bookmark. I'm waving my hand here, but I could see a history add on that would want to annotate history items, and not with a limited set of annotations, but with arbitrary annotations.
sherman Don't know about batch tag... let me check del.icio.us...
sherman I agree.
dietrich sspitzer: right - arbitrary annotations provide a level extensibility that add-on developers could *really* take to the next level
dietrich however, to some extent, RDF provides that same level of flexibility
dietrich but falls down flat on ease-of-use for developers
sspitzer right, but does our current (places) data model / api provide it?
sspitzer yes, exactly: ease-of-use!
sherman Hey, cool... del.icio.us deleted all of my bookmarks and tags! Nice!
sherman There's a feature for you... data loss.
dietrich regarding the annotations data model - it's designed for a limited set of annotation "types" or "names"
myk sspitzer: i think it does
myk sspitzer: specifically, i think moz_anno annotates history items, whether those items are bookmarked or not
myk sspitzer: but you should check with others (or the code) to be sure, since i'm basing this on what it looked like was happening the last time i looked at the database schema, which was a while ago
myk two specific limitations of the annotation service that i ran into while building support for microsummaries in Places:
myk 1. you can't specify that an annotation should expire when a bookmark is deleted
myk 2. you can't store arbitrary binary data in an annotation, only images
brettw sspitzer: what you described is what the annotation service does
brettw myk: what do you mean about point 2?
brettw There is no special code to handle images
brettw it supports arbitrary binary data
myk brettw: perhaps i misunderstood then
brettw WRT point 1: expiration was not implemented, bookmark level deletion is probably a requirement
brettw but we never got around to that
myk brettw: at one point, when i looked at it, it looked like i could only store binary data if it was an image
brettw nope
brettw that's probably what the examples were of, but you can put anything in there
brettw including text/html
brettw You can put a hole web page in there and load it in a content area
brettw s/hole/whole
sspitzer very cool
brettw sspitzer: to clarify, the annotation service annotations any URI, not just bookmarks
brettw we have special URIs for bookmark folders so random crap can be attached to those
brettw the annotation service was originally designed for thumbnails and favicons
brettw and spellcheck state
brettw but it was too slow an not specific enough for the favicons, so that had to go in a separate service
myk brettw: hmm, not sure what i was looking at; i thought it was API, not examples, but it was a while ago, so i don't remember
brettw it's possible the first version was like this
sspitzer I need to play around with the annotation service, clearly.
sspitzer thanks for the info, brettw.
brettw the only significant problem with it is the lack of expiration
brettw that & the favicon service are my favorites :)
dietrich it seems like some expiration should be handled external to the anno service though
dietrich like bookmark deletion
myk dietrich: yeah, bookmark deletion itself shouldn't go through the annotation service, but the annotation service should observe bookmark changes and delete annotations that were added with the stipulation that they should only live as long as the bookmark
brettw Expiration in places is complicated because there are various dependencies
brettw for example, the favicon needs to stay in if there is a history page that refers to it, and the history page needs to stay in if a bookmark refers to it
brettw All places expiration is handled in nsNavHistoryExpire
brettw (.cpp)
brettw The bookmark observer thingy sounds good for a certain class of items
brettw Otherwise, search for "FIXME bug 319455" :)
sspitzer brettw: thanks for all those FIXME comments, as I go through the code, they have been helping me out.
brettw it only takes 644 lines to expire things!
brettw places history expiration happens incrementally as you browse (instead of delaying shutdown)
brettw and is highly optimized not to delay things, hence the lots o' code
sspitzer here's are my take away / todo items from our second meeting:
sspitzer post this irc log
sspitzer link to blogs from the team list (brettw, myk, sherman, do you guys have blogs and/or want to be listed?)
brettw not I
sherman Not yet.
sspitzer start a thread about the long term goals of places n stuff, starting from the goals listed on the :Places page.
sspitzer I'm using place n stuff, per sherman / dietrich's comments above.
myk sspitzer: probably i shouldn't, either, as i'm not on the places team (although i'm interested in places generally and its integration points with microsummaries specifically, hence my lurking in this channel)
sspitzer myk: ok
sspitzer sherman asked about cleaning up of the wiki in general, but are there specifc pages?
sspitzer the bug where I'll be putting the build patch (per my comment above) is https://bugzilla.mozilla.org/show_bug.cgi?id=356487
sspitzer thanks again to brettw for providing answers and info about moz_anno
sspitzer and the rest of places.
sherman http://wiki.mozilla.org/Bookmarks_Use_Cases
sherman Seems to be a brainstorming list... perhaps a few other pages.
sherman I could take a look.
brettw I'm scared of that page
sspitzer I'm all out of topics today, anyone else?
dietrich i think we're done for today
dietrich thanks again brettw for hanging out and clarifying stuff as we get deeper into places
sspitzer fwiw, v_thunder was unable to attend due to his machine is dead.
sspitzer yes, thanks again brettw
sspitzer I'll go post the log, thanks guys

Places/StatusMeetings/2006-10-05

2006-12-10T05:19:10Z

Taken:

<small>[[Places/StatusMeetings|index]] | [[Places/StatusMeetings/2006-10-12|next week »]]</small>
== Places meeting: 2006-10-05 4pm PST ==
sspitzer ok, so looking at http://wiki.mozilla.org/Places:Task_List
sspitzer should we just run down that list, assign some names, and figure out what me might be missing?
sspitzer I'm sure we will think of lots more as soon as we start doing more work.
dietrich sure, sounds fine
sspitzer ok, starting from the top:
sspitzer for: will be posting to and discussing places in ff3 on [http://groups.google.com/group/mozilla.dev.apps.firefox mozilla.dev.apps.firefox]
sspitzer I'd like to clean up and repost what I sent to brettw (hi brett, if you are there!) and the google guys and send to the newsgroup
sspitzer any objection?
dietrich nope
brettw hi
sspitzer sort of "we're here, where in #places and m.d.a.f"
dietrich howdy brettw
sspitzer for the next two items, I'll list all three of our names
sspitzer will be posting to and discussing places...
sspitzer developers hanging out in #places
sspitzer for "* fix trunk regressions caused by disabling places"
sspitzer I haven't seen lots of regressions, so I'll slap my name down there. ok?
dietrich ok. we should put something in status whiteboard for those
dietrich non-places-regression or something
sspitzer good idea. I'll add that info to this task wiki
sspitzer for review patch from Myk...and finish backporting non-places changes to trunk , I've got a patch started (waiting review) for one such backport. in addition to reviewing myk's patch, I'd like to go through the tree and look at all MOZ_PLACES ifdef and see what might need some love.
sspitzer his patch only covers the bookmarks code, and not the whole tree.
dietrich i can help w/ that also
dietrich what's the bug# for you patch?
sspitzer cool, I'll list us both for that.
dietrich s/you/your
sspitzer I'll start a new bug with the list of places we need to review to be sure that nothing fell through the crack. I'll do that after our meeting and cc you.
sspitzer or I may add my patch / info to myks bug
dietrich k
sspitzer https://bugzilla.mozilla.org/show_bug.cgi?id=353571
dietrich ah, ok, i thought your patch was in a diff bug, was why i asked
sspitzer I think his patch only covered mozilla/browser/components/bookmarks/
sspitzer no, not in a bug yet.
sspitzer the only patch I have is the one in https://bugzilla.mozilla.org/show_bug.cgi?id=342930
dietrich right. i'll review that RSN :)
sspitzer (no rush, it is not critical)
sspitzer on to the list...
sspitzer are microsummaries broken?
sspitzer no, they are not
sspitzer dao reported an issue
dietrich yeah saw that
sspitzer but it was just pilot error
sspitzer removing it...
dietrich cool
sspitzer per brettw's suggestion, start by implementing the Firefox 2.0 "History" UI on top of Places backend
sspitzer I'll keep that, if you are cool with that.
dietrich sure, and if that creeps, please break it out into different bugs, and i can jump in
sspitzer I'll do that. I'll update you on monday letting you know where I am. (been sidetracked with a software update back port for 1.5.0.x!)
dietrich sspitzer: so
dietrich actually, before any work starts on that, we should break it out into bugs
dietrich and maybe put swags on it
dietrich so we can figure out just how much of a job it is
sspitzer ok, I'll start by logging a meta bug and then bugs for each piece that we can swag.
dietrich and same for bookmarks (once we figure out where we're going it)
dietrich awesome
dietrich i think doing that from the beginning will help us track, and report progress
sspitzer I agree.
dietrich which will help out when we explain our plan to mconnor :)
sspitzer good point.
sspitzer I've got:
sspitzer * [dietrich sspitzer] per brettw's suggestion, start by implementing the Firefox 2.0 "History" UI on top of Places backend. Start by logging a meta bug and then log bugs for each part, add swag.
sspitzer I'll log the bugs today.
dietrich cool, i'll keep refreshing the wiki
dietrich or are you doing a big batch edit?
sspitzer refresh
sspitzer I just saved
dietrich k
dietrich so, the next item is the bookmarks ui
sspitzer for the bookmarks UI work, I think that all depends on what we do. for starters, we want to keep the existing UI and service
sspitzer what do you think about MOZ_PLACES_HISTORY and MOZ_PLACES_BOOKMARKS
sspitzer using them, I mean.
dietrich are u talking about the schemas?
sspitzer at the start, while we work on the history ui, we want to keep bookmarks alone.
dietrich exactly
sspitzer so when I build with --enable-places
brettw I wouldn't think you'd need to change the backend
sspitzer I really just mean MOZ_PLACES_HISTORY for now. But I'd like to keep all the MOZ_PLACES in the tree.
brettw but you may want those flags for the UI
sspitzer brettw: I was going to leave the backend alone for this first step.
sspitzer how about for the bookmark items, we don't list an owner (yet) but we do put a name by figuring out the hard part: "the plan for bookmarks for fx 3"
dietrich sspitzer: to clarify, you intend that MOZ_PLACES_HISTORY would use places history backend, but the old skool UI, and bookmarks untouched
dietrich ?
dietrich sspitzer: yeah, i can jump on the bookmarks plan
sspitzer how about this:
sspitzer when you do --enable-places, it means (at the start), MOZ_PLACES_HISTORY, and the usages that are bookmarks-on-top-of-places, we make it MOZ_PLACES_BOOKMARKS
sspitzer which won't be defined
sspitzer thereby giving us what we want (to start)
sspitzer this is for the stuff in the UI
sspitzer so the MOZ_PLACES that disables the old bookmarks service will now be MOZ_PLACES_BOOKMARKS
sspitzer dietrch: I have you by the bookmarks plan
dietrich ok
sspitzer for the bookmark ui issues, I will put [blocked by dietrich]
dietrich cool
sspitzer on to perf / testing
sspitzer can I give v_thunder the first one?
dietrich sure
sspitzer fix the Tp test
dietrich also,
dietrich add "history unit tests"
dietrich and change mine to "bookmarks unit tests"
sspitzer got it
dietrich those should be separate test suites
sspitzer I gave dmills:
sspitzer get some performance benchmarks with various history sizes (places vs non-places)
sspitzer also
sspitzer I'll take history unit tests.
dietrich k
sspitzer unless you've started that
dietrich nope
sspitzer (or have you been doing bookmarks with davel?)
dietrich i just did the bookmarks ones, and had davel review
sspitzer excellent
dietrich he helped figure out how to get it to work w/ the build infra
sspitzer on top of the places api, or the existing 2.0 bookmarks api?
dietrich so you can do a global "make check"
sspitzer very cool.
sspitzer on to "
sspitzer Synchronization / Remote Bookmarks"
dietrich the ones i did were on top of places api
dietrich so, this is where there's overlap w/ the data model changes
sspitzer right
dietrich i think a P1 is to give unique identifiers to each object (bookmark, folder, sep, etc)
dietrich i think "named separators" is kinda weird
dietrich i'd rather have an extensibility mechanism for bookmarks
sspitzer but as long as there is a guid for a separators, sync (of seps) should work.
dietrich right
sspitzer is the named thing just something fx 2 had, that is no longer in places, and that broke foxmarks?
dietrich i think it's that seps can have labels, and they sometimes show up in the UI
dietrich and foxmarks may have been using them for identification
sspitzer I think we'd want to support that, if the current places back end does not.
sspitzer for "reference implementation of sync client (P2)"
sspitzer I'm not sure about that one.
dietrich do you mean support the 'named' part? or just unique identifiers?
sspitzer I mean: seps should get guids, and if the could have labels in fx2, but can't in the current backend in places, I think we need to add that.
sspitzer so that nothing that gets lost when importing up from fx2
dietrich sspitzer: ok, lets leave it on there, and i'll address it w/ the data model changes
sspitzer ok. I've got yor name by lots of hard problems:
sspitzer all the ones in Sync / remote
dietrich haha rad
sspitzer and same with API / Data Model / Arch, but I'm sure dmills and I will get in on the action.
sspitzer I'm not sure what to do Tags and Livemarks yet.
dietrich we can discuss that more at the summit
sspitzer another time for the top of the list: schedule meetings for the summit
dietrich yes
dietrich i think they're going to do the open sessions again
dietrich we should have a places session
dietrich and possibly another breakout session for us to talk tasks, status, whatever arch issues are still open
sspitzer sounds good.
dietrich is that it for the list?
sspitzer yes. here's the overall picture, I think:
sspitzer at the start, you have lots of hard API / data model problems and decisions and I am going to be doing some history UI stuff, and dmills (who also has some non places work on his plate) will be starting on some perf / tinderbox related stuff.
sspitzer does the task list sort of reflect that?
dietrich yeah
sspitzer are you cool with that, for a starting point? everything can change, of course!
dietrich yes, that's fine to get us moving
dietrich i'll post the data model evaluation stuff so we can get public comment on it
sspitzer cool, and I'll go log the history UI meta bug and the dependent bugs (so we can SWAG / divide it up)
dietrich k
sspitzer any objection to me posting this chat log (or a link to it) into the newsgroup (m.d.a.firefox) after I post the "kickoff" post?
dietrich sure, or just post it to the wiki as meeting notes, and point people to the wiki in your post
dietrich we might want to set up weekly irc meetings like this, and then just post the log to the wiki each week
sspitzer good idea. how about mentioning in my kick off post that we will be meeting in #places at 4pm thursdays PST?
sspitzer (or is that not a good time for you?)
dietrich sounds good :)
dietrich wfm
sspitzer (worldwide, is that an ok time?)
sspitzer (east coast?)
dietrich uh, yeah we might want to do it in the AM, if we think east coasters and euros want to be there
dietrich well, but this is more team meeting than a progress report
dietrich let's just keep it at 4 for now
dietrich if people want a different time, they'll ask :)
sspitzer ok, will do. I'll say our team meeting is 4pm thur PST.