From MozillaWiki
Jump to: navigation, search

Christian Biesinger <>

random notes/things I intend to work on

unsorted list of things I intend to work on at some point; but for which I don't want to file a bug just yet (or assign the existing one to me)

port seamonkey to "new toolkit"/xulrunner

1. merge chrome://global/ changes between toolkits, to ensure not losing any patches

2. make xpfe/global's reference toolkit/content files

Notes for those tasks:

  • implement "new tab" button on tab bar using an overlay
  • "Redo" in ctxt menu of textboxes will be lost, probably not much of a loss
  • <wizard> can't include statusbars any more (this is a Good Thing) (added in bug 209550)
  • more...

3. replace xpfe/bootstrap with toolkit/xre issues:

  • splash screen (probably not as important)
  • existing profiles

--> this means xpfe/global as well as xpfe/bootstrap are obsolete and can removed.

4. build system changes to build toolkit/content directly, instead of xpfe/global

  • take care of l10n issues (dtd/properties are elsewhere in toolkit)

5. gradually switch more stuff to toolkit

  • DL Manager. At least backend, maybe frontend too
  • Wallet -> Satchel
  • more...

AxelHecht quotes Benjamin,

	bsmedberg	Pike: that would fall under "port seamonkey to toolkit"
	Pike	yes
	Pike	or "unfork chrome registry"?
	Pike	as a step in the port?
	bsmedberg	The problem is, that the toolkit chrome registry doesn't check localeVersion/skinVersion.
	bsmedberg	Compatibility is managed by the extension manager.
	bsmedberg	So you have to get the extension manager working at the same time.

This should probably go into a bugzilla somehow.

implement uploads for gnomevfs channels

todo: write documentation on necko's socket apis

nsISocketTransportService, etc. when will it connect. how to read. how to write. blocking/nonblocking.

Plugin Notes

various notes about plugin code.

Plugins tend to fail when the protocol can't be handled internally; but note: must not always fail (consider mms:// etc)

communicate info frames/content nodes via nsIContent::SetProperty

reconstruct frames via nsIPresShell::RecreateFramesFor

Where to do the check whether java is disabled? (Note: not needed. Even currently, objects without type attribute do not check the pref in plugin code. but OJI code checks the pref)

How to handle mms://? (Note: Current code handles that only if type is specified) Solution: pass it directly to plugin, like now.

What about stopped plugins?


  • Content code gets a new class nsObjectLoadingContent : public nsImageLoadingContent
  • that takes care of setting up a stream listener and finding out what type the content is
  • once it figures that out, it sets a property and asks the presshell to reconstruct frames
  • uses LoadImageWithChannel / nsIURIContentListener::DoContent / a new plugin function to load the content from the channel

need to make sure that subdocumentframe / imageframe don't make a new request for the content:

  • nsSubdocumentFrame: If content implements nsIFrameLoaderOwner, that's avoided. Get the docshell from the frameloader and GetInterface nsIURIContentListener; then use DoContent
  • nsImageFrame: ought to be fine (everything loaded in content anyway). call super::LoadImageWithChannel as needed.

Left: plugins. May be enough to have an nsIStreamListener* nsIObjectFrame::LoadPlugin(nsIChannel*), but maybe those should live more in content?

It may not be too hard to move nsPluginInstanceOwner to content. probably need to call SetWindow(null) when the frame goes away. will do in 2nd stage.

be sure to retest:

   // for a replaced object frame, clear our vertical alignment style info, see bug 36997
   nsStyleTextReset* text = NS_STATIC_CAST(nsStyleTextReset*,


  • Scriptability should not regress
  • Dynamic changes should work, to the main involved attributes
    • Hixie says only changes to data should trigger anything

std::nothrow support in compilers

Tested, and new (std::nothrow) works:

  • g++33 (GCC) 3.3.4 20040817 (Red Hat Linux 3.3.4-2)
  • g++ (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
  • g++4 (GCC) 4.0.0 20050406 (Red Hat 4.0.0-0.41.fc3)
  • MS Visual C++ 6

Tested, doesn't work:

Palm sync notes

Needs BUILD_PALMSYNC=1 and PALM_CDK_DIR=c:/PALMCDK403 env vars

Need CDK 4.0.3. (no plans/need to use CDK 6)

The CDK is free, but requires registration. or

Perhaps also useful - Building Palm OS Conduits with [CDK 4.0.3 and] VS 2005: (thanks Wayne)

BeOS GFX/Widget

Locking and updating the BView happens in GFX; it calls LockAndUpdateView for each drawing instruction. It is not sufficient to lock in widget before dispatching the paint event, because (I'm told) Gecko paints to more than one window. Additionally, locks should only exist for a short period.