MozillaWiki - User contributions [en]

Mobile/Notes/13-Oct-2010

2010-10-13T16:31:31Z

Crowder: /* Performance */

== Details ==

* Wednesdays - 9:30am Pacific, 12:30pm Eastern, 16:30 UTC
* 650-903-0800 or 650-215-1282 x92 Conf# 8605 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 8605 (US)
* irc.mozilla.org #mobile for backchannel

== Schedule ==
* Beta 1 has shipped
* Beta 2
** String freeze: Oct 9
** Code freeze: Oct 19

== Major Topics for This Week ==

== Front-end ==
* Primarily working on Beta 2 [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking-fennec%3A2.0b2%2B blockers]
** Triaging the blocker list to move out non-critical bugs
* Also working on other blockers and some performance/optimization bugs
* Features (see [[Mobile/Planning/2.0 | Planning]] page)
** Work re-started on scroll indicators
** Need to re-evaluate the page interactions feature
* New Core (nee Android) theme is underway
** Martell is supplying styles and glyphs
** Vivien landed first patch and we regressed Twinopen by ~180ms
** We are re-working the theme with less "slow" CSS parts
** We are breaking up the theme into smaller parts

=== UX design ===
* theme work ongoing in {{bug|575403}}
** WIP screenshots here http://www.flickr.com/photos/madhava_work/sets/72157625031737595/detail/
** link to mocks as well: http://www.flickr.com/photos/madhava_work/collections/72157625031739669/
* reviewing ux b2-intended ux bugs

== Maemo ==

=== Qt ===

== Android ==

== Electrolysis ==

== General Platform ==

=== Video ===

=== Camera ===

=== Plugins ===

=== Performance ===

*Investigated Sync perf
**Encrypt/decrypt off-main-thread patch is done (by philiKON) just needs approval..  this helps enormously with responsiveness during esp. first sync (bug 570619)
**Patch to remove "tmp" sqlite tables helps with errors/warnings that are perf-related during first sync (bug 552053), but might cause other issues (bug 585704)
**Dug into JS perf tools for profiling issues like this (not quite ready for prime-time, but soon -- maybe a week?)

=== Networking ===

=== Graphics ===

=== Startup ===

=== Layout ===

=== Content ===

== Release Engineering ==

== QA ==

== Other ==

Mobile/Fennec/Android

2010-09-29T22:02:22Z

Crowder: typo fixes

== Developing Fennec for Android ==

This page contains developer information about [[Mobile/Platforms/Android|Firefox for Android]], part of the [[Fennec]] project.

To download Firefox for Android or learn more about it, see the main '''[[Mobile/Platforms/Android|Fennec for Android]]''' page.

== Current Status ==

* [[Android/Status|Current bugs]]

== Download Source Code ==

Check out the mozilla-central [[Mercurial]] repository, and the separate mobile-browser repository in a subdirectory called "mobile":

hg clone http://hg.mozilla.org/mozilla-central
cd mozilla-central
hg clone http://hg.mozilla.org/mobile-browser mobile

== Install Dependencies ==

