Christian Biesinger <mailto:firstname.lastname@example.org>
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 jar.mn 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)
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
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.
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*, mStyleContext->GetUniqueStyleData(eStyleStruct_TextReset)); text->mVerticalAlign.SetNormalValue();
- Scriptability should not regress
- Dynamic changes should work, to the main involved attributes
- Hixie says only changes to
datashould trigger anything
- Hixie says only changes to
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. http://www.accessdevnet.com/index.php?option=com_docman&task=cat_view&gid=69&Itemid=33 or https://www.developerpavilion.com/palmos/page.asp?page_id=365&tool_id=14
Perhaps also useful - Building Palm OS Conduits with [CDK 4.0.3 and] VS 2005: http://tomfrauenhofer.com/wordpress/?p=4 (thanks Wayne)
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.