* Standard [https://developer.mozilla.org/En/Linux_Build_Prerequisites Linux build environment] or [https://developer.mozilla.org/En/Developer_Guide/Build_Instructions/Mac_OS_X_Prerequisites Mac OS X build environment]
* [http://ftp.mozilla.org/pub/mozilla.org/mobile/source/ Android NDK] - This version is based on the original [http://developer.android.com/sdk/ndk/ Android NDK], modified to include C++ standard libraries and sys/queue.h.
* [http://developer.android.com/sdk/ Android SDK]

=== Set up a build environment ===

==== Ubuntu 10.04 ====
sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
sudo apt-get update
sudo apt-get build-dep firefox
sudo apt-get install sun-java6-jre sun-java6-plugin sun-java6-fonts sun-java6-jdk
sudo update-java-alternatives -s java-6-sun
if Running on amd64 or ia64 (basically 64bit linux), install the ia32-libs package :
sudo apt-get install ia32-libs
Then install Android sdk and ndk :
wget http://dl.google.com/android/android-sdk_r06-linux_86.tgz
tar xzf android-sdk_r06-linux_86.tgz
wget http://ftp.mozilla.org/pub/mozilla.org/mobile/source/android-ndk-r4c-0moz3.tar.bz2
tar xjf android-ndk-r4c-0moz3.tar.bz2
./android-sdk-linux_86/tools/android update sdk

==== Fedora 13 ====

yum install \
cvs zip gcc-c++ glib2-devel gtk2-devel fontconfig-devel libnotify-devel \
libIDL-devel alsa-lib-devel libXt-devel freetype-devel pkgconfig \
dbus-glib-devel curl-devel autoconf213 xorg-x11-proto-devel libX11-devel \
libXau-devel libXext-devel wireless-tools-devel glibc-static yasm

Install java: http://wporta.wordpress.com/2010/07/06/installing-jdk-in-fedora-13/

Then install Android sdk and ndk :
wget http://dl.google.com/android/android-sdk_r06-linux_86.tgz
tar xzf android-sdk_r06-linux_86.tgz
wget http://ftp.mozilla.org/pub/mozilla.org/mobile/source/android-ndk-r4c-0moz3.tar.bz2
tar xjf android-ndk-r4c-0moz3.tar.bz2
./android-sdk-linux_86/tools/android update sdk

=== Quickstart (Linux) ===

Download the SDK and NDK:

wget http://dl.google.com/android/android-sdk_r06-linux_86.tgz
wget http://ftp.mozilla.org/pub/mozilla.org/mobile/source/android-ndk-r4c-0moz3.tar.bz2

Then unpack them:

tar xvfj android-ndk-r4c-0moz3.tar.bz2
tar xvfz android-sdk_r06-linux_86.tgz

Install Java runtime and JDK:

sudo apt-get install sun-java6-jre sun-java6-plugin sun-java6-fonts sun-java6-jdk

'''Ubuntu note:''' be sure to install the Sun or OpenJDK version of Java, gcj will not work. In Ubuntu 10.04 Sun Java was moved to the Partner repository. Open the Software Center, edit Software Sources and enable the Partner repository.

Android SDK needs to be setup manually.

* In the SDK directory, run tools/android
* Check Settings->Force https://... sources to be fetched using http://...
* Click Save & Apply
* Installed Packages->Update All...
* Select at least the Android SDK, API level 6. Optionally you can install API levels 4 and 8.
* Click Install, Accept, etc.

== Build Fennec for Android ==

=== Full Build ===

Normal Firefox build, with the following mozconfig. (Put this in a file called "mozconfig" in your top-level source directory.)

OBJDIR=objdir-android
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/$OBJDIR

# Add the correct paths here:
ac_add_options --with-android-ndk="CHANGE/PATH/TO/android-ndk-r4c"
ac_add_options --with-android-sdk="CHANGE/PATH/TO/android-sdk-linux_86/platforms/android-8"
ac_add_options --with-android-tools="CHANGE/PATH/TO/android-sdk-linux_86/tools"

# android options
ac_add_options --enable-application=mobile
ac_add_options --target=arm-android-eabi
ac_add_options --with-endian=little

# Uncomment to run on ARMv5 or ARMv6 devices, including the emulator
#ac_add_options --disable-thumb2

ac_add_options --disable-tests

export MOZ_DEBUG_SYMBOLS=1

A standard build should succeed with those paths.

After that build finishes, a <tt>make -C embedding/android</tt> in the OBJDIR should generate a fennec.apk that's installable on an Android device using <tt>adb install fennec.apk</tt> -- to remove it you need to use the reverse domain name for the package: <tt>adb uninstall org.mozilla.fennec</tt>.

=== JS/NSPR only ===

In the commands below, replace these with the appropriate paths:

* <tt>$NDK</tt> is the NDK location
* <tt>$moz</tt> is the mozilla-droid repo checkout
* <tt>$out</tt> is some base destination directory

First, regenerate configure in the js dir (the nspr configure is checked in):

cd $moz/js/src && autoconf2.13

Then create a nspr directory, configure nspr, and build it:

cd $out
mkdir nspr
cd nspr
$moz/nsprpub/configure \
--target=arm-android-eabi \
--with-android-ndk=$NDK
make -s

Then do the same for JS, telling it where to find the NSPR you just built:

cd $out
mkdir js
cd js
$moz/js/src/configure \
--target=arm-android-eabi \
--with-android-ndk=$NDK \
--with-nspr-cflags=-I$out/nspr/dist/include/nspr \
--with-nspr-libs='-L$out/nspr/dist/lib -lnspr4 -lplc4 -lplds4' \
--enable-threadsafe \
--with-endian=little \
--with-arm-kuser
make -s

More information about NSPR is on [[Android/NSPR|this separate page]].

== Run JS/NSPR on Android ==

You'll need to copy the NSPR libraries and the js shell to the emulator or your device. Whether you're running on a physical device or an emulator, /data/local should be writable by the user.

cd $out/nspr/dist/lib
for f in *.so ; do adb push $f /data/local ; done
cd $out/js/shell
adb push js /data/local

Then, connect to a shell on the device, and run js (adb shell prompts prefixed with "android"):

% adb shell
android% cd /data/local
android% LD_LIBRARY_PATH=. ./js
js> 1+1
2

== Debugging with GDB ==

=== Preparation ===

Debugging with gdbserver requires root access. If you have not rooted your phone, search the web for instructions for your particular device. Or see [[User:Blassey/Notes/Android#debugging_without_rooting|notes on debugging without root access]].

=== Using nVidia version (recommended) ===

Need to document here. See [[User:Blassey/Notes/Android]] for how to install.

Note that you'll still need to pull the system libraries as described in the next section -- don't skip it entirely just because you've gotten the NVIDIA gdb.

=== Using the NDK version ===

NOTE: Fennec might crash when attaching using the gdb binaries included in the Google NDK. nVidia's gdb binaries are better.

If you do not already have gdbserver on your device (use <tt>adb shell gdbserver</tt> to check), you can push a pre-built version from the NDK.

adb push /PATH/TO/android-ndk-r4/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/gdbserver /data/local

Copy the necessary files from your device via adb pull. /system/bin/linker is referred to by absolute path so setting solib-absolute-prefix in gdb will be necessary for it to be found. Other files can be placed anywhere as long as they can be found in solib-search-path.

In short, find a directory to put some libraries, make sure adb is in your path, and paste this into your terminal:

adb pull /system/bin/linker . &&
adb pull /system/bin/app_process . &&
mkdir -p system/bin &&
mv linker system/bin &&
for LIB in libc.so libm.so libstdc++.so liblog.so libz.so libGLESv1_CM.so
do
adb pull /system/lib/$LIB .
done

=== Attach GDB ===

* launch in debug mode:
(Host)$ adb shell am start -a org.mozilla.gecko.DEBUG \
-n org.mozilla.fennec/org.mozilla.fennec.App
* Forward a port for gdb between your device and computer using adb. Any port you can open should work. 1234 is used here.
(Host)$ adb forward tcp:1234 tcp:1234
* Find the pid of your process if you don't know it. You can look at the second column of <tt>adb shell ps|grep fennec</tt>.
* Attach gdbserver to the process
(Host)$ adb shell /data/local/gdbserver localhost:1234 --attach YOURPID
Attached; pid = YOURPID
Listening on port 1234
* Run arm-eabi-gdb on your binary. (android-ndk-1.6_r1/build/prebuilt/linux-x86/arm-eabi-4.2.1/bin) For debugging gecko, a copy of app_process from your device should be used. (Note that <tt>app_process</tt> is not a variable name -- it is actually a binary pulled from the device in the previous section.)
(Host)$ /PATH/TO/NDK/build/prebuilt/linux-x86/arm-eabi-4.2.1/bin/arm-eabi-gdb app_process
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-elf-linux"...
* Configure solib-absolute-prefix. This will point to the directory where you unpacked your system image or where you copied the libraries.
(Host gdb) set solib-absolute-prefix ANDROIDLIBS
* Configure solib-search-path. This needs to point to the directories you need debugging symbols from - /system/lib or where ever you copied the libraries.
(Host gdb) set solib-search-path ANDROIDLIBS:ANDROIDLIBS/system/lib:OBJDIR/dist/bin
* Connect to gdbserver
(Host gdb) target remote localhost:1234
* These three Host gdb commands can be placed in a .gdbinit file to automate future gdb runs. .gdbinit should be located where you normally run gdb.

=== Automating gdbserver setup ===
You can use the script below to setup gdbserver:

<pre>
#!/bin/bash
PORT=1234
PID=""

# By default, this will attach to the parent process.
# Use "plugin-container" as argument to attach to child.
if [ -z $1 ]; then
GREP=org.mozilla.fennec
else
GREP=$1
fi

adb forward tcp:$PORT tcp:$PORT &&
adb shell am start -a org.mozilla.gecko.DEBUG -n org.mozilla.fennec/org.mozilla.fennec.App &&
while [ -z $PID ]; do
PID=`adb shell ps | grep $GREP | head -n 1 | cut -c11-16`
done &&
adb shell run-as org.mozilla.fennec /data/local/gdbserver localhost:$PORT --attach $PID
</pre>

=== Debugging on Galaxy S devices ===

These include AT&T Galaxy S, Tmobile Vibrant, Sprint Epic.

Unfortunately, it appears that android v2.1 denies non-root programs the ptrace capability, which means that non-root gdb (and breakpad!) won't work there. So if you have 2.1, you need to root first.
* [http://samsungvibranthacks.com/samsung-vibrant-hacks/how-to-root-samsung-vibrant-galaxy-s/ T-mobile Vibrant]
* ???
To ensure that your device is rooted (at least partially), run the following commands while the home screen is unlocked: you'll need to grant superuser permissions on the device itself.
adb shell
su
If you get a <code>#</code> prompt, you're good to go.

Next find a good directory for your gdb install and set up gdb. The dir where you installed the NDK/SDK works well. Let's call that dir <code>~/android</code>
cd ~/android
mkdir gdb && cd gdb
wget http://developer.download.nvidia.com/tegra/files/tegra-gdb-20100430.zip
unzip tegra-gdb-20100430.zip
rm -f debug.sh and install.sh
tegra-gdb ships with install.sh and debug.sh scripts, but they don't work with the root above for the T-mobile Vibrant. So we'll create our own ~/android/gdb/install.sh.
chmod +x prebuilt/linux-x86/arm-eabi-gdb
adb push prebuilt/gdbserver /data/local
adb shell chmod 755 /data/local/gdbserver
mkdir lib && cd lib
adb pull /system/bin/linker .
adb pull /system/bin/app_process .
mkdir -p system/bin
mv linker system/bin
for file in $(adb shell ls /system/lib | tr "\n" " " | tr "\r" " "); do
adb pull /system/lib/$file .
done
Then
bash install.sh
Now you're ready to start gdbserver and gdb. The tegra-gdb has a bug in which it apparently can't find threads created before it attaches to a process. This sounds like an easy bug to fix, but a workaround is to use the DEBUG intent as follows.
adb forward tcp:12345 tcp:12345
adb shell
su
am start -a org.mozilla.gecko.DEBUG -n org.mozilla.fennec/org.mozilla.fennec.App
On device, you should see a button that says "Launch". Fennec is now waiting for you to connect with gdb. Back in the adb shell
ps
# you should see a line like
# app_95 7549 2204 248356 26264 ffffffff 83844aa8 D org.mozilla.fennec
# the first number is the PID
/data/local/gdbserver localhost:12345 --attach 7549
If that goes well, gdbserver should print something like
Attached; pid = 7549
Listening on port 12345
You're now ready to connect a local gdb to the gdbserver on device. We'll pretend that you installed tegra-gdb and the device libs into <code>/home/cjones/android/gdb</code>, and that your objdir is <code>/home/cjones/mozilla/ma-opt/dist/bin</code>. Then in a new host shell (or emacs gdb), point gdb at the right symbols by running
~/android/gdb/prebuilt/linux-x86/arm-eabi-gdb ~/android/gdb/lib/app_process
# (in gdb)
set solib-absolute-prefix /home/cjones/android/gdb/lib
set solib-search-path /home/cjones/android/gdb/lib:/home/cjones/android/gdb/lib/system/lib:/home/cjones/mozilla/ma-opt/dist/bin
You very much want to add this setup to a .gdbinit script. Finally, connect to the gdbserver
target remote localhost:12345
If all goes well, you should see something like
(gdb) target remote localhost:12345
Remote debugging using localhost:12345
Reading symbols from /home/cjones/android/gdb/lib/system/bin/linker...(no debugging symbols found)...done.
Loaded symbols for /home/cjones/android/gdb/lib/system/bin/linker
Reading symbols from libc.so...(no debugging symbols found)...done.
Loaded symbols for libc.so
[snip]
0xafe0d9c4 in __futex_wait () from libc.so
(gdb) bt
#0 0xafe0d9c4 in __futex_wait () from libc.so
#1 0xafe0f444 in __pthread_cond_timedwait_relative () from libc.so
#2 0xafe0f4d0 in __pthread_cond_timedwait () from libc.so
#3 0xad0402d6 in ?? () from libdvm.so
#4 0xad0402d6 in ?? () from libdvm.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The final warning about a corrupt stack appears to be a quirk of the Dalvik VM's implementation, and isn't worrisome because the Java frames would be meaningless in C++ anyway.

To connect to a content process, the steps are mostly the same, except you want to start fennec with
am start -a org.mozilla.gecko.DEBUG -n org.mozilla.fennec/org.mozilla.fennec.App --es env0 MOZ_DEBUG_CHILD_PROCESS=1
attach to a process that looks like
app_95 16029 16005 20488 5852 c03b08dc afe0d0ac S /data/data/org.mozilla.fennec/plugin-container
and start android-gdb with
~/android/gdb/prebuilt/linux-x86/arm-eabi-gdb $objdir/dist/bin/plugin-container

== Running tests on device ==

It's probably going to be painful, prepare thyself.

=== JS trace-tests ===

A rooted device isn't required to run trace-tests. One may or may not be required to debug test failures, see debugging instructions bove.

Install the "android scripting environment" (sl4a_r*.apk) and the python interpreter (python_for_android_r*.apk) from [http://code.google.com/p/android-scripting/downloads/list here].

You need to apply the "Support for debugging on android" patch from {{bug|600488}} for the time being.
hg qimport -n adbg bz:600488 && hg qpush

Set up a local staging directory for files to be pushed to device. We'll push all the junk to /data/local/js/.
mkdir testjs
cd testjs
wget https://bugzilla.mozilla.org/attachment.cgi?id=479421 -O - > testjs.py
mkdir js
cp $objdir/js/src/js \
$objdir/memory/mozalloc/libmozalloc.so \
$objdir/nsprpub/pr/src/libnspr4.so \
$objdir/nsprpub/lib/libc/src/libplc4.so \
$objdir/nsprpub/lib/ds/libplds4.so \
js/
cp -R $srcdir/js/src/trace-test js/trace-test
adb push js /data/local/js
adb push testjs.py /sdcard/sl4a/scripts/

Time for a sanity check. Try running
adb shell LD_LIBRARY_PATH="/data/local/js" /data/local/js/js
You may or may not get a "> " prompt (and if you do, it's broken anyway), but if you don't see any error messages you're probably good to go.

testjs.py is a wrapper script for trace_test.py (and soon other tests). We'll run testjs.py using the python interpreter. If the scripting environment wasn't broken, you could run the tests with
$ am start -a com.googlecode.android_scripting.action.LAUNCH_TERMINAL -n com.googlecode.android_scripting/.activity.ScriptingLayerServiceLauncher -e com.googlecode.android_scripting.extra.SCRIPT_NAME testjs.py
(lol! java). But it is broken. So instead, you need to launch the "SL4A" application and then click "testjs.py". Choose the "terminal" icon to run the script in the built-in terminal. You should then see trace-test's usual progress meter.

When all the tests finish, the failed tests and their output will be in the file /data/local/js/trace-test-failures.txt (it gets stomped on every test run, beware). You may need to mark the /data/local/js directory as writable by all in order for the script to sae its output. See the results with
$ adb shell cat /data/local/js/trace-test-failures.txt
basic/testComparisons.js
Exit code: -11 # oops, segfault
...

To debug a particular test, use the newly-added <code>js -g</code> option, which has jsshell sleep for 30 seconds on startup, and then attach with gdb using the instructions above.
adb shell LD_LIBRARY_PATH="/data/local/js" /data/local/js/js -g -j -e "const platform='linux2'; const libdir='/data/local/js/trace-test/lib/';" -f /data/local/js/trace-test/lib/prolog.js -f /data/local/js/trace-test/tests/basic/testComparisons.js
# attach using gdb instructions for your device

You run trace-test with custom options by editing testjs.py. For example, to run with -mj, add
trace_test.main([
JS,
'--avoid-stdio',
+ '--jitflags', 'mj',
'--write-failure-log', failures_file
])
then
adb push testjs.py /sdcard/sl4a/scripts/.
and re-run using the instructions above.

== Profiling ==

oprofile is enabled in the kernel on the G1 dev phone and SDK emulator images. The oprofile programs (opcontrol, oprofiled) are in <tt>/system/xbin</tt>.

== Android Development Tips ==

* You can build a full Android OS from source [http://wiki.cyanogenmod.com/index.php?title=Building_from_source following the instructions on Cyanogen's site]. This helps tremendously with debugging.
* Running in the Android SDK emulator requires a build with --disable-thumb2. You might also need to change the emulator options to give it enough space to install and run Fennec: <tt>emulator -partition-size 256 -memory 512</tt>
* Pass command line arguments to Fennec as "extras" using the -es argument: <tt>adb shell am start -n org.mozilla.fennec/org.mozilla.fennec.App -es -safe-mode</tt>

Nightly builds are available unsigned, so that you can sign them with your local debug key and install them on top of your own debug builds (without uninstalling and losing your profile). To sign and install the unsigned nightly build:

wget http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-android-r7/gecko-unsigned-unaligned.apk
jarsigner -keystore ~/.android/debug.keystore -storepass android -keypass android gecko-unsigned-unaligned.apk androiddebugkey
zipalign -f -v 4 gecko-unsigned-unaligned.apk gecko-signed-aligned.apk
adb install -r gecko-signed-aligned.apk

== Passing in environment variables to Fennec ==

<pre>
adb shell am start -a org.mozilla.fennec -n org.mozilla.fennec/org.mozilla.fennec.App --es env0 KEY=VALUE
</pre>

== Updates ==
* [[Mobile/Fennec/Android/Updates|Updates check implementation]]

== Other Resources ==

* [https://wiki.mozilla.org/User:Joel_Reymont/Android_Notes Joel's Notes]
* [https://wiki.mozilla.org/User:VladVukicevic/Android_Notes Vlad's Notes]
* [http://hg.mozilla.org/users/vladimir_mozilla.com/android-testapp/ Vlad's Test App Hg Repo]

Mobile/Notes/15-Sep-2010

2010-09-15T16:39:43Z

Crowder: /* Networking */

== Details ==

* Wednesdays - 9:30am Pacific, 12:30pm Eastern, 16:30 UTC
* 650-903-0800 or 650-215-1282 x92 Conf# 8605 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 8605 (US)
* irc.mozilla.org #mobile for backchannel

== Schedule ==
* See [[Mobile/Planning/2.0#Timeline | timeline]]
** Beta 1 code freeze: Sept 13 (slipped but we are close)
** Design freeze: Sept 16
** Beta 2 code freeze: Sept 23 (might depend on Beta 1 slip)

== Major Topics for This Week ==

* Crashes
** {{bug|595868}} 20 second crash (garbage collection related? we have stack traces on Android but reported on Maemo, may not even be same issue)
** {{bug|596382}} N900 content crash (shows content for a little while)
** {{bug|596433}} Illegal instruction on Android (has a fix, needs a little work)
** {{bug|594563}}, {{bug|596482}} Regular expression on Android

== Front-end ==

* Working on Beta 1 [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking-fennec%3A2.0b1%2B blockers]
* Also working on Beta 2 [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking-fennec%3A2.0b2%2B blockers]
** Login Manager patchs landed and we have some followup work for it
** Tile Manager patch has been reviewed and should be OK to land when cedar lands on m-c. We have some followup bugs to file.
* Features (see [[Mobile/Planning/2.0 | Planning]] page)
** Sharing backend for Android and Maemo was pushed to Beta 2
** Beta Feedback XPI landed
** We have done some work on simplifying the downloads around downloading
** Webapps for Maemo might land for Beta 1
** RSS support is ready for another review
** Android theme is underway
** Need Madhava feedback on Master Password patch
** Making a final decision on clipboard context menu
* Working with Madhava on UX designs and loose ends
** Design freeze is looming

=== UX design ===

* Android theme work is ready for final review; see it here:
http://www.flickr.com/photos/madhava_work/sets/72157624962763028/
** accompanying notes on their way

* finishing flow explanations for
** meego vkb
** android and meego sharing (just to be perfectly clear!)
** copy paste

The following set of bugs describes the changes to what's in the nightly front end to get to what we want. In terms of screen layout, the android theme mockups (and bug) shows the changes required.

*Add-ons Manager
**{{bug|596594}} - ability to browse more add-ons in add-ons manager
**{{bug|594795}} - Add a "What's an Add-on" block to the Add-ons Manager
*Sharing redesign
**{{bug|596609}} - share items from the awesomescreen
**{{Bug|596615}} - autobookmark shared pages/links
**{{Bug|596632}} - on n900, make sure that SMS and email are sharing options
*Awesomescreen
** {{bug|596612}} - indicate "remote" pages in awesomescreen results
** {{bug|596614}} - focusing the URL field on the awesomescreen should not visibly change categories
**{{bug|596626}} - Use the vkb with "Go" button when on awesomescreen
**{{bug|594918}} - dismiss vkb as a user starts to pan the awesomelist
* Titlebar
** {{bug|596617}} - stop button should be responsive
*Find in page
** {{bug|596619}} - panning the page during findbar use shouldn't dismiss the findbar
** {{Bug|596621}} - findbar - need to indicate when no matches found
*Undo Close Tab
** {{bug|582583}} - Expose a small, simple UI for 'Undo Closed Tab'
*Presf Pane
** {{bug|596629}} - Use vkb with "next" button when in prefs (sync)
*Themeing
** {{bug|596625}} - Theme Fennec for Android

== Maemo ==

=== Qt ===

== Android ==
* Custom dlopen {{bug|588607}} 2/3rds done
** Can load libraries via our own dlopen
** Need to add new interface to load from regions within a file
** Compression may be difficult
* Investigating using gold {{bug|596024}}

== Electrolysis ==

== Layers==

[[Mobile/Layers#2.0_b1_TODO|Some TODOs for b1]].

== General Platform ==

=== Geolocation Working Group ===

=== Video ===

=== Camera ===
* Slipping the last of the platform pieces that aren't NPOTB for firefox into the tree today. (565843 needs approval2.0)
* Dealing with a fun bug that a previous patch exposed (Bug 594964)

=== Plugins ===

=== Performance ===

=== Networking ===

* Patches done for nsIEncodedChannel support in e10s (needed to get gzip/gunzip right for some cases), need review+landing, which should hopefully happen today.
* Working on Pause/Resume regression described in {{bug|596402}}
* Working w/ Honza on crash/assert-botch described in {{bug|596059}}

=== Graphics ===

=== Startup ===

=== Layout ===

=== Content ===

== Release Engineering ==

* android update status -- in progress.
** patches look good but i'm uploading snippets to the wrong place -- i need to upload them to the *previous* nightly's buildid; same with release patches
** hoping to fix/review/land nightly patches today.
* android l10n -- will need to investigate how omnijar will change things
* android tests -- launching tests, running into remote logging issues
** bear to try using patches attached to bugs
*** android unit/talos tests testing with patch for {{bug|596132}} to finalize steps
** bug to order 10 tegras filed

== QA ==
=== Manual ===
* QA is having a work week, so take this opportunity to take to your 2.0 feature QA for anything that they should know.
* Notes:
** Builds are complete broken over the past 2-3 days. We can't provide any test coverage [https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&chfieldto=Now&chfield=bug_status&query_format=advanced&chfieldfrom=2010-08-10&chfieldvalue=resolved&bug_status=RESOLVED&product=Fennec on a lot of bugs] until builds are actually stable.
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=595868 Builds are crashing]
**** Others: {{bug|596482}}, {{bug|596289}}, {{bug|596433}}, {{bug|594563}}
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=596382 Pages don't load] because the content process crashes
*** Finally, why is [https://bugzilla.mozilla.org/show_bug.cgi?id=596610 tinderbox green across the board] when all of our builds are crashing on startup?
*** Finallyx2, why did we not branch before jagermonkey landed?
*** Finallyx3, where was the testing on ARM for jagermonkey before it landed?
* New Bugs over the week: [http://bit.ly/97ReXI filed]
* Results from [https://wiki.mozilla.org/QA/Fennec/Waverley#Results nightly Smoketest runs].
* [http://quality.mozilla.org/qmo-news/2010/09/14/firefox-moible-2-beta-testday-results/ MobiFx Testday] Results

=== Automation ===
* talos
** {{bug|582997}} - working patch for android and n900, need to land

* android
** lots of little fixes in the patch queue now, sounds like :bear has done a lot of work as we are finding some of these little bugs now:)

* browser-chrome - need some attention, carryover from last week
** new test files {{bug|489163}} and {{bug|570706}} are blocked on awesomebar problem
** {{bug|593463}} - awesomescreen.js problem

* [[https://wiki.mozilla.org/Mobile/Fennec_Unittests/green#mochitest mochitest: green]]
** {{bug|590121}} - FIXED
** {{bug|590248}} and {{bug|587646}} account for 60% of known mochitest failures on n900!, no progress on these two bugs?! Still no traction on this - WEEK #4!!!

== Other ==

Mobile/Notes/15-Sep-2010

2010-09-15T16:38:45Z

Crowder: /* Networking */

== Details ==

* Wednesdays - 9:30am Pacific, 12:30pm Eastern, 16:30 UTC
* 650-903-0800 or 650-215-1282 x92 Conf# 8605 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 8605 (US)
* irc.mozilla.org #mobile for backchannel

== Schedule ==
* See [[Mobile/Planning/2.0#Timeline | timeline]]
** Beta 1 code freeze: Sept 13 (slipped but we are close)
** Design freeze: Sept 16
** Beta 2 code freeze: Sept 23 (might depend on Beta 1 slip)

== Major Topics for This Week ==

* Crashes
** {{bug|595868}} 20 second crash (garbage collection related? we have stack traces on Android but reported on Maemo, may not even be same issue)
** {{bug|596382}} N900 content crash (shows content for a little while)
** {{bug|596433}} Illegal instruction on Android (has a fix, needs a little work)
** {{bug|594563}}, {{bug|596482}} Regular expression on Android

== Front-end ==

* Working on Beta 1 [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking-fennec%3A2.0b1%2B blockers]
* Also working on Beta 2 [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking-fennec%3A2.0b2%2B blockers]
** Login Manager patchs landed and we have some followup work for it
** Tile Manager patch has been reviewed and should be OK to land when cedar lands on m-c. We have some followup bugs to file.
* Features (see [[Mobile/Planning/2.0 | Planning]] page)
** Sharing backend for Android and Maemo was pushed to Beta 2
** Beta Feedback XPI landed
** We have done some work on simplifying the downloads around downloading
** Webapps for Maemo might land for Beta 1
** RSS support is ready for another review
** Android theme is underway
** Need Madhava feedback on Master Password patch
** Making a final decision on clipboard context menu
* Working with Madhava on UX designs and loose ends
** Design freeze is looming

=== UX design ===

* Android theme work is ready for final review; see it here:
http://www.flickr.com/photos/madhava_work/sets/72157624962763028/
** accompanying notes on their way

* finishing flow explanations for
** meego vkb
** android and meego sharing (just to be perfectly clear!)
** copy paste

The following set of bugs describes the changes to what's in the nightly front end to get to what we want. In terms of screen layout, the android theme mockups (and bug) shows the changes required.

*Add-ons Manager
**{{bug|596594}} - ability to browse more add-ons in add-ons manager
**{{bug|594795}} - Add a "What's an Add-on" block to the Add-ons Manager
*Sharing redesign
**{{bug|596609}} - share items from the awesomescreen
**{{Bug|596615}} - autobookmark shared pages/links
**{{Bug|596632}} - on n900, make sure that SMS and email are sharing options
*Awesomescreen
** {{bug|596612}} - indicate "remote" pages in awesomescreen results
** {{bug|596614}} - focusing the URL field on the awesomescreen should not visibly change categories
**{{bug|596626}} - Use the vkb with "Go" button when on awesomescreen
**{{bug|594918}} - dismiss vkb as a user starts to pan the awesomelist
* Titlebar
** {{bug|596617}} - stop button should be responsive
*Find in page
** {{bug|596619}} - panning the page during findbar use shouldn't dismiss the findbar
** {{Bug|596621}} - findbar - need to indicate when no matches found
*Undo Close Tab
** {{bug|582583}} - Expose a small, simple UI for 'Undo Closed Tab'
*Presf Pane
** {{bug|596629}} - Use vkb with "next" button when in prefs (sync)
*Themeing
** {{bug|596625}} - Theme Fennec for Android

== Maemo ==

=== Qt ===

== Android ==
* Custom dlopen {{bug|588607}} 2/3rds done
** Can load libraries via our own dlopen
** Need to add new interface to load from regions within a file
** Compression may be difficult
* Investigating using gold {{bug|596024}}

== Electrolysis ==

== Layers==

[[Mobile/Layers#2.0_b1_TODO|Some TODOs for b1]].

== General Platform ==

=== Geolocation Working Group ===

=== Video ===

=== Camera ===
* Slipping the last of the platform pieces that aren't NPOTB for firefox into the tree today. (565843 needs approval2.0)
* Dealing with a fun bug that a previous patch exposed (Bug 594964)

=== Plugins ===

=== Performance ===

=== Networking ===

* Patches done for nsIEncodedChannel support in e10s (needed to get gzip/gunzip right for some cases), need review+landing, which should hopefully happen today.
* Working on Pause/Resume regression described in {{bug|596402}}

=== Graphics ===

=== Startup ===

=== Layout ===

=== Content ===

== Release Engineering ==

* android update status -- in progress.
** patches look good but i'm uploading snippets to the wrong place -- i need to upload them to the *previous* nightly's buildid; same with release patches
** hoping to fix/review/land nightly patches today.
* android l10n -- will need to investigate how omnijar will change things
* android tests -- launching tests, running into remote logging issues
** bear to try using patches attached to bugs
*** android unit tests waiting on {{bug|596132}} to finalize steps
*** android talos tests also waiting on {{bug|596132}} and steps are being iterated on now
** bug to order 10 tegras filed

== QA ==
=== Manual ===
* QA is having a work week, so take this opportunity to take to your 2.0 feature QA for anything that they should know.
* Notes:
** Builds are complete broken over the past 2-3 days. We can't provide any test coverage [https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&chfieldto=Now&chfield=bug_status&query_format=advanced&chfieldfrom=2010-08-10&chfieldvalue=resolved&bug_status=RESOLVED&product=Fennec on a lot of bugs] until builds are actually stable.
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=595868 Builds are crashing]
**** Others: {{bug|596482}}, {{bug|596289}}, {{bug|596433}}, {{bug|594563}}
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=596382 Pages don't load] because the content process crashes
*** Finally, why is [https://bugzilla.mozilla.org/show_bug.cgi?id=596610 tinderbox green across the board] when all of our builds are crashing on startup?
*** Finallyx2, why did we not branch before jagermonkey landed?
*** Finallyx3, where was the testing on ARM for jagermonkey before it landed?
* New Bugs over the week: [http://bit.ly/97ReXI filed]
* Results from [https://wiki.mozilla.org/QA/Fennec/Waverley#Results nightly Smoketest runs].
* [http://quality.mozilla.org/qmo-news/2010/09/14/firefox-moible-2-beta-testday-results/ MobiFx Testday] Results

=== Automation ===
* talos
** {{bug|582997}} - working patch for android and n900, need to land

* android
** lots of little fixes in the patch queue now, sounds like :bear has done a lot of work as we are finding some of these little bugs now:)

* browser-chrome - need some attention, carryover from last week
** new test files {{bug|489163}} and {{bug|570706}} are blocked on awesomebar problem
** {{bug|593463}} - awesomescreen.js problem

* [[https://wiki.mozilla.org/Mobile/Fennec_Unittests/green#mochitest mochitest: green]]
** {{bug|590121}} - FIXED
** {{bug|590248}} and {{bug|587646}} account for 60% of known mochitest failures on n900!, no progress on these two bugs?! Still no traction on this - WEEK #4!!!

== Other ==

Mobile/Notes/15-Sep-2010

2010-09-15T16:35:03Z

Crowder: /* Networking */

== Details ==

* Wednesdays - 9:30am Pacific, 12:30pm Eastern, 16:30 UTC
* 650-903-0800 or 650-215-1282 x92 Conf# 8605 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 8605 (US)
* irc.mozilla.org #mobile for backchannel

== Schedule ==
* See [[Mobile/Planning/2.0#Timeline | timeline]]
** Beta 1 code freeze: Sept 13 (slipped but we are close)
** Design freeze: Sept 16
** Beta 2 code freeze: Sept 23 (might depend on Beta 1 slip)

== Major Topics for This Week ==

* Crashes
** {{bug|595868}} 20 second crash (garbage collection related? we have stack traces on Android but reported on Maemo, may not even be same issue)
** {{bug|596382}} N900 content crash (shows content for a little while)
** {{bug|596433}} Illegal instruction on Android (has a fix, needs a little work)
** {{bug|594563}}, {{bug|596482}} Regular expression on Android

== Front-end ==

* Working on Beta 1 [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking-fennec%3A2.0b1%2B blockers]
* Also working on Beta 2 [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking-fennec%3A2.0b2%2B blockers]
** Login Manager patchs landed and we have some followup work for it
** Tile Manager patch has been reviewed and should be OK to land when cedar lands on m-c. We have some followup bugs to file.
* Features (see [[Mobile/Planning/2.0 | Planning]] page)
** Sharing backend for Android and Maemo was pushed to Beta 2
** Beta Feedback XPI landed
** We have done some work on simplifying the downloads around downloading
** Webapps for Maemo might land for Beta 1
** RSS support is ready for another review
** Android theme is underway
** Need Madhava feedback on Master Password patch
** Making a final decision on clipboard context menu
* Working with Madhava on UX designs and loose ends
** Design freeze is looming

=== UX design ===

* Android theme work is ready for final review; see it here:

* finishing flow explanations for
** meego vkb
** android and meego sharing (just to be perfectly clear!)
** copy paste

The following set of bugs describes the changes to what's in the nightly front end to get to what we want. In terms of screen layout, the android theme mockups (and bug) shows the changes required.

*Add-ons Manager
**{{bug|596594}} - ability to browse more add-ons in add-ons manager
**{{bug|594795}} - Add a "What's an Add-on" block to the Add-ons Manager
*Sharing redesign
**{{bug|596609}} - share items from the awesomescreen
**{{Bug|596615}} - autobookmark shared pages/links
**{{Bug|596632}} - on n900, make sure that SMS and email are sharing options
*Awesomescreen
** {{bug|596612}} - indicate "remote" pages in awesomescreen results
** {{bug|596614}} - focusing the URL field on the awesomescreen should not visibly change categories
**{{bug|596626}} - Use the vkb with "Go" button when on awesomescreen
**{{bug|594918}} - dismiss vkb as a user starts to pan the awesomelist
* Titlebar
** {{bug|596617}} - stop button should be responsive
*Find in page
** {{bug|596619}} - panning the page during findbar use shouldn't dismiss the findbar
** {{Bug|596621}} - findbar - need to indicate when no matches found
*Undo Close Tab
** {{bug|582583}} - Expose a small, simple UI for 'Undo Closed Tab'
*Presf Pane
** {{bug|596629}} - Use vkb with "next" button when in prefs (sync)
*Themeing
** {{bug|596625}} - Theme Fennec for Android

== Maemo ==

=== Qt ===

== Android ==
* Custom dlopen {{bug|588607}} 2/3rds done
** Can load libraries via our own dlopen
** Need to add new interface to load from regions within a file
** Compression may be difficult
* Investigating using gold {{bug|596024}}

== Electrolysis ==

== Layers==

[[Mobile/Layers#2.0_b1_TODO|Some TODOs for b1]].

== General Platform ==

=== Geolocation Working Group ===

=== Video ===

=== Camera ===
* Slipping the last of the platform pieces that aren't NPOTB for firefox into the tree today. (565843 needs approval2.0)
* Dealing with a fun bug that a previous patch exposed (Bug 594964)

=== Plugins ===

=== Performance ===

=== Networking ===

Patches done for nsIEncodedChannel support in e10s (needed to get gzip/gunzip right for some cases), need review+landing, which should hopefully happen today.

=== Graphics ===

=== Startup ===

=== Layout ===

=== Content ===

== Release Engineering ==

* android update status -- in progress.
** patches look good but i'm uploading snippets to the wrong place -- i need to upload them to the *previous* nightly's buildid; same with release patches
** hoping to fix/review/land nightly patches today.
* android l10n -- will need to investigate how omnijar will change things
* android tests -- launching tests, running into remote logging issues
** bear to try using patches attached to bugs
*** android unit tests waiting on bug 596132 to finalize steps
*** android talos tests also waiting on bug 596132 and steps are being iterated on now
** bug to order 10 tegras filed

== QA ==
=== Manual ===
* QA is having a work week, so take this opportunity to take to your 2.0 feature QA for anything that they should know.
* Notes:
** Builds are complete broken over the past 2-3 days. We can't provide any test coverage [https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&chfieldto=Now&chfield=bug_status&query_format=advanced&chfieldfrom=2010-08-10&chfieldvalue=resolved&bug_status=RESOLVED&product=Fennec on a lot of bugs] until builds are actually stable.
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=595868 Builds are crashing]
**** Others: {{bug|596482}}, {{bug|596289}}, {{bug|596433}}, {{bug|594563}}
*** [https://bugzilla.mozilla.org/show_bug.cgi?id=596382 Pages don't load] because the content process crashes
*** Finally, why is [https://bugzilla.mozilla.org/show_bug.cgi?id=596610 tinderbox green across the board] when all of our builds are crashing on startup?
*** Finallyx2, why did we not branch before jagermonkey landed?
*** Finallyx3, where was the testing on ARM for jagermonkey before it landed?
* New Bugs over the week: [http://bit.ly/97ReXI filed]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=591368 Beta Tester Tools] landed
* Results from [https://wiki.mozilla.org/QA/Fennec/Waverley#Results nightly Smoketest runs].
* [http://quality.mozilla.org/qmo-news/2010/09/14/firefox-moible-2-beta-testday-results/ MobiFx Testday] Results

=== Automation ===

== Other ==

LandingQueue

2010-09-13T18:37:46Z

Crowder: /* Ride-along patches */

= Landing Queue for Mozilla-Central =

Please add an item containing your name, the bugs you want to land, and what the blocking status of them is to the bottom of the list. After you push, remove yourself from the top of the list. You should only push after consulting with the tree sheriff.

* Your name, bug numbers and their blocker-status here.
* jdm - bug 474356

== Ride-along patches ==

Add yourself here if you would prefer that some kind soul check your patch in on your behalf. '''And make sure you've read [http://blog.bonardo.net/2010/06/22/so-youre-about-to-use-checkin-needed  So You're About To Use checkin-needed]!'''

* Priority ride-alongs are these [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking2.0%3Abeta6%20:toolkit,firefox%20kw%3Acheckin-needed checkin-needed B6 blockers].

Approval+ ride-alongs:
* crowder - bug 589025
* crowder - bug 591081

Mobile/Notes/01-Sep-2010

2010-09-01T16:10:27Z

Crowder: /* General Platform */

LandingQueue

2010-08-27T20:13:17Z

Crowder: /* Ride-along patches */

= Landing Queue for Mozilla-Central =
* Bas - blocking-beta5
* ddahl
** {{bug|591008}} - [orange] test fix r=sdwilsh a=sdwilsh
** {{bug|588730}} - r=dietrich a=blocking2.0
* mfinkle
** {{bug|584610}} - blocking-fennec (bump buffer size from 1024 to 8192)
* jlebar
** {{bug|590573}} - blocking beta N
** {{bug|589306}} - npotb
** {{bug|590179}} - ridealong from bz, a=beltzner
* felipe
** {{bug|574833}} - persona theme covers aero caption buttons (blocks betaN)
** {{bug|586961}} - Access key label click on label, not controlled element (blocks betaN)
** {{bug|575440}} - Deal with eWindowType_toplevel on WM_GESTURENOTIFY for bug 130078 landing (blocks 130078)
* gavin (bug 591026, bug 587691, bug 591371)
* tn: bug 130078 (make the world a better place)
* bz: bug 590179 (make mac faster)
*blassey
** {{bug|591153}}
** {{bug|591412}}

Please add an item containing your name, the bugs you want to land, and what the blocking status of them is to the bottom of the list. After you push, remove yourself from the top of the list. You should only push after consulting with the tree sheriff.

== Ride-along patches ==

Add yourself here if you would prefer that some kind soul check your patch in on your behalf. And make sure you've read http://blog.bonardo.net/2010/06/22/so-youre-about-to-use-checkin-needed !

* {{bug|562313}} [https://bugzilla.mozilla.org/attachment.cgi?id=469916 attachment 469916] - Links browsercomps into firefox.exe statically, approved for landing before beta5 (checkin data in patch)
* {{bug|587691}} - ready-to-import patch
* {{bug|416743}} - r=bz, not part of the build, killing a silly assertion

User:Blassey/Notes/Android

2010-08-18T19:17:29Z

Crowder: android:debuggable="true" is already in there

==Build Env==

After normal linux build pre-reqs:

wget ftp://ftp.mozilla.org/pub/mobile/source/android-ndk-r4c-0moz3.tar.bz2
wget http://dl.google.com/android/android-sdk_r06-linux_86.tgz
tar -xf android-sdk_r06-linux_86.tgz
tar -xjf android-ndk-r4-linux-x86-crystax-1.tar.bz2
./android-sdk-linux_86/tools/android update sdk

And already set up VM can be found here: http://lassey.us/droid-vm.7z

==Debugging==

Nvidia's gdb is better: http://developer.download.nvidia.com/tegra/files/tegra-gdb-20100430.zip

In order to attach before things get running, launch with:
adb shell am start -a org.mozilla.gecko.DEBUG -n org.mozilla.fennec/org.mozilla.fennec.App

and just click launch once gdb is attached. If you need to debug a crash that happens before XRE_Main is called, the patch on {{bug|572247}} may be useful.

===Env Vars===
If you need to set and env var at run time, use append --es env# VAR=VAL to your activity manager command where # is the ordered number of variables for example:
adb shell am start -a android.activity.MAIN -n org.mozilla.fennec/org.mozilla.fennec.App --es env0 VAR=val --es env1 FOO=bar

You may need {{bug|578493}} if the env var you're using is tested before XRE_Main is called

===PR Logging===
You can use the env vars as described above to make logging work (along with {{bug|578493}}). With just that you can log to a file
adb shell am start -a android.activity.MAIN -n org.mozilla.fennec/org.mozilla.fennec.App --es env0 NSPR_LOG_MODULES=all:5 --es env1 NSPR_LOG_FILE=/mnt/sdcard/log.txt

With the patch on {{bug|578496}} you can have the logging directed to the android logs and as such only need:
adb shell am start -a android.activity.MAIN -n org.mozilla.fennec/org.mozilla.fennec.App --es env0 NSPR_LOG_MODULES=all:5

==debugging without rooting==

with Froyo you can debug without rooting your phone. However to make this work with the nvidia gdb (which I found more reliable than the android r3 gdb) you need to modify install.sh and debug.sh.

first, change the location where install.sh copies gdbserver to somewhere writable by a non-root process. I used /data/local. Be sure to update that both in the push command and the chmod command.

second, update debug.sh with the new location of gdbserver.

finally, you'll need to add run-as $2 to the adb shell command that launches gdbserver. In the end you should have:
install.sh:
#!/bin/sh
mkdir lib
adb push prebuilt/gdbserver /data/local
adb shell chmod 755 /data/local/gdbserver
for file in $(adb shell ls /system/lib | tr "\n" " " | tr "\r" " "); do
adb pull /system/lib/$file lib
done
adb pull /system/bin/app_process lib

debug.sh:
!/bin/sh
if [ $# -ne 2 ]
then
echo "usage: $0 /path/to/your/library.so packagename.of.your.activity"
echo "for example:"
echo " $0 /code/mydemo/libs/armeabi/libmydemo.so com.nvidia.devtech.mydemo"
exit
fi

if [ ! -f $1 ]
then
echo "ERROR: That library file doesn't exist"
exit
fi

cp $1 lib

p=`adb shell ps | grep $2 | awk '{print $2}'`
if [ "$p" = "" ];
then
echo "ERROR: That doesn't seem to be a running process. Please make sure your"
echo "application has been started and that you are using the correct"
echo "namespace argument."
exit
fi

adb forward tcp:12345 tcp:12345
adb shell run-as $2 /data/local/gdbserver --attach :12345 $p

User:Blassey/Notes/Android

2010-08-18T19:07:26Z

Crowder: fixing what looks like a cut and paste error

LandingQueue

2010-08-18T03:29:26Z

Crowder: /* Landing Queue for Mozilla-Central */

= Landing Queue for Mozilla-Central =

Please add your name to the bottom of the list, the bugs you want to land and what the blocking status of them is. After you push, remove yourself from the top of the list. All pushes should be made after consulting with the tree sheriff. 

* roc - {{nbug|537890}} approved, {{nbug|497808}} blocking
* Bas - blocking-beta5+
* Josh, {{bug|578868}} blocking-beta5+
* bholley {{bug|512260}} blocking-beta5+
* birtles {{nbug|485157}} approved, {{nbug|544855}} blocking-betaN+ (away until 3am PDT, feel free to queue jump until then)
* mwu - landing Taras' patch - {{nbug|559961}} beta5+

== Ride-along patches ==

Add yourself here if you would prefer that some kind soul check your patch in on your behalf.

LandingQueue

2010-08-18T02:31:57Z

Crowder: /* Landing Queue for Mozilla-Central */

= Landing Queue for Mozilla-Central =

Please add your name to the bottom of the list, the bugs you want to land and what the blocking status of them is. After you push, remove yourself from the top of the list. All pushes should be made after consulting with the tree sheriff. 

* crowder - {{nbug|562444}} blocking-fennec2.0a1+
* roc - {{nbug|537890}} approved, {{nbug|497808}} blocking
* Bas - blocking-beta5+
* Josh, {{bug|578868}} blocking-beta5+
* bholley {{bug|512260}} blocking-beta5+
* birtles {{nbug|485157}} approved, {{nbug|544855}} blocking-betaN+
* mwu - landing Taras' patch - {{nbug|559961}} beta5+

== Ride-along patches ==

Add yourself here if you would prefer that some kind soul check your patch in on your behalf.

* robarnold - {{nbug|554982}} final+

LandingQueue

2010-08-18T02:25:42Z

Crowder: /* Landing Queue for Mozilla-Central */

= Landing Queue for Mozilla-Central =

Please add your name to the bottom of the list, the bugs you want to land and what the blocking status of them is. After you push, remove yourself from the top of the list. All pushes should be made after consulting with the tree sheriff. 

* roc - {{nbug|537890}} approved, {{nbug|497808}} blocking
* Bas - blocking-beta5+
* Josh, {{bug|578868}} blocking-beta5+
* bholley {{bug|512260}} blocking-beta5+
* birtles {{nbug|485157}} approved, {{nbug|544855}} blocking-betaN+
* crowder - {{nbug|562444}} blocking-fennec2.0a1+

== Ride-along patches ==

Add yourself here if you would prefer that some kind soul check your patch in on your behalf.

* Taras - {{nbug|559961}} beta5+
* robarnold - {{nbug|554982}} final+

LandingQueue

2010-08-18T01:52:37Z

Crowder: /* Landing Queue for Mozilla-Central */

= Landing Queue for Mozilla-Central =

Please add your name to the bottom of the list, the bugs you want to land and what the blocking status of them is. After you push, remove yourself from the top of the list. All pushes should be made after consulting with the tree sheriff. 

* roc - {{nbug|537890}} approved, {{nbug|497808}} blocking
* dougt - {{nbug|588201}} approved
* Bas - blocking-beta5+
* Josh, {{bug|578868}} blocking-beta5+
* bholley {{bug|512260}} blocking-beta5+
* birtles {{nbug|485157}} approved, {{nbug|544855}} blocking-betaN+
* crowder - {{nbug|562444}} blocking-fennec2.0a1+

== Ride-along patches ==

Add yourself here if you would prefer that some kind soul check your patch in on your behalf.

* Taras - {{nbug|559961}} beta5+

Necko: Electrolysis design and subprojects

2010-05-05T20:50:21Z

Crowder: /* Download Manager */

This is a page dedicated to the design issues involved in making necko work under electrolysis (i.e. moving all network traffic to the chrome process, and using IPDL to communicate with the content process(es)).

= Protocols that need work for e10s =

In the long term, we do not want to allow any network connections from child processes for security reasons (we may enforce this via operating system mechanisms). In the short term, we are more concerned with memory footprint and correctness. HTTP requires both caching and NSS, which are both memory-heavy, and it also uses cookies and auth, which require a single central database. So HTTP will need to be centralized in chrome immediately. FTP (and gopher, if it's still supported) will initially continue to run unmodified in child processes as an interim step. Eventually they too will need to do network traffic solely in chrome. Web sockets will also need to be modified to run only in chrome.

Eventually we may sandbox all file access, and thus other protocols (about://, file://, jar://) will need some work. But this is for "Stage 2".

= High-level implementation description =

Most of necko's logic is going to happen in the chrome process.

* Content process will open Channels, but these channels will essentially be stubs (HttpChannelChild) that are connected to a real Channel in the chrome process via IPDL.

* When an HTTP request is made, for instance, all the nitty-gritty of socket creation, authentication, SSL, cookies, and caching will be made in the chrome process

* The content process will then be notified with the usual OnStartRequest, OnDataAvailable, and OnStopRequest notifications.

So, the most obvious place for inter-process communication will be AsyncOpen (from content->chrome, to queue the network request) and the various "On..." events back from chrome to the content process. There will also be IPDL traffic for notifications, cancellations, and probably other things. For HTTP, this traffic is handled by the netwerk/protocol/http/src/HttpChannel{Parent|Child} classes.

= Design/architecture issues =

=== Types of network requests under electrolysis ===

The most common case of necko usage under electrolysis will be network requests that originate in a child (tab) process, and are serviced by the parent. But it is important to realize that there are actually three logically different types of network request:

# Traditional, non-e10s single process mode.
#* e10s will be disabled for firefox on certain platforms, and may not be used at all in Thunderbird or other necko applications. In such cases MOZ_IPC will not be #defined, and necko should work exactly as it used to.
#** So any code dealing with IPC must be guarded by #if MOZ_IPC.
# Requests from within the parent.
#* While most necko requests will be initiated from child (tab) processes, there will still be some (update checks, safebrowsing) that originate within the parent.
#** Note that some IPC may still be performed for these requests (an observer of the request may still live in a child process).
#** Otherwise, these requests should work essentially the same as in "traditional" mode.
# Request from a child process
#* The basic design for requests from child processes is that they should "wrap" a regular request on the parent, using IPDL. In other words, we hope to keep the existing nsHttpChannel, nsHttpHandler, etc. code as unmodified as possible; this code should not need to know whether it is servicing a child or a parent request. The logic for supporting a child request should be handled within the IPDL protocol classes instead whenever possible (for instance, HttpChannelParent).
#** Some of the existing necko architecture will exist in both the parent/child, and will need to know at some times where they are running; for instance, nsHttpHandler needs to know whether to hand out an nsHttpChannel (if it's in the parent) or an HttpChannelChild (if it's in the child). For this there is a IsNeckoChild() function, which returns true if called within the child process. For certain optimizations (ex: consolidating OnDataAvail and OnStatus/OnProgress into one IPDL message) it is also useful for the chrome nsHttpChannel to know if it is servicing a remote child request: this is true if "mRemoteChannel" is set.

=== Sync and async IPC messages ===

IPDL traffic between the parent/child channels should generally be asynchronous. This is both for performance reasons, and to avoid tricky issues that can come up with sync messaging. In particular, the child must avoid doing sync requests to the parent to get channel state information, as the parent channel may have diverged in state. (See http://tinyurl.com/yaa9p7s for some discussion of this). The child channel must instead cache all the state info that is needed to answer any queries from necko client code.

=== Validating data ===
Lucas suggested that IPDL parent actors should take measures to validate data passed to them by children, in case the latter have been compromised (ex: validating that strings are actually UTF-16). In necko's case, that should mainly be the URI and other data for the initial request, but keep in mind for other IPC exchanges, too.

= Building, running, and testing necko e10s =

=== Building ===

The code lives in the main e10s repo, so follow the regular e10s instructions at
[[Content_Processes#Building_.26_debugging]] to build.

=== Running ===

The necko e10s code is currently turned off by default (instead each child process gets its own full necko stack). To turn it on, set NECKO_E10S_HTTP=1 in your environment.

Depending on what you're trying to do, you'll either be running [https://developer.mozilla.org/en/Writing_xpcshell-based_unit_tests xpcshell] tests or the [https://wiki.mozilla.org/Content_Processes/Build remote tab demo] (a.k.a. test-ipc.xul). Running xpcshell tests is quite lightweight (text-based, and fewer XPCOM things to load, so fast to run on a remote machine over ssh, etc.), while test-ipc.xul fires up a version of the whole browser. Develop with xpcshell when you can (unfortunately some important features--like load groups, notifications, etc.--are not tested by xpcshell, so you currently need to run test-ipc.xul).

=== Testing and Logging ===

Testing is currently mainly done in the form of [https://developer.mozilla.org/en/Writing_xpcshell-based_unit_tests xpcshell] tests (see netwerk/test/unit_ipc; You'll need the patches for [https://bugzilla.mozilla.org/show_bug.cgi?id=521922 bug 521922] and (if you want to run the full set of existing necko tests) [https://bugzilla.mozilla.org/show_bug.cgi?id=526335 bug 526335]. The xpcshell framework is set up to run first on chrome (the tests in 'netwerk/test/unit') and then the child ('netwerk/test/unit_ipc'), since we need both codepaths to work). If you are not interested in the chrome tests (which should all pass, unless you've f*cked something up with chrome-side necko), you can turn them off in /netwerk/test/Makefile.in by setting XPCSHELL_TESTS= unit_ipc (i.e. changing the "+=" to "="), after which "make xpcshell-tests" will run only the child-side tests.

NOTE: the xpcshell tests currently by default do NOT run the e10s version of necko; instead they run the "each process gets the full necko stack" version. This is both because we are still making sure that the xpcshell tests all work correctly on the child-side with necko unmodified ([https://bugzilla.mozilla.org/show_bug.cgi?id=526335 bug 526335]) before we try to test them against the experimental code, and because it is quite certain that many of the existing tests will fail if we try to run them against our buggy, incomplete e10s necko code. You will want to turn on the e10s code if you're trying to test it. You may also want [http://www.mozilla.org/projects/netlib/http/http-debugging.html HTTP logging] to work :), which is currently broken. To turn on e10s HTTP for xpcshell and fix HTTP logging, apply my workaround patch for [https://bugzilla.mozilla.org/show_bug.cgi?id=534764 bug 534764]. I do not yet have a fix for HTTP logging for test-ipc.xul.

= Bugzilla tracking =

The necko e10s work is currently divided into two broad stages: features that are needed for the next release of fennec (https://bugzilla.mozilla.org/show_bug.cgi?id=516730), and later work which will be needed for e10s firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=535725). All necko e10s work should be grouped under one of these two tracking bugs.

= Old notes =

The remainder of this page is notes from the original revision of this page. They are now superceded by the various bugs that have been created for them, but I'm keeping them around for reference. Please update the bugs, not these notes (unless you feel like doing both :)

==== HTTP Headers ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536279 and https://bugzilla.mozilla.org/show_bug.cgi?id=536283

HTTP headers will need to be parsed first in the chrome process--so things like auth, cache directives, cookies, etc., can be handled. We will also need to provide some or all headers to the content process, via IPDL.
* bz suggests we "whitelist" the headers and provide only needed headers to the content process.

==== HTTP redirects ====

https://bugzilla.mozilla.org/show_bug.cgi?id=513086 and https://bugzilla.mozilla.org/show_bug.cgi?id=536294

The current architecture shifts out the original channel and replaces it with a channel to the new destination.

*This will probably require IPDL traffic to tell the content process to do something similar on its end.
*There are also listeners that are notified of redirects, and have the ability to cancel if they don't approve (plugins such as flash use this).
**There will be listeners that need to notified in both chrome and content processes, so use IPC.
**But right now these notifications are synchronous: we should change this to async on mozilla-central, and then merge into e10s tree, before trying to implement with IPC.
***Opened as [https://bugzilla.mozilla.org/show_bug.cgi?id=513086 bug 513086]
*Security concerns
**Is it possible an observer to rewrite/redirect a navigation rather than just canceling it? If so how would that change be propagated?
**Is the navigation blocked until all observers return? Otherwise we might run the risk of a race condition.

==== HTTPS ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536301

e10s will hopefully only need minor mods for HTTPS.
* One issue: to determine if Lock Icon needed, content process will need handle to securityInfo, which is currently pointed to by nsHttpChannel. Shouldn't need to actually read security info--see what exactly is needed.

==== Download Manager ====

The download manager should live in the chrome process. The chrome process is responsible for displaying "Where do you want to save this file?" and should be responsible for the network transfer and disk access.

Issues arise in this architecture (as I understand it) because currently necko actually primarily resides in content processes.

In the ideal world, necko would live in the chrome process entirely and would proxy requests for content processes. Content processes would "subscribe" to the kinds of content they're able to handle for a given request, and if no handler is subscribed, the download manager should be invoked.

How should this work in the existing incarnation of necko/e10s?

==== LoadGroups ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536292

LoadGroups will live in the content process.
* They need to be able to cancel Channels, which should be fairly trivial IPC.
* When Channels are added to a LoadGroup notifications must be sent, both to DocShell (in content) and various listeners in chrome. Right now these notifications are SYNC, but we might want to change them to asynchronous to make them play better in the e10s model. But for now bz/bsmedberg suggest we wait.
* We will need to keep track (via LoadGroups or otherwise) of which channels are "owned" by which content processes, so if one dies, we know to cancel its requests.

==== Application cache ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536295

The application cache is fairly recent & is used for offline mode for web apps like gmail. Unlike the regular HTTP cache, which will be invisible effectively to the content process, the app cache will be visible to the content process, which needs among other things to parse HTTP headers to see if data needs to be cached.
* Presumably cache lives in chrome, and content processes read from it? Not sure.
* This isn't getting lots of use yet, so it doesn't need to work immediately.
* Honza Bambas and/or Doug Camp (ex-Mozilla) are the ones to ask about this code.

==== EventSink listeners ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536292

(Firebug, for instance). We'll need to propagate these events to both chrome/content processes, as listeners will live on both.
* ideally we send one IPC msg per event, not one per remote listener.
* don't need much data (HTTP/Channel status?); might need to send the data along in the IPC msg.
* These calls are already async, so no API change should be needed.

==== Suspending channels ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536321

We suspend Channels from the Download manager, and also when plugins don't consume arriving Channel data quickly enough. Also HTTP auth?
* We will need to keep around whatever data has arrived but hasn't been delivered, so resume works correctly. Could happen on either chrome/content end.

==== Http Auth dialog ====

https://bugzilla.mozilla.org/show_bug.cgi?id=537782

How will chrome know which window to pop Auth tab up in when HTTP auth is needed? Right now the Channel has callbacks which can be used to get originating window. We'll need to make this work with e10s, possibly by including window info in chrome Channel when we create it during AsyncOpen.

==== File form POSTs ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536273

bz suggests that we can accomplish this without having the content process read the file by creating a new kind of stream class, in which the content process marks the name of the file and the chrome process actually reads it from disk and uploads it.

==== Channel "owner" ====
Channels have Set/GetOwner methods, used to store the principal responsible for the request.
* Apparently not used much for HTTP?
** jst: CSP (Content Security Protocol) may use?
* Not clear if get & set only on content side, or if set only on content, but read by both chrome/content. Find out and propagate as needed
* bz would like to rework this API anyway

== FTP ==

https://bugzilla.mozilla.org/show_bug.cgi?id=536289

* Doug Turner knows this code.
* Proposal from bsmedberg: we keep FTP purely within the chrome process, so that we don't need to make it IPC-savvy.
** We would only allow files to be downloaded (not rendered within browser) via FTP.
** browsing of FTP server tree would be done by hiding content process tab with a chrome one when a FTP directory is the target.
** FTP also supports upload--used by seamonkey and composer--but this happens all in chrome, so no changes needed?

= Security Issues =

For a general Electrolysis threat model see [[Security/ProcessIsolation/ThreatModel]]

=== Race conditions ===

* Could one frame navigate another frame without permission
* Could one window script into another window without permission
* Redirects - could a redirect happen in chrome while content is performing a security check

=== Domain isolation ===

* Do we try to restrict cookies to per process / per window
* Can we actually authenticate a network request from a given content process
* How do we handle access to file:// and related schemes... trusting content process might be too much (see below)
* If we do try to isolate, how do we verify the validity of a request (do we need to have a stateful proxy to determine which content is valid to access cross-domain and which isn't)
* Can we do anything to protect cookies? Password manager? Cache? Local storage?

=== Do we want to check principals in the chrome process? ===

(heard on IRC...)

bz: long term we want to move CheckLoadURI checks into the chrome process and
not trust any self-reported principals of content processes right?

bsmedberg: hrm, I'm not sure that's ever going to be feasible. it's certainly
not part of releasing anything, or even releasing anything with a sandbox

bz: it seems like it lets you trivially escape the sandbox.... if not done

bsmedberg: depends on what the sandbox is for, though. If it's only to
prevent viral infections and such, I think you're fine. And protecting
against XSS/cookiedata leaks is much harder due to interior iframes,
document.cookie scripting, loading arbitrary JS/images

bz is not sure why it's fine: As long as you can ask the chrome process to do
network requests for you and it trusts your self-reported principal you can
read arbitrary files and phone home. Not a viral infection, but much worse
than just XSS

Necko: Electrolysis design and subprojects

2010-05-05T20:46:56Z

Crowder: /* LoadGroups */

This is a page dedicated to the design issues involved in making necko work under electrolysis (i.e. moving all network traffic to the chrome process, and using IPDL to communicate with the content process(es)).

= Protocols that need work for e10s =

In the long term, we do not want to allow any network connections from child processes for security reasons (we may enforce this via operating system mechanisms). In the short term, we are more concerned with memory footprint and correctness. HTTP requires both caching and NSS, which are both memory-heavy, and it also uses cookies and auth, which require a single central database. So HTTP will need to be centralized in chrome immediately. FTP (and gopher, if it's still supported) will initially continue to run unmodified in child processes as an interim step. Eventually they too will need to do network traffic solely in chrome. Web sockets will also need to be modified to run only in chrome.

Eventually we may sandbox all file access, and thus other protocols (about://, file://, jar://) will need some work. But this is for "Stage 2".

= High-level implementation description =

Most of necko's logic is going to happen in the chrome process.

* Content process will open Channels, but these channels will essentially be stubs (HttpChannelChild) that are connected to a real Channel in the chrome process via IPDL.

* When an HTTP request is made, for instance, all the nitty-gritty of socket creation, authentication, SSL, cookies, and caching will be made in the chrome process

* The content process will then be notified with the usual OnStartRequest, OnDataAvailable, and OnStopRequest notifications.

So, the most obvious place for inter-process communication will be AsyncOpen (from content->chrome, to queue the network request) and the various "On..." events back from chrome to the content process. There will also be IPDL traffic for notifications, cancellations, and probably other things. For HTTP, this traffic is handled by the netwerk/protocol/http/src/HttpChannel{Parent|Child} classes.

= Design/architecture issues =

=== Types of network requests under electrolysis ===

The most common case of necko usage under electrolysis will be network requests that originate in a child (tab) process, and are serviced by the parent. But it is important to realize that there are actually three logically different types of network request:

# Traditional, non-e10s single process mode.
#* e10s will be disabled for firefox on certain platforms, and may not be used at all in Thunderbird or other necko applications. In such cases MOZ_IPC will not be #defined, and necko should work exactly as it used to.
#** So any code dealing with IPC must be guarded by #if MOZ_IPC.
# Requests from within the parent.
#* While most necko requests will be initiated from child (tab) processes, there will still be some (update checks, safebrowsing) that originate within the parent.
#** Note that some IPC may still be performed for these requests (an observer of the request may still live in a child process).
#** Otherwise, these requests should work essentially the same as in "traditional" mode.
# Request from a child process
#* The basic design for requests from child processes is that they should "wrap" a regular request on the parent, using IPDL. In other words, we hope to keep the existing nsHttpChannel, nsHttpHandler, etc. code as unmodified as possible; this code should not need to know whether it is servicing a child or a parent request. The logic for supporting a child request should be handled within the IPDL protocol classes instead whenever possible (for instance, HttpChannelParent).
#** Some of the existing necko architecture will exist in both the parent/child, and will need to know at some times where they are running; for instance, nsHttpHandler needs to know whether to hand out an nsHttpChannel (if it's in the parent) or an HttpChannelChild (if it's in the child). For this there is a IsNeckoChild() function, which returns true if called within the child process. For certain optimizations (ex: consolidating OnDataAvail and OnStatus/OnProgress into one IPDL message) it is also useful for the chrome nsHttpChannel to know if it is servicing a remote child request: this is true if "mRemoteChannel" is set.

=== Sync and async IPC messages ===

IPDL traffic between the parent/child channels should generally be asynchronous. This is both for performance reasons, and to avoid tricky issues that can come up with sync messaging. In particular, the child must avoid doing sync requests to the parent to get channel state information, as the parent channel may have diverged in state. (See http://tinyurl.com/yaa9p7s for some discussion of this). The child channel must instead cache all the state info that is needed to answer any queries from necko client code.

=== Validating data ===
Lucas suggested that IPDL parent actors should take measures to validate data passed to them by children, in case the latter have been compromised (ex: validating that strings are actually UTF-16). In necko's case, that should mainly be the URI and other data for the initial request, but keep in mind for other IPC exchanges, too.

= Building, running, and testing necko e10s =

=== Building ===

The code lives in the main e10s repo, so follow the regular e10s instructions at
[[Content_Processes#Building_.26_debugging]] to build.

=== Running ===

The necko e10s code is currently turned off by default (instead each child process gets its own full necko stack). To turn it on, set NECKO_E10S_HTTP=1 in your environment.

Depending on what you're trying to do, you'll either be running [https://developer.mozilla.org/en/Writing_xpcshell-based_unit_tests xpcshell] tests or the [https://wiki.mozilla.org/Content_Processes/Build remote tab demo] (a.k.a. test-ipc.xul). Running xpcshell tests is quite lightweight (text-based, and fewer XPCOM things to load, so fast to run on a remote machine over ssh, etc.), while test-ipc.xul fires up a version of the whole browser. Develop with xpcshell when you can (unfortunately some important features--like load groups, notifications, etc.--are not tested by xpcshell, so you currently need to run test-ipc.xul).

=== Testing and Logging ===

Testing is currently mainly done in the form of [https://developer.mozilla.org/en/Writing_xpcshell-based_unit_tests xpcshell] tests (see netwerk/test/unit_ipc; You'll need the patches for [https://bugzilla.mozilla.org/show_bug.cgi?id=521922 bug 521922] and (if you want to run the full set of existing necko tests) [https://bugzilla.mozilla.org/show_bug.cgi?id=526335 bug 526335]. The xpcshell framework is set up to run first on chrome (the tests in 'netwerk/test/unit') and then the child ('netwerk/test/unit_ipc'), since we need both codepaths to work). If you are not interested in the chrome tests (which should all pass, unless you've f*cked something up with chrome-side necko), you can turn them off in /netwerk/test/Makefile.in by setting XPCSHELL_TESTS= unit_ipc (i.e. changing the "+=" to "="), after which "make xpcshell-tests" will run only the child-side tests.

NOTE: the xpcshell tests currently by default do NOT run the e10s version of necko; instead they run the "each process gets the full necko stack" version. This is both because we are still making sure that the xpcshell tests all work correctly on the child-side with necko unmodified ([https://bugzilla.mozilla.org/show_bug.cgi?id=526335 bug 526335]) before we try to test them against the experimental code, and because it is quite certain that many of the existing tests will fail if we try to run them against our buggy, incomplete e10s necko code. You will want to turn on the e10s code if you're trying to test it. You may also want [http://www.mozilla.org/projects/netlib/http/http-debugging.html HTTP logging] to work :), which is currently broken. To turn on e10s HTTP for xpcshell and fix HTTP logging, apply my workaround patch for [https://bugzilla.mozilla.org/show_bug.cgi?id=534764 bug 534764]. I do not yet have a fix for HTTP logging for test-ipc.xul.

= Bugzilla tracking =

The necko e10s work is currently divided into two broad stages: features that are needed for the next release of fennec (https://bugzilla.mozilla.org/show_bug.cgi?id=516730), and later work which will be needed for e10s firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=535725). All necko e10s work should be grouped under one of these two tracking bugs.

= Old notes =

The remainder of this page is notes from the original revision of this page. They are now superceded by the various bugs that have been created for them, but I'm keeping them around for reference. Please update the bugs, not these notes (unless you feel like doing both :)

==== HTTP Headers ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536279 and https://bugzilla.mozilla.org/show_bug.cgi?id=536283

HTTP headers will need to be parsed first in the chrome process--so things like auth, cache directives, cookies, etc., can be handled. We will also need to provide some or all headers to the content process, via IPDL.
* bz suggests we "whitelist" the headers and provide only needed headers to the content process.

==== HTTP redirects ====

https://bugzilla.mozilla.org/show_bug.cgi?id=513086 and https://bugzilla.mozilla.org/show_bug.cgi?id=536294

The current architecture shifts out the original channel and replaces it with a channel to the new destination.

*This will probably require IPDL traffic to tell the content process to do something similar on its end.
*There are also listeners that are notified of redirects, and have the ability to cancel if they don't approve (plugins such as flash use this).
**There will be listeners that need to notified in both chrome and content processes, so use IPC.
**But right now these notifications are synchronous: we should change this to async on mozilla-central, and then merge into e10s tree, before trying to implement with IPC.
***Opened as [https://bugzilla.mozilla.org/show_bug.cgi?id=513086 bug 513086]
*Security concerns
**Is it possible an observer to rewrite/redirect a navigation rather than just canceling it? If so how would that change be propagated?
**Is the navigation blocked until all observers return? Otherwise we might run the risk of a race condition.

==== HTTPS ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536301

e10s will hopefully only need minor mods for HTTPS.
* One issue: to determine if Lock Icon needed, content process will need handle to securityInfo, which is currently pointed to by nsHttpChannel. Shouldn't need to actually read security info--see what exactly is needed.

==== Download Manager ====

==== LoadGroups ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536292

LoadGroups will live in the content process.
* They need to be able to cancel Channels, which should be fairly trivial IPC.
* When Channels are added to a LoadGroup notifications must be sent, both to DocShell (in content) and various listeners in chrome. Right now these notifications are SYNC, but we might want to change them to asynchronous to make them play better in the e10s model. But for now bz/bsmedberg suggest we wait.
* We will need to keep track (via LoadGroups or otherwise) of which channels are "owned" by which content processes, so if one dies, we know to cancel its requests.

==== Application cache ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536295

The application cache is fairly recent & is used for offline mode for web apps like gmail. Unlike the regular HTTP cache, which will be invisible effectively to the content process, the app cache will be visible to the content process, which needs among other things to parse HTTP headers to see if data needs to be cached.
* Presumably cache lives in chrome, and content processes read from it? Not sure.
* This isn't getting lots of use yet, so it doesn't need to work immediately.
* Honza Bambas and/or Doug Camp (ex-Mozilla) are the ones to ask about this code.

==== EventSink listeners ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536292

(Firebug, for instance). We'll need to propagate these events to both chrome/content processes, as listeners will live on both.
* ideally we send one IPC msg per event, not one per remote listener.
* don't need much data (HTTP/Channel status?); might need to send the data along in the IPC msg.
* These calls are already async, so no API change should be needed.

==== Suspending channels ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536321

We suspend Channels from the Download manager, and also when plugins don't consume arriving Channel data quickly enough. Also HTTP auth?
* We will need to keep around whatever data has arrived but hasn't been delivered, so resume works correctly. Could happen on either chrome/content end.

==== Http Auth dialog ====

https://bugzilla.mozilla.org/show_bug.cgi?id=537782

How will chrome know which window to pop Auth tab up in when HTTP auth is needed? Right now the Channel has callbacks which can be used to get originating window. We'll need to make this work with e10s, possibly by including window info in chrome Channel when we create it during AsyncOpen.

==== File form POSTs ====

https://bugzilla.mozilla.org/show_bug.cgi?id=536273

bz suggests that we can accomplish this without having the content process read the file by creating a new kind of stream class, in which the content process marks the name of the file and the chrome process actually reads it from disk and uploads it.

==== Channel "owner" ====
Channels have Set/GetOwner methods, used to store the principal responsible for the request.
* Apparently not used much for HTTP?
** jst: CSP (Content Security Protocol) may use?
* Not clear if get & set only on content side, or if set only on content, but read by both chrome/content. Find out and propagate as needed
* bz would like to rework this API anyway

== FTP ==

https://bugzilla.mozilla.org/show_bug.cgi?id=536289

* Doug Turner knows this code.
* Proposal from bsmedberg: we keep FTP purely within the chrome process, so that we don't need to make it IPC-savvy.
** We would only allow files to be downloaded (not rendered within browser) via FTP.
** browsing of FTP server tree would be done by hiding content process tab with a chrome one when a FTP directory is the target.
** FTP also supports upload--used by seamonkey and composer--but this happens all in chrome, so no changes needed?

= Security Issues =

For a general Electrolysis threat model see [[Security/ProcessIsolation/ThreatModel]]

=== Race conditions ===

* Could one frame navigate another frame without permission
* Could one window script into another window without permission
* Redirects - could a redirect happen in chrome while content is performing a security check

=== Domain isolation ===

* Do we try to restrict cookies to per process / per window
* Can we actually authenticate a network request from a given content process
* How do we handle access to file:// and related schemes... trusting content process might be too much (see below)
* If we do try to isolate, how do we verify the validity of a request (do we need to have a stateful proxy to determine which content is valid to access cross-domain and which isn't)
* Can we do anything to protect cookies? Password manager? Cache? Local storage?

=== Do we want to check principals in the chrome process? ===

(heard on IRC...)

bz: long term we want to move CheckLoadURI checks into the chrome process and
not trust any self-reported principals of content processes right?

bsmedberg: hrm, I'm not sure that's ever going to be feasible. it's certainly
not part of releasing anything, or even releasing anything with a sandbox

bz: it seems like it lets you trivially escape the sandbox.... if not done

bsmedberg: depends on what the sandbox is for, though. If it's only to
prevent viral infections and such, I think you're fine. And protecting
against XSS/cookiedata leaks is much harder due to interior iframes,
document.cookie scripting, loading arbitrary JS/images

bz is not sure why it's fine: As long as you can ask the chrome process to do
network requests for you and it trusts your self-reported principal you can
read arbitrary files and phone home. Not a viral infection, but much worse
than just XSS

Mobile/Fennec Unittests/green

2010-04-22T19:41:23Z

Crowder: marking spellcheck bug wfm

== overview ==

This is a list of tests which I found to fail on both the n900 and n810 over repeated runs. I believe making these tests pass (either by fixing the tests or ignoring the tests and writing new ones if necessary) will get us to a good position where we can start seeing green.

Until reftest/crashtest/xpcshell are green we will continue to ignore the mochitest stuff.

== reftest ==

Here are some guides for running the tests:
* [[https://wiki.mozilla.org/Mobile/Fennec_Reftests maemo]]
* [[https://wiki.mozilla.org/Mobile/WinMo_Reftest winmo]]

{| class="wikitable" style="width: 100%" class="fullwidth-table sortable"
|+
| test || status || bug
|-
| tests/modules/libpr0n/test/reftest/colordepth.html || ||
|-
| tests/modules/libpr0n/test/reftest/pngsuite-ancillary/ccwn2c08.png || || <strike>{{bug|471917}}</strike>
|-
| tests/modules/libpr0n/test/reftest/pngsuite-ancillary/ccwn3p08.png || || <strike>{{bug|471917}}</strike>
|-
| tests/layout/reftests/bugs/134706-3-left-scrollframe.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/134706-3-right-scrollframe.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/240536-resizer-ltr.xul || This is a nativetheme issue. It depends on the resize handle being rendered. ||
|-
| tests/layout/reftests/bugs/300691-1a.html || spellcheck squiggle || <strike>{{bug|556076}}</strike>
|-
| tests/layout/reftests/bugs/300691-1b.html || spellcheck squiggle || <strike>{{bug|556076}}</strike>
|-
| tests/layout/reftests/bugs/300691-1c.html || spellcheck squiggle || <strike>{{bug|556076}}</strike>
|-
| tests/layout/reftests/bugs/300691-1d.html || spellcheck squiggle || <strike>{{bug|556076}}</strike>
|-
| tests/layout/reftests/bugs/300691-1e.html || spellcheck squiggle || <strike>{{bug|556076}}</strike>
|-
| tests/layout/reftests/bugs/300691-1f.html || spellcheck squiggle || <strike>{{bug|556076}}</strike>
|-
| tests/layout/reftests/bugs/301726-2.html || round2 ||
|-
| tests/layout/reftests/bugs/338251-p-oh.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/362901-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/367247-s-auto.html || round2 ||
|-
| tests/layout/reftests/bugs/367247-l-hidden.html || round2 ||
|-
| tests/layout/reftests/bugs/371561-1.html || round2 ||
|-
| tests/layout/reftests/bugs/376532-2.html || round2 ||
|-
| tests/layout/reftests/bugs/376532-3.html || round2 ||
|-
| tests/layout/reftests/bugs/379461-3-container-xhtml.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/379461-3-container-xhtml.html (!=)|| round2 ||
|-
| tests/layout/reftests/bugs/385569-1a.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/385569-1b.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/386470-1b.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/423823-1.html || ||
|-
| tests/layout/reftests/bugs/424074-1-ref2.xul || ||
|-
| tests/layout/reftests/bugs/440112.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/466395-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/466395-2.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/467084-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/474417-1.html || round2 ||
|-
| <strike>tests/layout/reftests/bugs/491180-1.html</strike> || || <strike>{{bug|548826}}</strike>
|-
| <strike>tests/layout/reftests/bugs/491180-2.html</strike> || || <strike>{{bug|548826}}</strike>
|-
| tests/layout/reftests/bugs/495385-2h.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/513318-2.xul || round2 ||
|-
| tests/layout/reftests/bugs/513318-3.xul || round2 ||
|-
| tests/layout/reftests/canvas/text-bidi-ltr-test.html || round2 ||
|-
| tests/layout/reftests/canvas/text-bidi-rtl-test.html || round2 ||
|-
| tests/layout/reftests/generated-content/table-parts-01.html || round2 ||
|-
| <strike>tests/layout/reftests/font-face/src-list-local-full.html </strike>|| || <strike>{{bug|548865}}</strike>
|-
| <strike>tests/layout/reftests/font-face/src-list-local-full-quotes.html</strike> || || <strike>{{bug|548865}}</strike>
|-
| <strike>tests/layout/reftests/font-face/local-1.html</strike> || || <strike>{{bug|548865}}</strike>
|-
| tests/layout/reftests/margin-collapsing/block-overflow-2.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/margin-collapsing/block-overflow-2.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/text-input-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/textarea-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/button-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/combobox-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/listbox-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/radio-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/checkbox-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/box-shadow-styling.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| tests/layout/reftests/svg/sizing/inline--display-inline--01.xhtml || left edge of box is broken || {{bug|548648}}
|-
| tests/layout/reftests/svg/sizing/inline--display-inline-block--01.xhtml || left edge of box is broken || {{bug|548648}}
|-
| tests/layout/reftests/svg/sizing/inline--position-relative--01.xhtml || left edge of box is broken || {{bug|548648}}
|-
| tests/layout/reftests/svg/sizing/dynamic--inline-resize-cb-height.xhtml || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/svg/sizing/dynamic--inline-resize-cb-width.xhtml || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/svg/sizing/dynamic--inline-resize-window-width.xhtml || marked as fails in m-c ||
|-
| tests/layout/reftests/svg/opacity-and-gradient-01.svg || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/text/wordwrap-01.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/transform/iframe-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/content/test/reftest/xml-stylesheet/lreas_selflink_dtd_id.svg || marked as fails in m-c ||
|-
| tests/layout/xul/base/src/grid/reftests/scrollable-columns.xul || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|}

== crashtest ==

Here are some guides for running the tests:
* [[https://wiki.mozilla.org/Mobile/Fennec_Reftests maemo]]
* [[https://wiki.mozilla.org/Mobile/WinMo_Reftest winmo]]

{| class="wikitable" style="width: 100%" class="fullwidth-table sortable"
|+
| Test || Status || Bugs
|-
| tests/layout/base/crashtests/311611-1.html || FAIL ||
|-
| tests/layout/base/crashtests/500467-1.html || HANG ||
|}

== xpcshell ==

Here are some guides for running the tests:
* [[https://wiki.mozilla.org/Mobile/Fennec_Xpcshell maemo]]
* [[https://wiki.mozilla.org/Mobile/WinMo_Xpcshell winmo]]

{| class="wikitable" style="width: 100%" class="fullwidth-table sortable"
|+
| Test || Status || Bugs
|-
| tests/jsctypes-test/unit/test_jsctypes.js || ||
|-
| tests/test_uriloader_exthandler/unit/test_handlerService.js || ||
|-
| tests/test_docshell/unit/test_bug414201_jfif.js || ||
|-
| tests/test_places/autocomplete/test_download_embed_bookmarks.js || ||
|-
| tests/test_places/autocomplete/test_livemarks.js || ||
|-
| tests/test_places/sync/test_expire_on_timed_flush.js || ||
|-
| tests/test_places/sync/test_expire_on_timed_flush_not_whole_entry.js || ||
|-
| tests/test_places/unit/test_000_frecency.js || ||
|-
| tests/test_places/unit/test_408221.js || ||
|-
| tests/test_places/unit/test_empty_tags.js || HANGS ||
|-
| tests/test_places/unit/test_frecency.js || ||
|-
| tests/test_places/unit/test_history_autocomplete_tags.js || ||
|-
| tests/test_places/unit/test_migrateFrecency.js || ||
|-
| tests/test_satchel/unit/test_autocomplete.js || ||
|-
| tests/test_satchel/unit/test_expire.js || ||
|-
| tests/test_extensionmanager/unit/test_bug299716.js || ||
|-
| tests/test_extensionmanager/unit/test_bug371495.js || ||
|-
| tests/test_extensionmanager/unit/test_bug396129.js || ||
|-
| tests/test_extensionmanager/unit/test_bug428341.js || ||
|-
| tests/test_extensionmanager/unit/test_bug463819.js || ||
|-
| tests/test_extensionmanager/unit/test_bug470377_1.js || ||
|-
| tests/test_extensionmanager/unit/test_bug470377_2.js || ||
|-
| tests/test_necko/unit/test_file_protocol.js || ||
|-
| tests/test_necko/unit/test_localstreams.js || ||
|}

Mobile/Fennec Unittests/green

2010-04-01T16:27:13Z

Crowder: /* marking 471917 fixed */

== overview ==

This is a list of tests which I found to fail on both the n900 and n810 over repeated runs. I believe making these tests pass (either by fixing the tests or ignoring the tests and writing new ones if necessary) will get us to a good position where we can start seeing green.

Until reftest/crashtest/xpcshell are green we will continue to ignore the mochitest stuff.

== reftest ==

Here are some guides for running the tests:
* [[https://wiki.mozilla.org/Mobile/Fennec_Reftests maemo]]
* [[https://wiki.mozilla.org/Mobile/WinMo_Reftest winmo]]

{| class="wikitable" style="width: 100%" class="fullwidth-table sortable"
|+
| test || status || bug
|-
| tests/modules/libpr0n/test/reftest/colordepth.html || ||
|-
| tests/modules/libpr0n/test/reftest/pngsuite-ancillary/ccwn2c08.png || || <strike>{{bug|471917}}</strike>
|-
| tests/modules/libpr0n/test/reftest/pngsuite-ancillary/ccwn3p08.png || || <strike>{{bug|471917}}</strike>
|-
| tests/layout/reftests/bugs/134706-3-left-scrollframe.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/134706-3-right-scrollframe.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/240536-resizer-ltr.xul || This is a nativetheme issue. It depends on the resize handle being rendered. ||
|-
| tests/layout/reftests/bugs/300691-1a.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/300691-1b.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/300691-1c.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/300691-1d.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/300691-1e.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/300691-1f.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/301726-2.html || round2 ||
|-
| tests/layout/reftests/bugs/338251-p-oh.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/362901-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/367247-s-auto.html || round2 ||
|-
| tests/layout/reftests/bugs/367247-l-hidden.html || round2 ||
|-
| tests/layout/reftests/bugs/371561-1.html || round2 ||
|-
| tests/layout/reftests/bugs/376532-2.html || round2 ||
|-
| tests/layout/reftests/bugs/376532-3.html || round2 ||
|-
| tests/layout/reftests/bugs/379461-3-container-xhtml.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/379461-3-container-xhtml.html (!=)|| round2 ||
|-
| tests/layout/reftests/bugs/385569-1a.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/385569-1b.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/386470-1b.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/423823-1.html || ||
|-
| tests/layout/reftests/bugs/424074-1-ref2.xul || ||
|-
| tests/layout/reftests/bugs/440112.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/466395-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/466395-2.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/467084-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/474417-1.html || round2 ||
|-
| <strike>tests/layout/reftests/bugs/491180-1.html</strike> || || <strike>{{bug|548826}}</strike>
|-
| <strike>tests/layout/reftests/bugs/491180-2.html</strike> || || <strike>{{bug|548826}}</strike>
|-
| tests/layout/reftests/bugs/495385-2h.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/513318-2.xul || round2 ||
|-
| tests/layout/reftests/bugs/513318-3.xul || round2 ||
|-
| tests/layout/reftests/canvas/text-bidi-ltr-test.html || round2 ||
|-
| tests/layout/reftests/canvas/text-bidi-rtl-test.html || round2 ||
|-
| tests/layout/reftests/generated-content/table-parts-01.html || round2 ||
|-
| <strike>tests/layout/reftests/font-face/src-list-local-full.html </strike>|| || <strike>{{bug|548865}}</strike>
|-
| <strike>tests/layout/reftests/font-face/src-list-local-full-quotes.html</strike> || || <strike>{{bug|548865}}</strike>
|-
| <strike>tests/layout/reftests/font-face/local-1.html</strike> || || <strike>{{bug|548865}}</strike>
|-
| tests/layout/reftests/margin-collapsing/block-overflow-2.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/margin-collapsing/block-overflow-2.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/text-input-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/textarea-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/button-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/combobox-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/listbox-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/radio-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/checkbox-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/box-shadow-styling.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| tests/layout/reftests/svg/sizing/inline--display-inline--01.xhtml || left edge of box is broken || {{bug|548648}}
|-
| tests/layout/reftests/svg/sizing/inline--display-inline-block--01.xhtml || left edge of box is broken || {{bug|548648}}
|-
| tests/layout/reftests/svg/sizing/inline--position-relative--01.xhtml || left edge of box is broken || {{bug|548648}}
|-
| tests/layout/reftests/svg/sizing/dynamic--inline-resize-cb-height.xhtml || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/svg/sizing/dynamic--inline-resize-cb-width.xhtml || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/svg/sizing/dynamic--inline-resize-window-width.xhtml || marked as fails in m-c ||
|-
| tests/layout/reftests/svg/opacity-and-gradient-01.svg || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/text/wordwrap-01.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/transform/iframe-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/content/test/reftest/xml-stylesheet/lreas_selflink_dtd_id.svg || marked as fails in m-c ||
|-
| tests/layout/xul/base/src/grid/reftests/scrollable-columns.xul || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|}

== crashtest ==

Here are some guides for running the tests:
* [[https://wiki.mozilla.org/Mobile/Fennec_Reftests maemo]]
* [[https://wiki.mozilla.org/Mobile/WinMo_Reftest winmo]]

{| class="wikitable" style="width: 100%" class="fullwidth-table sortable"
|+
| Test || Status || Bugs
|-
| tests/layout/base/crashtests/311611-1.html || FAIL ||
|-
| tests/layout/base/crashtests/500467-1.html || HANG ||
|}

== xpcshell ==

Here are some guides for running the tests:
* [[https://wiki.mozilla.org/Mobile/Fennec_Xpcshell maemo]]
* [[https://wiki.mozilla.org/Mobile/WinMo_Xpcshell winmo]]

{| class="wikitable" style="width: 100%" class="fullwidth-table sortable"
|+
| Test || Status || Bugs
|-
| tests/jsctypes-test/unit/test_jsctypes.js || ||
|-
| tests/test_uriloader_exthandler/unit/test_handlerService.js || ||
|-
| tests/test_docshell/unit/test_bug414201_jfif.js || ||
|-
| tests/test_places/autocomplete/test_download_embed_bookmarks.js || ||
|-
| tests/test_places/autocomplete/test_livemarks.js || ||
|-
| tests/test_places/sync/test_expire_on_timed_flush.js || ||
|-
| tests/test_places/sync/test_expire_on_timed_flush_not_whole_entry.js || ||
|-
| tests/test_places/unit/test_000_frecency.js || ||
|-
| tests/test_places/unit/test_408221.js || ||
|-
| tests/test_places/unit/test_empty_tags.js || HANGS ||
|-
| tests/test_places/unit/test_frecency.js || ||
|-
| tests/test_places/unit/test_history_autocomplete_tags.js || ||
|-
| tests/test_places/unit/test_migrateFrecency.js || ||
|-
| tests/test_satchel/unit/test_autocomplete.js || ||
|-
| tests/test_satchel/unit/test_expire.js || ||
|-
| tests/test_extensionmanager/unit/test_bug299716.js || ||
|-
| tests/test_extensionmanager/unit/test_bug371495.js || ||
|-
| tests/test_extensionmanager/unit/test_bug396129.js || ||
|-
| tests/test_extensionmanager/unit/test_bug428341.js || ||
|-
| tests/test_extensionmanager/unit/test_bug463819.js || ||
|-
| tests/test_extensionmanager/unit/test_bug470377_1.js || ||
|-
| tests/test_extensionmanager/unit/test_bug470377_2.js || ||
|-
| tests/test_necko/unit/test_file_protocol.js || ||
|-
| tests/test_necko/unit/test_localstreams.js || ||
|}

Mobile/Fennec Unittests/green

2010-04-01T16:25:12Z

Crowder: /* marking 556087 fixed */

== overview ==

This is a list of tests which I found to fail on both the n900 and n810 over repeated runs. I believe making these tests pass (either by fixing the tests or ignoring the tests and writing new ones if necessary) will get us to a good position where we can start seeing green.

Until reftest/crashtest/xpcshell are green we will continue to ignore the mochitest stuff.

== reftest ==

Here are some guides for running the tests:
* [[https://wiki.mozilla.org/Mobile/Fennec_Reftests maemo]]
* [[https://wiki.mozilla.org/Mobile/WinMo_Reftest winmo]]

{| class="wikitable" style="width: 100%" class="fullwidth-table sortable"
|+
| test || status || bug
|-
| tests/modules/libpr0n/test/reftest/colordepth.html || ||
|-
| tests/modules/libpr0n/test/reftest/pngsuite-ancillary/ccwn2c08.png || || {{bug|471917}}
|-
| tests/modules/libpr0n/test/reftest/pngsuite-ancillary/ccwn3p08.png || || {{bug|471917}}
|-
| tests/layout/reftests/bugs/134706-3-left-scrollframe.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/134706-3-right-scrollframe.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/240536-resizer-ltr.xul || This is a nativetheme issue. It depends on the resize handle being rendered. ||
|-
| tests/layout/reftests/bugs/300691-1a.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/300691-1b.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/300691-1c.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/300691-1d.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/300691-1e.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/300691-1f.html || spellcheck squiggle || {{bug|556076}}
|-
| tests/layout/reftests/bugs/301726-2.html || round2 ||
|-
| tests/layout/reftests/bugs/338251-p-oh.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/362901-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/367247-s-auto.html || round2 ||
|-
| tests/layout/reftests/bugs/367247-l-hidden.html || round2 ||
|-
| tests/layout/reftests/bugs/371561-1.html || round2 ||
|-
| tests/layout/reftests/bugs/376532-2.html || round2 ||
|-
| tests/layout/reftests/bugs/376532-3.html || round2 ||
|-
| tests/layout/reftests/bugs/379461-3-container-xhtml.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/379461-3-container-xhtml.html (!=)|| round2 ||
|-
| tests/layout/reftests/bugs/385569-1a.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/385569-1b.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/386470-1b.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/423823-1.html || ||
|-
| tests/layout/reftests/bugs/424074-1-ref2.xul || ||
|-
| tests/layout/reftests/bugs/440112.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/466395-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/466395-2.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/467084-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/474417-1.html || round2 ||
|-
| <strike>tests/layout/reftests/bugs/491180-1.html</strike> || || <strike>{{bug|548826}}</strike>
|-
| <strike>tests/layout/reftests/bugs/491180-2.html</strike> || || <strike>{{bug|548826}}</strike>
|-
| tests/layout/reftests/bugs/495385-2h.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/bugs/513318-2.xul || round2 ||
|-
| tests/layout/reftests/bugs/513318-3.xul || round2 ||
|-
| tests/layout/reftests/canvas/text-bidi-ltr-test.html || round2 ||
|-
| tests/layout/reftests/canvas/text-bidi-rtl-test.html || round2 ||
|-
| tests/layout/reftests/generated-content/table-parts-01.html || round2 ||
|-
| <strike>tests/layout/reftests/font-face/src-list-local-full.html </strike>|| || <strike>{{bug|548865}}</strike>
|-
| <strike>tests/layout/reftests/font-face/src-list-local-full-quotes.html</strike> || || <strike>{{bug|548865}}</strike>
|-
| <strike>tests/layout/reftests/font-face/local-1.html</strike> || || <strike>{{bug|548865}}</strike>
|-
| tests/layout/reftests/margin-collapsing/block-overflow-2.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/margin-collapsing/block-overflow-2.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/text-input-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/textarea-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/button-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/combobox-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/listbox-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/radio-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/checkbox-native.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| <strike>tests/layout/reftests/native-theme/box-shadow-styling.html</strike> || expected fail (native widget) || <strike>{{bug|471700}}</strike>
|-
| tests/layout/reftests/svg/sizing/inline--display-inline--01.xhtml || left edge of box is broken || {{bug|548648}}
|-
| tests/layout/reftests/svg/sizing/inline--display-inline-block--01.xhtml || left edge of box is broken || {{bug|548648}}
|-
| tests/layout/reftests/svg/sizing/inline--position-relative--01.xhtml || left edge of box is broken || {{bug|548648}}
|-
| tests/layout/reftests/svg/sizing/dynamic--inline-resize-cb-height.xhtml || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/svg/sizing/dynamic--inline-resize-cb-width.xhtml || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/svg/sizing/dynamic--inline-resize-window-width.xhtml || marked as fails in m-c ||
|-
| tests/layout/reftests/svg/opacity-and-gradient-01.svg || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/text/wordwrap-01.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/layout/reftests/transform/iframe-1.html || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|-
| tests/content/test/reftest/xml-stylesheet/lreas_selflink_dtd_id.svg || marked as fails in m-c ||
|-
| tests/layout/xul/base/src/grid/reftests/scrollable-columns.xul || pass with no-scrollbar || <strike>{{bug|556087}}</strike>
|}

== crashtest ==

Here are some guides for running the tests:
* [[https://wiki.mozilla.org/Mobile/Fennec_Reftests maemo]]
* [[https://wiki.mozilla.org/Mobile/WinMo_Reftest winmo]]

{| class="wikitable" style="width: 100%" class="fullwidth-table sortable"
|+
| Test || Status || Bugs
|-
| tests/layout/base/crashtests/311611-1.html || FAIL ||
|-
| tests/layout/base/crashtests/500467-1.html || HANG ||
|}

== xpcshell ==

Here are some guides for running the tests:
* [[https://wiki.mozilla.org/Mobile/Fennec_Xpcshell maemo]]
* [[https://wiki.mozilla.org/Mobile/WinMo_Xpcshell winmo]]

{| class="wikitable" style="width: 100%" class="fullwidth-table sortable"
|+
| Test || Status || Bugs
|-
| tests/jsctypes-test/unit/test_jsctypes.js || ||
|-
| tests/test_uriloader_exthandler/unit/test_handlerService.js || ||
|-
| tests/test_docshell/unit/test_bug414201_jfif.js || ||
|-
| tests/test_places/autocomplete/test_download_embed_bookmarks.js || ||
|-
| tests/test_places/autocomplete/test_livemarks.js || ||
|-
| tests/test_places/sync/test_expire_on_timed_flush.js || ||
|-
| tests/test_places/sync/test_expire_on_timed_flush_not_whole_entry.js || ||
|-
| tests/test_places/unit/test_000_frecency.js || ||
|-
| tests/test_places/unit/test_408221.js || ||
|-
| tests/test_places/unit/test_empty_tags.js || HANGS ||
|-
| tests/test_places/unit/test_frecency.js || ||
|-
| tests/test_places/unit/test_history_autocomplete_tags.js || ||
|-
| tests/test_places/unit/test_migrateFrecency.js || ||
|-
| tests/test_satchel/unit/test_autocomplete.js || ||
|-
| tests/test_satchel/unit/test_expire.js || ||
|-
| tests/test_extensionmanager/unit/test_bug299716.js || ||
|-
| tests/test_extensionmanager/unit/test_bug371495.js || ||
|-
| tests/test_extensionmanager/unit/test_bug396129.js || ||
|-
| tests/test_extensionmanager/unit/test_bug428341.js || ||
|-
| tests/test_extensionmanager/unit/test_bug463819.js || ||
|-
| tests/test_extensionmanager/unit/test_bug470377_1.js || ||
|-
| tests/test_extensionmanager/unit/test_bug470377_2.js || ||
|-
| tests/test_necko/unit/test_file_protocol.js || ||
|-
| tests/test_necko/unit/test_localstreams.js || ||
|}

Mobile/Fennec/WinMoPain

2009-12-01T21:51:49Z

Crowder: /* Needs 1.9.2 landing */

==Bug status==
===Waiting for review===
* <strike>{{bug|527384}} device-width/height support for viewport meta tag '''(mfinkle)'''</strike>
* <strike>{{bug|510917}} Downloading a .cab file from nightly builds page shows nothing in downloads manager ('''mfinkle''')</strike>
* <strike>{{bug|531547}} content is fuzzy, chrome too big ('''mfinkle''')</strike>

===Waiting for approval===
* <strike>{{bug|529348}} improve xptcinvoke implementation on wince</strike>
* <strike>{{bug|520521}} add touch enabled support to windows mobile</strike>
* <strike>{{bug|527182}} fixes broken QI impl for TextEditRules</strike>

===Needs landing===
* <strike>{{bug|490189}} fennec should offer to be the default browser</strike>
* <strike>{{bug|519316}} remote start should happen earlier in start up sequence ('''crowder''')</strike>

===Needs 1.9.2 landing===
* <strike>{{bug|531332}} Run fast-start service</strike>
* <strike>{{bug|530676}} WinMo Installer gets stuck at User Profile Creation on 11/23 1.9.2 nightly </strike>
* <strike>{{bug|529092}}, fixes {{bug|527511}} trailing when panning on windows mobile </strike>
* <strike>{{bug|530367}} Echo only typed passwords (don't flash password from PW manager)</strike>
* <strike>{{bug|527674}} password echoing shows more asterisks than than typed letters</strike>
* <strike>{{bug|519316}} remote start should happen earlier in start up sequence ('''crowder''')</strike>
* {{bug|529852}} cannot install with .exe installer ('''alexp''') - ''depends on the following'':
** <strike>{{bug|530889}} Shutdown FastStart service</strike>
** <strike>{{bug|529897}} Make it possible to install Fennec over the existing version</strike>

===Needs patch (owned)===
* {{bug|525902}} [Regression] No See All Bookmarks icon on today's WinMo 1.9.2 Build ('''mfinkle''')
* {{bug|526257}} first character(s) are lost when typing into the URL bar ('''crowder''')

===Unowned===
* <strike> {{bug|518323}} Install breaks off half way on Windows Mobile 6.5 build 23047</strike>
* <strike>{{bug|522647}} Regression: HTC click wheel zooming broken</strike>

==Pain Points==
===Perf===
* slow startup (16s with or 35+s without fast start) '''blocking alpha 4'''
** Ts talos running by the end of the week
** How to test fast start daemon perf
* panning is too slow
** not blocking alpha 4
* awesome bar takes too long to come up '''blocking alpha 4''' also a maemo blocker
** we have race conditions involving selection that we consistently loose ({{bug|526257}})
** First UI showing
** selection and test switching
** sqlite issues
** results populating
* zoom is super slow '''need to investigate'''

===Usability===
* hard to click on links
* no spatial navigation (as a winmo user, I'm used to having this)
* after selecting an item in the awesome bar (or typing a new url) the previous page's title is shown
* closing and reopening the browser show's the last page you were on for sever seconds before reloading the first run page '''blocking a4'''
* notification bar cut off in portrait mode ''should be fixed''
* First run page looks crappy (zoomed out due to being in portrait)
* lots of little front end polish issues

===Platform Issues===
* Trailing while panning ({{bug|527511}}) '''block a4'''
* not the default browser ({{bug|490189}}) '''block a4'''
* task bar pops in when changing orientation '''block a4'''
* compact querty soft kb unusable
* can't switch keyboards (no SIP button) '''block final'''
* no flash support, need to sort out the activeX side of things
* no html5 video support '''not blocking final'''
* <strike>new 7zip installer ({{bug|502933}}) '''block a4'''</strike> - '''''landed'''''

Mobile/Fennec/WinMoPain

2009-12-01T17:59:23Z

Crowder: /* Needs 1.9.2 landing */

==Bug status==
===Waiting for review===
* <strike>{{bug|527384}} device-width/height support for viewport meta tag '''(mfinkle)'''</strike>
* <strike>{{bug|510917}} Downloading a .cab file from nightly builds page shows nothing in downloads manager ('''mfinkle''')</strike>
* <strike>{{bug|531547}} content is fuzzy, chrome too big ('''mfinkle''')</strike>

===Waiting for approval===
* <strike>{{bug|529348}} improve xptcinvoke implementation on wince</strike>
* <strike>{{bug|520521}} add touch enabled support to windows mobile</strike>
* <strike>{{bug|527182}} fixes broken QI impl for TextEditRules</strike>

===Needs landing===
* {{bug|490189}} fennec should offer to be the default browser '''(r+, with nits, need patch)'''
* <strike>{{bug|519316}} remote start should happen earlier in start up sequence ('''crowder''')</strike>
* {{bug|529852}} cannot install with .exe installer ('''alexp''') - ''depends on the following'':
** <strike>{{bug|529897}} Make it possible to install Fennec over the existing version</strike>
** {{bug|530889}} Shutdown FastStart service

===Needs 1.9.2 landing===
* <strike>{{bug|531332}} Run fast-start service</strike>
* <strike>{{bug|530676}} WinMo Installer gets stuck at User Profile Creation on 11/23 1.9.2 nightly </strike>
* <strike>{{bug|529092}}, fixes {{bug|527511}} trailing when panning on windows mobile </strike>
* <strike>{{bug|530367}} Echo only typed passwords (don't flash password from PW manager)</strike>
* <strike>{{bug|527674}} password echoing shows more asterisks than than typed letters</strike>
* {{bug|519316}} remote start should happen earlier in start up sequence ('''crowder''')

===Needs patch (owned)===
* {{bug|525902}} [Regression] No See All Bookmarks icon on today's WinMo 1.9.2 Build ('''mfinkle''')
* {{bug|526257}} first character(s) are lost when typing into the URL bar ('''crowder''')

===Unowned===
* <strike> {{bug|518323}} Install breaks off half way on Windows Mobile 6.5 build 23047</strike>
* <strike>{{bug|522647}} Regression: HTC click wheel zooming broken</strike>

==Pain Points==
===Perf===
* slow startup (16s with or 35+s without fast start) '''blocking alpha 4'''
** Ts talos running by the end of the week
** How to test fast start daemon perf
* panning is too slow
** not blocking alpha 4
* awesome bar takes too long to come up '''blocking alpha 4''' also a maemo blocker
** we have race conditions involving selection that we consistently loose ({{bug|526257}})
** First UI showing
** selection and test switching
** sqlite issues
** results populating
* zoom is super slow '''need to investigate'''

===Usability===
* hard to click on links
* no spatial navigation (as a winmo user, I'm used to having this)
* after selecting an item in the awesome bar (or typing a new url) the previous page's title is shown
* closing and reopening the browser show's the last page you were on for sever seconds before reloading the first run page '''blocking a4'''
* notification bar cut off in portrait mode ''should be fixed''
* First run page looks crappy (zoomed out due to being in portrait)
* lots of little front end polish issues

===Platform Issues===
* Trailing while panning ({{bug|527511}}) '''block a4'''
* not the default browser ({{bug|490189}}) '''block a4'''
* task bar pops in when changing orientation '''block a4'''
* compact querty soft kb unusable
* can't switch keyboards (no SIP button) '''block final'''
* no flash support, need to sort out the activeX side of things
* no html5 video support '''not blocking final'''
* <strike>new 7zip installer ({{bug|502933}}) '''block a4'''</strike> - '''''landed'''''

Mobile/Fennec/WinMoPain

2009-12-01T17:58:37Z

Crowder: /* Needs landing */

==Bug status==
===Waiting for review===
* <strike>{{bug|527384}} device-width/height support for viewport meta tag '''(mfinkle)'''</strike>
* <strike>{{bug|510917}} Downloading a .cab file from nightly builds page shows nothing in downloads manager ('''mfinkle''')</strike>
* <strike>{{bug|531547}} content is fuzzy, chrome too big ('''mfinkle''')</strike>

===Waiting for approval===
* <strike>{{bug|529348}} improve xptcinvoke implementation on wince</strike>
* <strike>{{bug|520521}} add touch enabled support to windows mobile</strike>
* <strike>{{bug|527182}} fixes broken QI impl for TextEditRules</strike>

===Needs landing===
* {{bug|490189}} fennec should offer to be the default browser '''(r+, with nits, need patch)'''
* <strike>{{bug|519316}} remote start should happen earlier in start up sequence ('''crowder''')</strike>
* {{bug|529852}} cannot install with .exe installer ('''alexp''') - ''depends on the following'':
** <strike>{{bug|529897}} Make it possible to install Fennec over the existing version</strike>
** {{bug|530889}} Shutdown FastStart service

===Needs 1.9.2 landing===
* <strike>{{bug|531332}} Run fast-start service</strike>
* <strike>{{bug|530676}} WinMo Installer gets stuck at User Profile Creation on 11/23 1.9.2 nightly </strike>
* <strike>{{bug|529092}}, fixes {{bug|527511}} trailing when panning on windows mobile </strike>
* <strike>{{bug|530367}} Echo only typed passwords (don't flash password from PW manager)</strike>
* <strike>{{bug|527674}} password echoing shows more asterisks than than typed letters</strike>

===Needs patch (owned)===
* {{bug|525902}} [Regression] No See All Bookmarks icon on today's WinMo 1.9.2 Build ('''mfinkle''')
* {{bug|526257}} first character(s) are lost when typing into the URL bar ('''crowder''')

===Unowned===
* <strike> {{bug|518323}} Install breaks off half way on Windows Mobile 6.5 build 23047</strike>
* <strike>{{bug|522647}} Regression: HTC click wheel zooming broken</strike>

==Pain Points==
===Perf===
* slow startup (16s with or 35+s without fast start) '''blocking alpha 4'''
** Ts talos running by the end of the week
** How to test fast start daemon perf
* panning is too slow
** not blocking alpha 4
* awesome bar takes too long to come up '''blocking alpha 4''' also a maemo blocker
** we have race conditions involving selection that we consistently loose ({{bug|526257}})
** First UI showing
** selection and test switching
** sqlite issues
** results populating
* zoom is super slow '''need to investigate'''

===Usability===
* hard to click on links
* no spatial navigation (as a winmo user, I'm used to having this)
* after selecting an item in the awesome bar (or typing a new url) the previous page's title is shown
* closing and reopening the browser show's the last page you were on for sever seconds before reloading the first run page '''blocking a4'''
* notification bar cut off in portrait mode ''should be fixed''
* First run page looks crappy (zoomed out due to being in portrait)
* lots of little front end polish issues

===Platform Issues===
* Trailing while panning ({{bug|527511}}) '''block a4'''
* not the default browser ({{bug|490189}}) '''block a4'''
* task bar pops in when changing orientation '''block a4'''
* compact querty soft kb unusable
* can't switch keyboards (no SIP button) '''block final'''
* no flash support, need to sort out the activeX side of things
* no html5 video support '''not blocking final'''
* <strike>new 7zip installer ({{bug|502933}}) '''block a4'''</strike> - '''''landed'''''

Mobile/Notes/08-Jul-2009

2009-07-08T16:36:33Z

Crowder: /* Windows Mobile */

== Details ==

* Wednesdays - 9:30am Pacific, 12:30pm Eastern, 17:30 UTC
* 650-903-0800 or 650-215-1282 x92 Conf# 8605 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 8605 (US)
* irc.mozilla.org #mobile for backchannel

== Fennec Requirements ==
* [http://people.mozilla.com/~csejersen/fennec/req.html Requirements]

== Status ==

=== UX design ===

* working on a review / polish of the Weave UI for Fennec
** Query for Weave Fennec UI bugs: [http://bit.ly/weave-fennec-ui http://bit.ly/weave-fennec-ui]

=== Front end ===
* Fixes for small-screen
* Awesome bar patches getting review
* Landed some fixes for <select> handling
* Kinetic/InputHandler patches getting review

=== Geolocation support ===
* waiting on reviews.
* want to look at cell position this q. Need platform cap.

=== Windows Mobile ===
* updater
** all blocking patches have landed
** Joel has unit tests running locally
** main updater patch awaiting review from bsmedberg
* start up
** image scaling issues largely resolved
** largest amount of time spent loading dll's
** work begun on "browserd" and DDE-replacement to enable it
** Windows Mobile profiler is very usable now, though the profiling itself does sway results.
* low-res theme
** Kanth's patches waiting for review from mfinkle (today)
** waiting for new images from sean
* Fullscreen
** backed out, hopefully relanding today
* painting perf
** is there anything we can do for the omnia?

=== Symbian ===

=== [[Mobile#Performance|Performance]] ===

* Networking

* Graphics

* Startup

* Layout

* Fennec

** Tile cache (froystig)
** Changing how we scroll (stuart)

=== Plugins ===

=== Builds ===

=== QA ===

=== Weave ===

== Current Milestone ==

== Other ==

Mobile/Fennec/Releases

2009-05-14T20:57:49Z

Crowder: Formatting tweaks.

Fennec releases will run on a couple different platforms (eventually). Each platform may have it's own way of installing applications.

== Installing Fennec on Windows Mobile ==
Using your current web browser, navigate to http://ftp.mozilla.org/pub/mozilla.org/mobile/releases/wince/1.0a1/fennec-1.0a1.en-US.wince-arm.cab

[[Image:Install-enter-url.png|240px]]

Click yes to accept the download.

[[Image:install-accept-download.png|240px]]

Depending on your connection speed, the download may take a while.

[[Image:install-download-progress.png|240px]]

If you had previously installed Fennec, you'll see this dialog. Click yes.

[[Image:install-previous-version.png|240px]]

If you device is software locked, you'll see this dialog. Click yes.

[[Image:install-unsigned-cab.png|240px]]

The install process will take a few minutes

[[Image:install-install-progress.png|240px]]

Once its complete you'll see this dialog. Click OK.

[[Image:install-success.png|240px]]

To launch click on "Programs" in the start menu.

[[Image:launch-programs.png|240px]]

From there, click on the Fennec icon.

[[Image:launch-icon.png|240px]]

== Installing Fennec on Nokia N810 ==

Fennec releases are provided as .deb packages and can be installed directly to your N810 from the Application Manager. But first, you'll need to configure your Application Manager to look in the Mozilla repository. That's easy to do and once you do it, you won't need to worry about it again. Here is the quick information for setting up the Application Manager:

* '''Web Address:''' http://ftp.mozilla.org/pub/mozilla.org/mobile/
* '''Distribution:''' chinook (Note: The chinook builds work on diablo as well.)
* '''Components:''' release

Here are the step-by-step instructions:

* Open the Application Manager. You should it listed under the '''Settings''' folder.
[[Image:Appman-main.png]]

* You need to add the Mozilla repository to your list of catalogs. Choose "Application manager > Tools > Application catalog..." from the menu.
[[Image:Appman-catalog.png]]

* You should see some application repositories already in the list. You need to add Mozilla's, so press the '''New''' button. Here is the information you need to fill into the form so Mozilla's repository is added to the catalog:
[[Image:Appman-details.png]]

* After filling in the information and pressing '''OK''', you can also '''Close''' the Catalog window. At this point, you should see the catalog list is being refreshed.

* You can now '''Browse installable applications''' from the main Application Manager window. You can choose '''All''' or '''Internet''' and Fennec should be listed as an installable application.
[[Image:Appman-chooseapp.png]]

* Choose '''fennec''' and press the '''Install''' button (at the bottom of the screen). After some dialogs double check your desire to install this non-official software, the application will be downloaded and installed.
[[Image:Appman-dialogs.png]]

* After a successful installation, you can launch Fennec from the '''Extras''' folder:
[[Image:Appman-launchapp.png]]

Mobile/Fennec/Releases

2009-05-14T20:54:08Z

Crowder: /* Installing Fennec on Windows Mobile */

Fennec releases will run on a couple different platforms (eventually). Each platform may have it's own way of installing applications.

== Installing Fennec on Windows Mobile ==
Using your current web browser, navigate to http://ftp.mozilla.org/pub/mozilla.org/mobile/releases/wince/1.0a1/fennec-1.0a1.en-US.wince-arm.cab
[[Image:Install-enter-url.png|240px]]

Click yes to accept the download.
[[Image:install-accept-download.png|240px]]

Depending on your connection speed, the download may take a while.
[[Image:install-download-progress.png|240px]]

if you had previously installed Fennec, you'll see this dialog. Click yes.
[[Image:install-previous-version.png|240px]]

If you device is software locked, you'll see this dialog. Click yes.
[[Image:install-unsigned-cab.png|240px]]

The install process will take a few minutes
[[Image:install-install-progress.png|240px]]

Once its complete you'll see this dialog. Click OK.
[[Image:install-success.png|240px]]

To launch click on "Programs" in the start menu.
[[Image:launch-programs.png|240px]]

From there, click on the Fennec icon.
[[Image:launch-icon.png|240px]]

== Installing Fennec on Nokia N810 ==

Fennec releases are provided as .deb packages and can be installed directly to your N810 from the Application Manager. But first, you'll need to configure your Application Manager to look in the Mozilla repository. That's easy to do and once you do it, you won't need to worry about it again. Here is the quick information for setting up the Application Manager:

* '''Web Address:''' http://ftp.mozilla.org/pub/mozilla.org/mobile/
* '''Distribution:''' chinook (Note: The chinook builds work on diablo as well.)
* '''Components:''' release

Here are the step-by-step instructions:

* Open the Application Manager. You should it listed under the '''Settings''' folder.
[[Image:Appman-main.png]]

* You need to add the Mozilla repository to your list of catalogs. Choose "Application manager > Tools > Application catalog..." from the menu.
[[Image:Appman-catalog.png]]

* You should see some application repositories already in the list. You need to add Mozilla's, so press the '''New''' button. Here is the information you need to fill into the form so Mozilla's repository is added to the catalog:
[[Image:Appman-details.png]]

* After filling in the information and pressing '''OK''', you can also '''Close''' the Catalog window. At this point, you should see the catalog list is being refreshed.

* You can now '''Browse installable applications''' from the main Application Manager window. You can choose '''All''' or '''Internet''' and Fennec should be listed as an installable application.
[[Image:Appman-chooseapp.png]]

* Choose '''fennec''' and press the '''Install''' button (at the bottom of the screen). After some dialogs double check your desire to install this non-official software, the application will be downloaded and installed.
[[Image:Appman-dialogs.png]]

* After a successful installation, you can launch Fennec from the '''Extras''' folder:
[[Image:Appman-launchapp.png]]

Mobile/Notes/24-Nov-2008

2008-11-24T17:05:27Z

Crowder: /* Windows Mobile */

=== Details ===

* Mondays - 9:00am Pacific, 12:00pm Eastern, 17:00 UTC
* 650-903-0800 or 650-215-1282 x91 Conf# 8605 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 8605 (US)
* irc.mozilla.org #mobile for backchannel

=== Notices ===
* [http://people.mozilla.com/~csejersen/fennec/req.html Requirements]

== Fennec Status ==

* M10 / Alpha 2 Scheduling

=== UX design ===

* work-in-progress UI design status page [http://spreadsheets.google.com/ccc?key=p2tjDbTybTBrG9uAjuSPTZQ&hl=en UI design status spreadsheet]
* queries: [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Fennec&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=UI+polish&keywords_type=allwords&keywords=&resolution=DUPLICATE&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= all Fennec UI polish bugs], [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Fennec&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=uiwanted&resolution=DUPLICATE&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Fennec uiwanted bugs]
* if you open a bug that needs some UI/UX attention, use the "uiwanted" keyword

New:
* Doing more with the site button (for RSS and search plugin discovery): [[Mobile/UI/Designs/TouchScreen/workingUI#Extended_Site_Button]]
* Mockups for authentication: [[Mobile/UI/Designs/TouchScreen/workingUI#Authentication]]
* Defining the desktop integration (weave) UX
** Overview: [[Mobile/UI/Designs/TouchScreen/workingUI/desktop_integration]]
** jono's proposed UI: [http://people.mozilla.com/~jdicarlo/weave-fennec-ui.html]
** proposed UI for tabs: [[Mobile/UI/Designs/TouchScreen/workingUI/desktop_integration/interface1]] (madhava)

Ongoing:

* bookmark management - early wireframes here: [[Mobile/UI/Designs/TouchScreen/workingUI/bookmark_management]]
* context-sensitive menus [[Mobile/UI/Designs/TouchScreen/workingUI/CSM]]
* [https://wiki.mozilla.org/Mobile/UI/Designs/TouchScreen/workingUI#Panning_and_Zooming better defining panning and zooming behaviour]

=== UI ===

* Unified panning (mfinkle/gavin/vlad/stuart)
** [https://bugzilla.mozilla.org/show_bug.cgi?id=462425 landed]
(see the [https://wiki.mozilla.org/User:Pavlov/MobileRefactoring tracking] page for remaining work to get it back to a1 functionality)

=== Geo support ===

=== Platform ===

=== Windows Mobile ===
* working on "faux gcc"less build system (crowder)

=== [[Mobile#Performance|Performance]] ===
* {{bug|461031}} Content sink notifications

* Networking
** {{bug|447866}} Better pipelining

* Graphics

=== Plugins ===
* {{bug|456091}}
* {{bug|456045}}

=== Builds ===

=== QA ===
* Big Blockers for Mochitests (unlocks a large number of mochitests)
** {{bug|455891}} - issues with setting Focus on elements -- has patch, in review
** <strike>{{bug|454613}} - showModalDialog issue</strike>

* Lesser issues, related to plugin support:
** {{bug|455956}} - plugin style
** {{bug|455866}} - pluginNotFound event not firing

* Developed script to run reftests/crashtests on device
* Developed [[https://wiki.mozilla.org/Mobile/Fennec_Automation table]] to track automated tests on fennec

* Additional [[https://litmus.mozilla.org/run_tests.cgi?test_run_id=35 litmus]] BFT's created for fennec

== Other ==

Mobile/Build/WindowsMobileBugs

2008-11-11T16:18:43Z

Crowder: /* Build Bustages */

== Build Bustages ==
* {{bug|456449}}nspr_love
** dougt
** '''r? wtc'''
* {{bug|464091}} widget_hacky_stuff
** '''dougt''' needs update
* {{bug|455381}}xpcom_unicode_changes
** blassey
** '''r? bsmedberg'''
* {{bug|455381}}nsCommonProcess
** '''r? bsmedberg'''
* {{bug|464088}}dont_build_dbm
** dougt
** patched attached, '''who should review?'''
* {{bug|454120}}nss_love
** dougt
** '''Blocked on NSS Reviewer'''
* {{bug|464095}} sqlite
** blassey
** r? sdwilsh
** ''fixed upstream''
* {{bug|461839}}unscribe_breaker
** dougt
** '''ready for review?'''
* {{bug|461841}}js_cleanup
** dougt
** '''r? crowder'''
* {{bug|461845}}lcm_fixes
** dougt
** '''r? pavlov'''
* {{bug|461847}}bzlib_bustage
** '''r? pavlov'''
* {{bug|461848}}libjar_bustage
** r+sr+ dveditz
** '''needs checkin'''
* {{bug|461849}}icon_bustage
** '''r? pavlov'''
* {{bug|461856}}toolkit_username
** r+ bsmedberg
** '''needs checking'''
* {{bug|461858}}toolkit_bustage
** '''blassey''' needs to update
** r- bsmedberg
* {{bug|461859}}xpcom_bustage
** '''blassey''' ready for review?
* {{bug|461860}}gfx_fixup
** '''dougt''' ready for review?
* {{bug|461844}}media_cleanup
** '''dougt''' needs to update
** asking chris double for suggestions.
* {{bug|463326}} expand_env_strings
** r- blassey
** '''wolfe needs to update'''
* {{bug|463532}} freetype2_import
** blassey
** '''r? ted'''
** '''sr? vlad'''
* {{bug|462908}} windows_freetype_font_backend
** '''blassey''' needs to update
** ''r? karlt''
** ''sr? pav''
** comments from karlt and vlad,
* {{bug|462912}} js_tracing_bustage
** needs landing
* {{bug|464166}} dllmain_wince
** blassey
** '''r? bsmedberg'''
* {{bug|464178}} js_bustage_int_ptr
** p=blassey
** passing ownership to '''crowder'''
* {{bug|464190}} GetProcAddress_configure
** dougt
** '''r? ted'''
* {{bug|464180}}_FNan_fix
** blassey
** bustage from wave decoder landing
** '''r? kinetik'''
* {{bug|463532}} ft_char_bit
** blassey
** root cause of mkdepend crash
** '''r? ted'''
* {{bug|464052}} no_far
** blassey
** already fixed on i386
** needs landing

== Runtime Errors ==
* {{bug|459677}} dpi_scale
** blassey
** sr+r = bz
** '''needs checkin'''
* {{bug|460767}} imgRequest_null_frame
** blassey
** r= pavlov
** '''checkin needed'''
* {{bug|463562}} mmtimer
** blassey
** '''r? pavlov'''
** discussion on trade off of accuracy/speed/additional dep

== Not Critical ==
* {{bug|458950}}updater_fixes
** blassey
** let's just disable the updater for now?
* {{bug|463561}} mkdepends_div_by_0
** blassey
** '''r? bs'''
** not in critical path anymore

Tamarin:WeeklyUpdates

2008-05-20T20:58:56Z

Crowder: /* Attendees */

:''These updates concern Tamarin and related projects only.''

'''Meeting Details'''
* 2:00pm Pacific Time (21:00 UTC) on Tuesdays
** (5PM Eastern US, 11PM Oslo, 6AM (Wed) Seoul, 7AM (Wed) Melbourne)

* Location: Tel: 866 705 2554 (us), 913 227 1201 (int’l)
** Passcode: 9140087
* Duration: 60 minutes
* join irc.mozilla.org #tamarin for attendence taking and questions

* '''Next meeting's Agenda Items:'''
** (Moh/Intel)-
*** Significant performance improvements through a shortcut in String::equalsUTF8
**** https://bugzilla.mozilla.org/show_bug.cgi?id=433799
*** runtests.py script is unfair
**** https://bugzilla.mozilla.org/show_bug.cgi?id=434118
*** Does it make sense to have a fast post-codegen pass to do code-alignment among other peephole optimizations? Starting points? Jungwoo is exploring.
*** Shengnan needs LIR_file and LIR_line in TT to enable VTune. Starting points?
**** https://bugzilla.mozilla.org/show_bug.cgi?id=432737
** (Jim/Mozilla)-
*** Moving TC's MMgc into TT: compiles, but there are still test regressions. Tommy has reviewed changes from TT's MMgc for inclusion in TC's MMgc (backmerge); seven patches waiting for review
**** https://bugzilla.mozilla.org/show_bug.cgi?id=409021

* '''Last meeting's Agenda Items:'''
** (Moh/Intel)-
*** Major performance gains from optimized doubleToInt32(double d) using integer code. https://bugzilla.mozilla.org/show_bug.cgi?id=412978
***CMOV is no longer considered harmful! A discussion on the performance considerations of using CMOV.
** (Mark Hammond)-
*** How to best evangelize Tamarin through ScreamingMonkey?

= 6th May 2008 =

== Attendees ==

* Adobe: Ed, Scott, Rick, Steven, Tom
* Mozilla: Dave, Jason, Jim, Brian Crowder
* Intel: Shengnan Cong, Marsha Eng, Jungwoo Ha, Moh Haghighat, Mingqiu Sun

== Updates ==

** Moh (Intel)-
*** Major performance gains from optimized doubleToInt32 (double d) using integer code. https://bugzilla.mozilla.org/show_bug.cgi?id=412978
**** This is used in SpiderMonkey and Tamarin. Intel’s numeric team has helped out with this issue. Great performance gains thus far- Ed has also gotten these consistent results
***** Mozilla to see how this works with Firefox
**** Now it needs to be tested!
*** CMOV is no longer considered harmful!
**** A discussion on the performance considerations of using CMOV. Intel recommends using CMOV except in certain highly predictable cases.

** Steven (Adobe)-
*** Working on a patch for an interpreter speed-up. Currently is only working on Mac. Patch should be viewable later today.
**** Progress is being made!

** Rick (Adobe)-
*** Is continuing to work on trees. Expects to land patch soon and go over updates in the next few weeks.

** Jim (Mozilla)-
*** Update on regression of performance. In order for Tamarin to get into Mozilla, then patches can’t land if they slow things down. Take a benchmark approach and get TT to be on par w/ SpiderMonkey- then it can be switched over.
**** Mozilla will contribute speed optimizations to Adobe. Adobe needs to be comfortable making optimized code “clean” going forward, while making sure the numbers hit.
***** Adobe is building out its own internal performance measurements now. Going forward, make sure Mozilla and Adobe have agreement on benchmarks.

** Tom (Adobe)-
*** Has posted a wiki page on Hosting APIs that he wants Mozilla to review. He will also send around to the list.

** Mark Hammond-
*** How to best evangelize Tamarin through ScreamingMonkey? How to get folks using it?
**** The IE DOM works as hopes (minus some expected issues). Can we evangelize and package? Yes, but who can assist? John R and other evangelists can blog on this. Brendan to follow-up with Mark on this.

= Older meetings =
* [[Tamarin:WeeklyUpdates/2008-04-15|April 15, 2008]]
* [[Tamarin:WeeklyUpdates/2008-03-25|March 25, 2008]]
* [[Tamarin:WeeklyUpdates/2008-03-18|March 18, 2008]]
* [[Tamarin:WeeklyUpdates/2008-03-11|March 11, 2008]]
* [[Tamarin:WeeklyUpdates/TamarinSummit2008|Tamarin Tech Summit Agenda, February 1, 2008]]
* [[Tamarin:WeeklyUpdates/2008-01-15|January 15, 2008]]
* [[Tamarin:WeeklyUpdates/2008-01-08|January 08, 2008]]
* [[Tamarin:WeeklyUpdates/2007-12-18|December 18, 2007]]
* [[Tamarin:WeeklyUpdates/2007-12-01|December 11, 2007]]
* [[Tamarin:WeeklyUpdates/2007-12-04|December 4, 2007]]
* [[Tamarin:WeeklyUpdates/2007-11-27|November 27, 2007]]
* [[Tamarin:WeeklyUpdates/2007-11-07|November 7, 2007]]
* [[Tamarin:WeeklyUpdates/2007-10-30|October 30, 2007]]
* [[Tamarin:WeeklyUpdates/2007-10-23|October 23, 2007]]
* [[Tamarin:WeeklyUpdates/2007-10-16|October 16, 2007]]
* [[Tamarin:WeeklyUpdates/2007-10-09|October 9, 2007]]
* [[Tamarin:WeeklyUpdates/2007-10-02|October 2, 2007]]
* [[Tamarin:WeeklyUpdates/2007-09-25|September 25, 2007]]
* [[Tamarin:WeeklyUpdates/2007-09-18|September 18, 2007]]
* [[Tamarin:WeeklyUpdates/2007-09-11|September 11, 2007]]
* [[Tamarin:WeeklyUpdates/2007-09-04|September 4, 2007]]
* [[Tamarin:WeeklyUpdates/2007-08-28|August 28, 2007]]
* [[Tamarin:WeeklyUpdates/2007-08-14|August 14, 2007]]
* [[Tamarin:WeeklyUpdates/2007-08-07|August 7, 2007]]
* [[Tamarin:WeeklyUpdates/Announcement|Meeting Announcement]]

Breakpad/Design/Database

2007-03-31T03:16:36Z

Crowder: Some feedback morgamic asked me to contribute

'''[[Breakpad/Design|« back to Breakpad design page]]'''

= Breakpad Database =
ER draft:
http://people.mozilla.org/~morgamic/breakpad-er.jpg
* [http://www.flickr.com/photo_zoom.gne?id=440017945&size=l whiteboarded first run] (don't laugh, sucka!)

Not sure about:
* How much we need to break apart the frames table?
** ''What you have here looks about right, imho.'' - [[User:Crowder|Crowder]]
* How normalized do we want things?
** ''Err on the side of more rather than less.'' - [[User:Crowder|Crowder]]
* For id->name pairings is it worth pulling the values out since data will be duplicated heavily for things like product, platform, os, etc.? To reduce the size of the main reports table I think it's necessary but I'm open to being convinced otherwise.
** ''For things where you can save time and space, normalize here, otherwise don't.'' - [[User:Crowder|Crowder]]
* Do comment and reason need to be separated from the report table as well?
** ''No'' - [[User:Crowder|Crowder]]
* Need some additional tables not talked about
** Crash groupings by address, module, function?
** For each of these groupings -- bugs open, bugs closed table
** Stored bugzilla queries in each of these groupings pointing to a query that brings up all related bugs
** A table (or set of tables) recording all the DLLs associated and captured with each report (perhaps DLL ID/version, then normalize DLL names to elsewhere) [[User:Crowder|Crowder]]

PostgreSQL 8.2 or higher should be used because it offers things that MySQL does not have:
* Partitioning if we need to scale the database in the future, which will likely happen if we plan on keeping more than 3 months worth of data. For example, we could partition by date and have the db create a new child table for each new month as time goes on, then pop off outdated partitions once they become too old but keep them in another db for since-beginning-of-time queries. Popping the old tables off the "stack" could be done using a backend script/procedure/cron -- whatever.
* Arguably better performance for larger data sets (read Google if you want to, but most of this lies in partitioning and bitmask joins)
* More precise datatypes (adhering to SQL standards is a plus)
* Long-standing support for stored procedures
* Views for databases that are heavily normalized (helps in simple reporting!)

Designing the schema is an important task and shouldn't be taken lightly. In general, there are typically two routes to take:
* Normalize, come up with a snowflake-like schema, abstract up-front but better long-term
* Leave denormalized, just swallow inefficiencies in the short term and pay the price later on
** ''As mentioned above, I vote for the former.'' - [[User:Crowder|Crowder]]

How we can have both:
* Normalize properly, generating a properly abstracted set of tables with partitions
* Use views to pull together common queries used for reporting

The current schema has:
* individual minidump records
* product/OS/buildid information
* control information used to "register" an incoming minidump and monitor/track/control its progress though all the stages from being transfered from the client until it is fully collected and processed on the server and available for reporting and analysis.

A major concern about over-normalization is data insertion and the problems it presents for the processor, which should probably be transactional and may have to do lookups and some db magic in order to successfully insert new records.
* ''Should be able to cache repetitive stuff like OS in whatever tool is talking to the DB to save it some work, if necessary'' - [[User:Crowder|Crowder]]
The lookups would be on stuff like product name, build, platform, os, locale, url, etc. I am interested in getting all this stuff out of the main table mainly because there is going to be a ridiculous amount of duplication.

I think there are two options here:
* Just dynamically add non-existent data if it hasn't been previously recorded, which could end up creating a bunch of messed up records depending on what we get back from clients
* Ignore stuff we haven't already accounted for, which ensures ACID but could eliminate things we "forgot" to prefill

I am not sure if this is the same problem as below -- I'd like to talk more about this in the meeting (this was on this page from before):
* Using the same database and schema for the minidump data and also for control over the processing of the minidumps has created problems in the past. when coruption is introduced, database performance problems crop up, or maintenance is required to manage the collection of minidumps, the processing of incoming minidumps is hindered and we start into a downward spiral of compounding problems. We should do some thinking to see if there are ways to improve on the existing design.

Breakpad/Design/Client

2007-03-31T02:48:29Z

Crowder: typo

'''[[Breakpad/Design|« back to Breakpad design page]]'''

= Breakpad Client Design and Requirements =

* Platform integration for Windows, Mac OS X, Linux
* UI parity with Mozilla products
* crash minidumps will be stored on the user HD automatically. NOTE: need to delete on "Clear Private Data"
* opt-in control for users to participate in sending data at all, and confirmation before sending any individual blackbox. also the ability to supply e-mail contact info, last visited site, and comments about activity leading up to the crash.
* Collect and send data to Breakpad Server** Product info (product, version, platform, build id, airbag version)
** System information
*** os version
*** processor, processor speed
*** available and in use memory and diskspace
*** screen size resolution and any available info on graphic system
*** process list for other programs that might be in use and conflicting
*** command line start up options --
*** extensions loaded (new)
*** we could also consider improvements like auto filling crash url with info out of history, or send a recent history list under user control.
** Stability statistics (total runtime, time since last crash, crash frequency, etc.)
** Minidumps automatically contain the list of DLLs in the process that crashed, which will give us plugin data
* Store incident queue/history
* Talkback also has the ability to receive config changes back from the server to control operations of the client. This is useful for such things as controls for shutting down the client for obsolete versions, slow down the transmission re-try rate or for another throttling mechanisms.

* It seems like, with some cleverness in recording symbol-offsets for various functions, we might be able to cause the client to analyze interesting stack variables in frames it recognizes. Perhaps this would allow us to collect information about JS (python?) code that was running at the time of the crash?

Breakpad/Design/Client

2007-03-31T02:47:58Z

Crowder: adding a brainstorm

'''[[Breakpad/Design|« back to Breakpad design page]]'''

= Breakpad Client Design and Requirements =

* Platform integration for Windows, Mac OS X, Linux
* UI parity with Mozilla products
* crash minidumps will be stored on the user HD automatically. NOTE: need to delete on "Clear Private Data"
* opt-in control for users to participate in sending data at all, and confirmation before sending any individual blackbox. also the ability to supply e-mail contact info, last visited site, and comments about activity leading up to the crash.
* Collect and send data to Breakpad Server** Product info (product, version, platform, build id, airbag version)
** System information
*** os version
*** processor, processor speed
*** available and in use memory and diskspace
*** screen size resolution and any available info on graphic system
*** process list for other programs that might be in use and conflicting
*** command line start up options --
*** extensions loaded (new)
*** we could also consider improvements like auto filling crash url with info out of history, or send a recent history list under user control.
** Stability statistics (total runtime, time since last crash, crash frequency, etc.)
** Minidumps automatically contain the list of DLLs in the process that crashed, which will give us plugin data
* Store incident queue/history
* Talkback also has the ability to receive config changes back from the server to control operations of the client. This is useful for such things as controls for shutting down the client for obsolete versions, slow down the transmission re-try rate or for another throttling mechanisms.

* It seems like, with some cleverness in recording symbol-offsets for various functions, we might be able to cause the client to analyse interesting stack variables in frames it recognizes. Perhaps this would allow us to collect information about JS (python?) code that was running at the time of the crash?

Gecko:1.9a2/ReleaseNotes

2007-02-06T07:08:35Z

Crowder: Added removal of JS Script object

== What should be on this page ==

There are four categories of items that should be on this page.

* '''Areas of Focus/Major Changes''' --- these are areas that all users of the alpha release should pay attention to, and should cover major changes since the last release as well as any known stability or data loss issues that users should be aware of. Issues that may affect web compatibility should also be in this section.

* '''Minor Changes''' --- areas that have been improved or changed and deserve explicit mention in the release notes.

* '''Bugfixes''' --- specific bugs that were fixed that deserve explicit mention. Items in this category will not make it into the actual release notes page that lives on mozilla.org, but that page will link to this page for those desiring more information.

For reference, here are [http://www.mozilla.org/projects/firefox/3.0a1/releasenotes/ the 1.9a1 release notes].

== Major Changes ==

* '''Known memory leak after prolonged browser usage.''' In order to better handle memory issues, a new garbage collection system has been implemented for native code. However, the process of integrating code into this system is still ongoing, and you may notice excessive memory usage after the browser is used for a long period of time. A restart should fix this problem, which will also be fixed in 1.9a3.

* '''Some Windows font rendering issues.''' With the partial landing of the new Cairo-based [http://wiki.mozilla.org/Gecko2:NewTextAPI nsTextFrame], some font rendering issues have been discovered on Windows-based platforms. These regressions will be fixed when the new code is fully landed for 1.9a3.

* Changes that [http://wiki.mozilla.org/Gecko:Reflow_Refactoring refactored] intrinsic width computation and incremental layout landed. This means that the code for determining intrinsic widths, used for width calculations in tables, floats, and absolutely positioned elements, has been rewritten. The code for handling incremental layout of pages (as the page arrives over the network, as images load, or as other dynamic changes are made) has also been changed extensively. These changes also resolved all of the remaining issues with ACID2 compliance

* The <code>inline-block</code> and <code>inline-table</code> values of CSS2.1's display property are now implemented.

== Minor Changes ==
* '''Incremental XML rendering.''' XML documents can now be rendered as they're downloaded from the originating server instead of after the full document has been downloaded.

* '''Support for Web Apps 1.0 API for changing stylesheets.''' This change enables Gecko to use a standard method for changing stylesheets via the DOM.

* '''Removed ''Script'' Object.''' The non-standard JavaScript ''Script'' object is no longer supported in default browser builds.

== Bugfixes ==

FirefoxSummit/2006/ProposedSessions/Text and Typography

2006-11-14T19:53:27Z

Crowder: /* Interested Attendees */

__NOTOC__
== Session Title ==

Text And Typography

== Session Leader ==

Robert O'Callahan

== Summary ==

We are reworking Gecko text infrastructure to support higher quality typography, to better support I18N, and (hopefully) for better performance. This session is to talk about where we're at and what still needs to be done for Gecko 1.9 and beyond.

== Agenda ==

* Overview of what's going on
** New textframe
** New textrun API
** Platform textrun implementations
* Discuss how this fits with SVG, I18N
* New linebreaker API?
* Changes to line breaking algorithm
* Auto-hyphenation?

== Interested Attendees ==

Please add your name here if you're likely to attend this session, this will help prioritize sessions and minimize conflicts.

* tor
* [[User:Dbaron|David Baron]]
* Christopher Aillon
* [[User:Smontagu|Simon Montagu]]
* Sheppy
* biesi
* Axel Hecht
* ispiked
* [[User:Waldo|Jeff Walden]] (want to attend, depends on schedule)
* rbs
* stuart
* [[User:Stan Shebs|Stan Shebs]]
* timeless
* [[User:rcampbell|robcee]]
* [[User:Crowder|Crowder]]

FirefoxSummit/2006/ProposedSessions/Microformats

2006-11-14T19:52:38Z

Crowder: /* Interested Attendees */

__NOTOC__
== Session Title ==

Microformat Detection in Firefox

== Session Leaders ==

[[User:Faaborg | Alex Faaborg]] (UE) and dmose/Myk (Implementation)

== Summary ==

Should Web browsers retroactively react to the organic development of the Web, or should they proactively drive innovation and progress? In this session we will discuss adding support for microformats in Firefox 3.

== Agenda ==

* Introduction to microformats
* Overview of the competitive landscape
** Apple
** IE8
** Live Clipboard
* The pros and cons of native support
* The need for a unified user experience for data detectors
* The user experience of microformat detection
* Implementation issues

== Interested Attendees ==

* [[User:Faaborg | Alex Faaborg]]
* Sherman
* Myk
* Jay Goldman (Radiant Core) - we've been working on a Firefox Extension for some time that does Microformat detection and will, one day, do handling of different formats. I've done a bunch of thinking around how to do the UI side of things, so maybe our efforts can end up part of the Fx3 conversation.
* Dria
* [[User:Dbaron|David Baron]]
* [[User:Wenzel|Frederic Wenzel]]
* Sheppy
* Dietrich
* Axel Hecht
* Gen Kanai - fwiw, I used to work at Technorati Japan and have had a close working relationship with the Technorati US team as well as Tantek
* Ian Hayward (Glaxstar)
* [[User:Rflint|Ryan Flint]]
* ispiked
* beltzner
* [[User:StevenGarrity|Steven Garrity]] (if schedule allows)
* Basil Hashem
* robcee
* Juan Becerra
* [[User:Crowder|Crowder]]

FirefoxSummit/2006/ProposedSessions/FuzzTesting

2006-11-14T19:51:31Z

Crowder: /* Interested Attendees */

__NOTOC__
== Session Title ==

Fuzz-testing Gecko

== Session Leader ==

Jesse Ruderman

== Summary ==

'''Fuzz testing''' is the art of creating "random" but interesting input to a program. For example, someone wanting to test an HTML parser might feed it thousands of horribly invalid HTML files. But someone testing code that displays SVG would want to use well-formed XML, only using SVG tags and attributes in random combinations and sometimes in invalid ways.

Hundreds of bugs have been fixed as a result of fuzz-testing components of Gecko over the last 15 months. Many of these were bogus assertion failures or obscure hangs, but some were security holes.

== Agenda ==

* How the Gecko fuzzers work
* The state of Gecko (with respect to fuzzing)
* Strategies for creating new fuzzers that are effective at finding bugs and facilitate creating reduced testcases after finding bugs
* What Gecko features, components, and APIs haven't been fuzz-tested and should be?

== Interested Attendees ==

Please add your name here if you're likely to attend this session, this will help prioritize sessions and minimize conflicts

* [[User:Waldo|Jeff Walden]]
* [[User:GavinSharp|Gavin]]
* tor
* [[User:Dbaron|David Baron]]
* [[User:Zachlipton|Zach Lipton]]
* Christopher Aillon
* rbs
* Steven Michaud
* [[User:Pettay|Olli Pettay]]
* Jonas Sicking
* chofmann
* Roc
* ispiked
* [[User:Rflint|Ryan Flint]]
* [[User:MartijnWargers| Martijn Wargers]]
* [[User:rcampbell|robcee]]
* [[User:Crowder|Crowder]]

AutomatedTestingSummit2006

2006-11-14T19:50:55Z

Crowder: /* Interested Attendees */

__NOTOC__
== Session Title ==

Automated testing: unit testing, test frameworks, test tools

== Session Leader ==

Tim Riley

== Summary ==

Review and discuss current test automation activities around unit testing, web page compatibility, performance testing, and execution/reporting infrastructure

== Agenda ==

* review specific activities
** mochikit
** RefTest
** New Tp performance tests
** Eggplant automation of smoke tests
** Setting up test buildbots
** others?
* Discuss upcoming activities
** fully automating the JS tests and security tests
** Ts Performance tests
** Getting the reporting tied into the tinderbox pages
** Other ideas??
** Prioritizing projects
** Who can help?

== Interested Attendees ==

Please add your name here if you're likely to attend this session, this will help prioritize sessions and minimize conflicts

* Robert Sayre
* Rob Campbell
* [[User:GavinSharp|Gavin]]
* Dave Townsend
* tor
* biesi
* shaver
* [[User:Waldo|Jeff Walden]]
* ispiked
* Jesse Ruderman
* Steve England
* Jay Goldman or Michael Glenn (Radiant Core)
* Steven Michaud
* [[User:Pettay|Olli Pettay]]
* Roc
* dietrich
* bsmedberg
* Christopher Aillon
* Javier Pedemonte
* [[User:AxelHecht|Axel Hecht]]
* [[User:Rhelmer| Rob Helmer]]
* Juan Becerra
* [[User:Crowder|Crowder]]

VersionControlSummit2006

2006-11-14T19:48:35Z

Crowder: /* Interested Attendees */

__NOTOC__
== Session Title ==

Version Control System Shootout Extravaganza

== Session Leader ==

''Preed'', ''Vlad'', ''Rhelmer''

== Summary ==

Lock everyone in a room and finally decide a) If we're switching version control systems, and b) the plan for switching

The goal is to not leave until b) is decided (assuming a) is true; if it's not, this will be a short meeting!)

== Agenda ==

* Kick people out who haven't reviewed the [[Version_Control_System_Requirements|original requirements]] :-)
* Review the revision control systems we've prototyped (This implies that there's been some minimal level of investigation on the system done, i.e. an import of the current CVS tree)
** SVN (Note: the SVN team have provided [[Version_Control_System_Requirements/SVN_Responses|responses]] to the original requirements)
** Hg
* A deathmatch until we've reached a decision. Will be broadcast on pay-per-view. Proceeds to go to the Foundation. (I kid, I kid...)

== Interested Attendees ==

Please add your name here if you're likely to attend this session, this will help prioritize sessions and minimize conflicts.

* Roc
* Reed
* caillon
* [[User:Dbaron|David Baron]]
* [[User:Wenzel|Frederic Wenzel]]
* tor
* biesi
* ispiked
* [[User:Rflint|Ryan Flint]]
* graydon
* Zach
* [[User:GavinSharp|Gavin]]
* [[User:Waldo|Jeff Walden]]
* shaver
* stuart
* bsmedberg
* [[User:Sancus|sancus]]
* [[User:Brendan|Brendan Eich]]
* [[User:Crowder|Crowder]]

VersionControlSummit2006

2006-11-14T19:39:10Z

Crowder: /* Interested Attendees */

FirefoxSummit/2006/ProposedSessions/Mozilla 2

2006-11-14T19:38:21Z

Crowder: /* Interested Attendees */

__NOTOC__
== Session Title ==

Mozilla 2 Kick-off

== Session Leader ==

[[User:Brendan|Brendan Eich]]

== Summary ==

Update, planning, and discussion of the proposals and challenges set forth in my [http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozilla_2.html|Mozilla 2] blog item.

== Agenda ==

See [[Mozilla_2]].

== Interested Attendees ==

Please add your name here if you're likely to attend this session, this will help prioritize sessions and minimize conflicts

* [[User:rcampbell|robcee]]
* Jesse Ruderman
* [[User:AxelHecht|Axel Hecht]]
* [[User:Rhelmer|Rob Helmer]]
* Brian Crowder

FirefoxSummit/2006/ProposedSessions/Oink

2006-11-14T19:19:33Z

Crowder: /* Interested Attendees */

__NOTOC__
== Session Title ==

Elsa/Oink/Cqual++: Open-Source Static Analysis for C++

== Session Leader ==

[http://www.cs.berkeley.edu/~dsw/ Daniel S. Wilkerson], with [[Users:Brendan | Brendan Eich]] hosting

== Summary ==

Dan's Oink presentation, with (I hope) helpful examples aimed at Mozilla 2

== Agenda ==

Dan's talk is [[http://www.cs.berkeley.edu/~dsw/elsa_cqual_codecon.ppt|online]] (PowerPoint, boo hiss).

== Interested Attendees ==

Please add your name here if you're likely to attend this session, this will help prioritize sessions and minimize conflicts

* Jesse Ruderman
* Roc
* [[User:Rhelmer|Rob Helmer]]
* Brian Crowder

JavaScript:SpiderMonkey:RegExp API

2006-09-29T23:11:49Z

Crowder: the already-defined routines don't offer "flat" param, so ditch it

=JavaScript Regular Expression API=

The purpose of this addition to the JS API is to make ECMA-262 compliant regular expression APIs available to C/C++ users. As with other JS API routines, clients are required to provide a properly initialized execution context (JSContext), and the API has the potential to throw JS exceptions, just as a script might.

==Structures==
<dt>JSObject</dt>
<dd>Used to track a JSRegExp, the structure of which we do not expose publically.</dd>

==Routines==
<dt>JSObject * JS_NewRegExpObjectFromString(JSContext *cx, const? JSString *str, uintN flags)</dt>
<dd>Used to build a JSObject which holds a precompiled regular expression to be used in future routines. I also am not entirely clear on what "flat" does, can someone explain it to me? --[[User:Crowder|Crowder]] 09:15, 31 August 2006 (PDT)</dd>

<dt>JSObject * JS_CloneRegExpObject(JSContext *cx, JSObject *obj, JSObject *parent)</dt>
<dd>Do we need this?</dd>

<dt>void JS_DestroyRegExpObject(JSContext *cx, JSObject *obj)</dt>
<dd>Used to destroy the object built with JS_NewRegExpObject.</dd>

<dt>JSBool JS_ExecuteRegExp(JSContext *cx, JSObject *re, const? JSString *input, JSBool test, jsval *rval)</dt>
<dd>Executes the expression compiled into ''re'' against ''input''. ''test'' is a flag which dictates whether or not
we're actually interested in results beyond whether the expression matches or not (ie., for parenthesized parts of the
expression, $1, $2, and so on). The results returned in ''rval'' are with JSVAL_NULL, JS_TRUE (if we're only ''test''ing),
or a JSArray object containing the discovered result strings. If rval is an array, the 0-index value contains the results
of any substitutions that occurred.</dd>

<dt>JSObject * JS_NewRegExpObject(JSContext *cx, char *bytes, size_t length, uintN flags)</dt>
<dd>Already exists. Wonder why bytes is not const? --[[User:Crowder|Crowder]] 09:15, 31 August 2006 (PDT)</dd>

<dt>JSObject * JS_NewUCRegExpObject(JSContext *cx, jschar *chars, size_t length, uintN flags)</dt>
<dd>Already exists.</dd>

<dt>void JS_SetRegExpInput(JSContext *cx, JSString *input, JSBool multiline)</dt>
<dd>Already exists.</dd>

<dt>void JS_ClearRegExpStatics(JSContext *cx)</dt>
<dd>Already exists.</dd>

<dt>void JS_ClearRegExpRoots(JSContext *cx)</dt>
<dd>Already exists.</dd>

[[Category:SpiderMonkey]]

JavaScript:SpiderMonkey:RegExp API

2006-08-31T16:15:09Z

Crowder: Adding some junk that already exists. And some constness questions/changes

=JavaScript Regular Expression API=

The purpose of this addition to the JS API is to make ECMA-262 compliant regular expression APIs available to C/C++ users. As with other JS API routines, clients are required to provide a properly initialized execution context (JSContext), and the API has the potential to throw JS exceptions, just as a script might.

==Structures==
<dt>JSObject</dt>
<dd>Used to track a JSRegExp, the structure of which we do not expose publically.</dd>

==Routines==
<dt>JSObject * JS_NewRegExpObjectFromString(JSContext *cx, const? JSString *str, uintN flags, JSBool flat)</dt>
<dd>Used to build a JSObject which holds a precompiled regular expression to be used in future routines. I also am not entirely clear on what "flat" does, can someone explain it to me? --[[User:Crowder|Crowder]] 09:15, 31 August 2006 (PDT)</dd>

<dt>JSObject * JS_CloneRegExpObject(JSContext *cx, JSObject *obj, JSObject *parent)</dt>
<dd>Do we need this?</dd>

<dt>void JS_DestroyRegExpObject(JSContext *cx, JSObject *obj)</dt>
<dd>Used to destroy the object built with JS_NewRegExpObject.</dd>

<dt>JSBool JS_ExecuteRegExp(JSContext *cx, JSObject *re, const? JSString *input, JSBool test, jsval *rval)</dt>
<dd>Executes the expression compiled into ''re'' against ''input''. ''test'' is a flag which dictates whether or not
we're actually interested in results beyond whether the expression matches or not (ie., for parenthesized parts of the
expression, $1, $2, and so on). The results returned in ''rval'' are with JSVAL_NULL, JS_TRUE (if we're only ''test''ing),
or a JSArray object containing the discovered result strings. If rval is an array, the 0-index value contains the results
of any substitutions that occurred.</dd>

<dt>JSObject * JS_NewRegExpObject(JSContext *cx, char *bytes, size_t length, uintN flags)</dt>
<dd>Already exists. Wonder why bytes is not const? --[[User:Crowder|Crowder]] 09:15, 31 August 2006 (PDT)</dd>

<dt>JSObject * JS_NewUCRegExpObject(JSContext *cx, jschar *chars, size_t length, uintN flags)</dt>
<dd>Already exists.</dd>

<dt>void JS_SetRegExpInput(JSContext *cx, JSString *input, JSBool multiline)</dt>
<dd>Already exists.</dd>

<dt>void JS_ClearRegExpStatics(JSContext *cx)</dt>
<dd>Already exists.</dd>

<dt>void JS_ClearRegExpRoots(JSContext *cx)</dt>
<dd>Already exists.</dd>

[[Category:SpiderMonkey]]

JavaScript:SpiderMonkey:JS Tests

2006-08-31T05:37:26Z

Crowder: Couple more rules

== Rules for Writing JavaScript Test Cases ==

* Use reportCompare() to report success/failure! (except for e4x cases)
* If your test will always throw an uncaught exception then you should name it with a suffix -n; it is always preferable to catch and handle exceptions directly.
* Don't use print(), use printStatus() or writeLineToLog(), etc.
* The tests will also be run in the browser in addition to the shell. If you use shell only features, detect that and let the browser report success.
* Do the converse, if you have a browser-only test.
* Each sub-suite has its own style -- use the template.js in that sub-suite's directory to as a starting-point for new tests.
* Each new sub-suite directory must have an empty shell.js and browser.js

When in doubt about this, ask for help.

JavaScript:SpiderMonkey:JS Tests

2006-08-31T05:31:24Z

Crowder: Compiled by crowder from an IRC convo with bclary

== Rules for Writing JavaScript Test Cases ==

* Use reportCompare() to report success/failure!
* If your test will always throw an uncaught exception then you should name it with a suffix -n; it is always preferable to catch and handle exceptions directly.
* Don't use print(), use printStatus() or writeLineToLog(), etc.
* The tests will also be run in the browser in addition to the shell. If you use shell only features, detect that and let the browser report success.
* Do the converse, if you have a browser-only test.

JavaScript:Home Page

2006-08-31T05:24:39Z

Crowder:

== Intro ==

JavaScript language and implementation plans go here. For background, see:

* JS items in [http://weblogs.mozillazine.org/roadmap/ Brendan's roadmap blog].
* The [http://www.mozilla.org/js/language mozilla.org website's JS language] page.
* [http://developer.mozilla.org/en/docs/JavaScript JS pages] at the [http://developer.mozilla.org Mozilla Developer Center].

== New Projects ==

* Narcissus ([http://lxr.mozilla.org/mozilla/source/js/narcissus source code]).
* A [[JavaScript:SpiderMonkey:Parser API|new SpiderMonkey API]] for building and inspecting parse trees.
* [[JavaScript:SpiderMonkey:Context Threading|Context-thread]] the SpiderMonkey interpreter.
* Make mostly-dense arrays [https://bugzilla.mozilla.org/show_bug.cgi?id=322889 blazingly fast].
* [[JavaScript:SpiderMonkey:RegExp API|Expose ECMA 262 Regular Expression API]] to C/C++ clients.

== Coding Style Guidelines ==

* [[JavaScript:SpiderMonkey:Coding_Style|SpiderMonkey]]
* How to write [[JavaScript:SpiderMonkey:JS_Tests|unit tests]] for use by jsDriver.pl.

== References ==
* "[http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html Garbage Collection: algorithms for automatic dynamic memory management]", by Richard Jones, is a comprehensive reference book about different garbage collection algorithms.
* Also Richard Jones's webpage has a collection of [http://www.cs.kent.ac.uk/people/staff/rej/gc.html references].
* Several conferences where most memory management papers go: [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES858&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574 ISMM], [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES363&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574 PLDI], [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES318&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574 OOPSLA], [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES11259&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574, VEE].

JavaScript:Home Page

2006-08-31T05:23:54Z

Crowder: Adding a link to a page describing the process for writing JS unit tests

== Intro ==

JavaScript language and implementation plans go here. For background, see:

* JS items in [http://weblogs.mozillazine.org/roadmap/ Brendan's roadmap blog].
* The [http://www.mozilla.org/js/language mozilla.org website's JS language] page.
* [http://developer.mozilla.org/en/docs/JavaScript JS pages] at the [http://developer.mozilla.org Mozilla Developer Center].

== New Projects ==

* Narcissus ([http://lxr.mozilla.org/mozilla/source/js/narcissus source code]).
* A [[JavaScript:SpiderMonkey:Parser API|new SpiderMonkey API]] for building and inspecting parse trees.
* [[JavaScript:SpiderMonkey:Context Threading|Context-thread]] the SpiderMonkey interpreter.
* Make mostly-dense arrays [https://bugzilla.mozilla.org/show_bug.cgi?id=322889 blazingly fast].
* [[JavaScript:SpiderMonkey:RegExp API|Expose ECMA 262 Regular Expression API]] to C/C++ clients.

== Coding Style Guidelines ==

* [[JavaScript:SpiderMonkey:Coding_Style|SpiderMonkey]]
* How to write [[JavaScript:SpiderMonkey:JS_Tests|unit tests]] for use by jsDriver.pl

== References ==
* "[http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html Garbage Collection: algorithms for automatic dynamic memory management]", by Richard Jones, is a comprehensive reference book about different garbage collection algorithms.
* Also Richard Jones's webpage has a collection of [http://www.cs.kent.ac.uk/people/staff/rej/gc.html references].
* Several conferences where most memory management papers go: [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES858&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574 ISMM], [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES363&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574 PLDI], [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES318&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574 OOPSLA], [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES11259&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574, VEE].

JavaScript:SpiderMonkey:RegExp API

2006-08-25T16:07:57Z

Crowder: Moving this here from MDC

JavaScript:Home Page

2006-08-25T16:07:03Z

Crowder: Adding page for JS RegExp API

== Intro ==

JavaScript language and implementation plans go here. For background, see:

* JS items in [http://weblogs.mozillazine.org/roadmap/ Brendan's roadmap blog].
* The [http://www.mozilla.org/js/language mozilla.org website's JS language] page.
* [http://developer.mozilla.org/en/docs/JavaScript JS pages] at the [http://developer.mozilla.org Mozilla Developer Center].

== New Projects ==

* Narcissus ([http://lxr.mozilla.org/mozilla/source/js/narcissus source code]).
* A [[JavaScript:SpiderMonkey:Parser API|new SpiderMonkey API]] for building and inspecting parse trees.
* [[JavaScript:SpiderMonkey:Context Threading|Context-thread]] the SpiderMonkey interpreter.
* Make mostly-dense arrays [https://bugzilla.mozilla.org/show_bug.cgi?id=322889 blazingly fast].
* [[JavaScript:SpiderMonkey:RegExp API|Expose ECMA 262 Regular Expression API]] to C/C++ clients.

== Coding Style Guidelines ==

* [[JavaScript:SpiderMonkey:Coding_Style|SpiderMonkey]]

== References ==
* "[http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html Garbage Collection: algorithms for automatic dynamic memory management]", by Richard Jones, is a comprehensive reference book about different garbage collection algorithms.
* Also Richard Jones's webpage has a collection of [http://www.cs.kent.ac.uk/people/staff/rej/gc.html references].
* Several conferences where most memory management papers go: [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES858&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574 ISMM], [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES363&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574 PLDI], [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES318&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574 OOPSLA], [http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES11259&coll=portal&dl=ACM&CFID=43281450&CFTOKEN=59448574, VEE].