r=gbarney
a=edburns
This checkin adds java.awt.event.MouseListener support to webclient for
mozilla. The following files are include in this checkin. "A" is new
file "M" is modified file.
A classes_spec/org/mozilla/webclient/WCMouseEvent.java
A classes_spec/org/mozilla/webclient/wrapper_native/WCMouseListenerImpl.java
A src_moz/DOMMouseListenerImpl.cpp
A src_moz/DOMMouseListenerImpl.h
A src_moz/dom_util.cpp
A src_moz/dom_util.h
M classes_spec/org/mozilla/webclient/EventRegistration.java
M classes_spec/org/mozilla/webclient/test/EMWindow.java
M classes_spec/org/mozilla/webclient/wrapper_native/EventRegistrationImpl.java
M classes_spec/org/mozilla/webclient/wrapper_native/NativeEventThread.java
M src_moz/DocumentLoaderObserverImpl.cpp
M src_moz/DocumentLoaderObserverImpl.h
M src_moz/EventRegistration.cpp
M src_moz/EventRegistration.h
M src_moz/Makefile.solaris
M src_moz/Makefile.win
M src_moz/NativeEventThread.cpp
M src_moz/NavigationImpl.cpp
M src_moz/RDFTreeNode.cpp
M src_moz/bal_util.cpp
M src_moz/jni_util.cpp
M src_moz/jni_util.h
M src_moz/jni_util_export.cpp
M src_moz/jni_util_export.h
A classes_spec/org/mozilla/webclient/WCMouseEvent.java
* <P> This java.awt.event.MouseEvent subclass allows the user to access the
* WebclientEvent. This eventData of this WebclientEvent, if non-null,
* is a java.util.Properties instance that contains information about
* this event. </P>
* <P>The following are some interesting keys:</P>
* <UL>
* <LI> href
* </LI>
* <LI> #text
* </LI>
* </UL>
A classes_spec/org/mozilla/webclient/wrapper_native/WCMouseListenerImpl.java
* This class wraps the user provided instance of
* java.awt.event.MouseListener so it can be installed as a
* WebclientEventListener. Note that we implement MouseListener so we
* can be detected by the webclient event system. We don't do anything
* with these methods here, though.
A src_moz/DOMMouseListenerImpl.cpp
A src_moz/DOMMouseListenerImpl.h
* This class is the shim between the mozilla listener event system for
* mouse events and the java MouseListener interface.
* For each of the Mouse* methods, we call the appropriate method in java.
* See the implementation of MouseOver for an example.
* For each mouseEvent, we create a Properties object containing
* information about the event. We use methods in dom_util to do this.
A src_moz/dom_util.cpp
A src_moz/dom_util.h
/**
* Methods to simplify webclient accessing the mozilla DOM.
*/
M classes_spec/org/mozilla/webclient/EventRegistration.java
Added support for java.awt.event.MouseListener
M classes_spec/org/mozilla/webclient/test/EMWindow.java
Implemented simle MouseListener
M classes_spec/org/mozilla/webclient/wrapper_native/EventRegistrationImpl.java
Added support for java.awt.event.MouseListener
M classes_spec/org/mozilla/webclient/wrapper_native/NativeEventThread.java
Added support for java.awt.event.MouseListener
M src_moz/DocumentLoaderObserverImpl.cpp
M src_moz/DocumentLoaderObserverImpl.h
* We define a local IID to allow the addDocumentLoadListener and
* addMouseListener functions in EventRegistration.{h,cpp} to
* interrogate the currently installed DocumentLoaderObserver instance
* in mozilla.
*/
#define NS_IDOCLOADEROBSERVERIMPL_IID_STR "fdadb2e0-3028-11d4-8a96-0080c7b9c5ba"
#define NS_IDOCLOADEROBSERVERIMPL_IID {0xfdadb2e0, 0x3028, 0x11d4, { 0x8a, 0x96, 0x00, 0x80, 0xc7, 0xb9, 0xc5, 0xba }}
/**
* This class is the shim between the mozilla listener event system for
* document load events and the java DocumentLoadListener interface.
* For each of the On* methods, we call the appropriate method in java.
* See the implementation of OnEndDocumentLoad for an example.
* A DocumentLoaderObserverImpl instance has a "jobject target", which
* is the Java object that should ultimately receive the events. This
* target will be null if the user just wants to listen for mouse
* events. It willl be non-null if the user wants to listen for
* DocumentLoad events.
* It also hosts a nsIDOMMouseListener instance, which piggybacks on the
* nsIDocumentLoaderObserver instance.
M src_moz/EventRegistration.cpp
M src_moz/EventRegistration.h
Add support for MouseListener
M src_moz/Makefile.win
Added classes for MouseListener and Dom access
M src_moz/NativeEventThread.cpp
Added support for MouseListener
M src_moz/NavigationImpl.cpp
Added call to ReleaseStringChars for bal case.
M src_moz/RDFTreeNode.cpp
Added call to ReleaseStringChars for bal case.
M src_moz/bal_util.cpp
Added #include "wchar.h" so this file compiles on Solaris.
M src_moz/jni_util.cpp
Added implementations for util_CreatePropertiesObject,
util_DestroyPropertiesObject and util_StoreIntoPropertiesObject.
M src_moz/jni_util.h
/**
* A JNI wrapper to create a java.util.Properties object, or the
* equivalent object in the BAL case.
*/
jobject util_CreatePropertiesObject(JNIEnv *env, jobject reserved_NotUsed);
/**
* A JNI wrapper to destroy the object from CreatePropertiesObject
*/
void util_DestroyPropertiesObject(JNIEnv *env, jobject propertiesObject,
jobject reserved_NotUsed);
/**
* A JNI wrapper for storing a name/value pair into the Properties
* object created by CreatePropertiesObject
*/
void util_StoreIntoPropertiesObject(JNIEnv *env, jobject propertiesObject,
jobject name, jobject value);
M src_moz/jni_util_export.cpp
M src_moz/jni_util_export.h
Added functions for allowing the BAL user to specify functions for
{creating, destroying, setting values into} properties objects.
bug: pressing BACK hangs webclient
Files touched
File: DocumentLoadEvent.java Status: Locally Modified
Made the constants final so they can be used in a
switch statement
File: EMWindow.java Status: Locally Modified
Modified eventDispatched() so it doesn't call any webclient
events. This was causing the hang. Took advantage of
the newly implemented ability to pass a string from the
mozilla event handler into java.
File: DocumentLoaderObserverImpl.cpp Status: Locally Modified
Create a jstring from the url in the OnStartDocumentLoad event.
Pass it on to java.
File: jni_util.cpp Status: Locally Modified
Wrapped JNU_GetEnv in BAL stuff so it works from Star.
File: WebclinetEventListener.java Status: Locally Modified
Added comment to eventDispatched.
r=shaver
a=edburns
Native code changes: This fix eradicates all
occurrences of the following symbols
nsComponentManager nsServiceManeger
And replaces them with their nsI counterparts.
The following ns* classes still are used in
webclient, and no plans exist to replace them
with nsI counterparts: nsresult nsCOMPtr
nsCRT nsnull * nsServiceManager occurrences
were replaced with do_GetService(), using a
PROGID. * nsComponentManager occurrences were replaced with a call on the global class gComponentManager, declared in the new file ns_globals.h, and defined in WrapperFactoryImpl.cpp. ns_globals.h is included in jni_util.h. See the attachment to bug 33099 for ns_globals.h * Added deallocation code to WindowControlImpl.cpp nativeTerminate. I know it doesn't do much, but it's correct. Java code changes: * Added static method BrowserControlFactory.appTerminate(). This method simply calls the existing BrowserControlImpl.appTerminate(), which calls WrapperFactoryImpl.cpp nativeTerminate(). BrowserControlFactory.appTerminate() is called from EmbeddedMozilla's WindowListener, which gets fired when the user signals she wants the app to terminate.
r=ashuk
a=edburns
Add an "eventData" argument to WebclientEvent and subclasses.
This argument is sub-event specific. For example, when a user
gets a DocumentLoadEvent, with an event type of
STATUS_URL_LOAD, the eventData is a String containing
the status string from the browser.
Added support for doing this in a BAL context.
r=ashuk
a=edburns
Add an "eventData" argument to WebclientEvent and subclasses.
This argument is sub-event specific. For example, when a user
gets a DocumentLoadEvent, with an event type of
STATUS_URL_LOAD, the eventData is a String containing
the status string from the browser.
Added ability to allow Native webclient client to populate
the listener class hash table and provide an InstanceOf function.
This enables listeners to work for the future.
This change replaces all printfs in src_moz with calls to PR_LOG. No
printfs should appear in src_moz anymore.
You won't see any console output from native code unless you define
NSPR_LOG_MODULES=webclient:3
in your environment. Furthermore, if you want PR_LOG statements in
webclient to go to a file instead, define
WEBCLIENT_LOG_FILE=C:\VALIDDIR\filename.txt
in your environment. This file will get created fresh each time, since
PR_LOG uses fopen(filename, "w").
New Files:
I've created ns_globals.h, included from jni_util.h. ns_globals.h holds
an extern * to a struct used in the PR_LOG calls.
Significant changes:
WrapperFactoryImpl.cpp
nativeAppInitialize(){
Added:
#if DEBUG_RAPTOR_CANVAS
prLogModuleInfo = PR_NewLogModule("webclient");
const char *webclientLogFile = PR_GetEnv("WEBCLIENT_LOG_FILE");
if (nsnull != webclientLogFile) {
PR_SetLogFile(webclientLogFile);
// If this fails, it just goes to stdout/stderr
}
#endif
}
All the other files in this checkin follow the this pattern:
Before checkin:
printf("InitMozillaStuff(%lx): Create the Event Queue for the UI thread...\n",
initContext);
After checkin:
if (prLogModuleInfo) {
PR_LOG(prLogModuleInfo, 3,
("InitMozillaStuff(%lx): Create the Event Queue for the UI thread...\n",
initContext));
}
See http://lxr.mozilla.org/mozilla/source/nsprpub/pr/include/prlog.h#190
for the definition of PR_LOG
NativeEventThread's run() method's infinite loop was implemented. The
loop looks like this:
while (null != this.browserControlCanvas) {
synchronized (this.browserControlCanvas.getTreeLock()) {
nativeProcessEvents(nativeWebShell);
if (null != listenersToAdd && !listenersToAdd.isEmpty()) {
tempEnum = listenersToAdd.elements();
while (tempEnum.hasMoreElements()) {
nativeAddListener(nativeWebShell,
(WebclientEventListener)
tempEnum.nextElement());
}
listenersToAdd.clear();
}
}
}
The problem I was observing was that
nativeProcessEvents(nativeWebShell) would crash due to the fact that
the nativeWebShell, which is actually an WebShellInitContext instance,
had been de-allocated. This de-allocation happens as a result of the
WindowControlImpl.delete() method, which looks like this:
public void delete()
{
Assert.assert(null != eventThread, "eventThread shouldn't be null at delete time");
eventThread.delete();
eventThread = null;
nativeDestroyInitContext(nativeWebShell);
nativeWebShell = -1;
}
nativeDestroyInitContext de-allocates the WebShellInitContextInstance.
You can see that the first thing done is to delete the eventThread().
NativeEventThread.delete() looks like this:
public void delete()
{
// setting this to null causes the run thread to exit
synchronized(this.browserControlCanvas.getTreeLock()) {
browserControlCanvas = null;
}
...
}
If you compare NativeEventThread.delete() with the infinite loop in
NativeEventThread.run(), you'll see that the fact that they both
synchronize on the same object doesn't protect us from the following
case:
NativeEventThread: The infinite loop checks to see if the
browserControlCanvas is null, then does synchronize on
browserControlCanvas.getTreeLock(), then calls processNativeEvents().
meanwhile
WindowControlImpl thread: delete() calls NativeEventThread.delete(),
which does synchronize on browserControlCanvas.getTreeLock().
During NativeEventThread.delete(), synchronized section,
browserControlCanvas is set to null.
NativeEventThread: because the check for null browserControlCanvas
occurrs outside of the synchronized block, it's not recheked, and
thus, the event loop continues to process when it shouldn't.
The fix is to change the event loop to look like this:
while (true) {
synchronized (this.browserControlCanvas.getTreeLock()) {
// this has to be inside the synchronized block!
if (null == this.browserControlCanvas) {
return;
}
nativeProcessEvents(nativeWebShell);
if (null != listenersToAdd && !listenersToAdd.isEmpty()) {
tempEnum = listenersToAdd.elements();
while (tempEnum.hasMoreElements()) {
nativeAddListener(nativeWebShell,
(WebclientEventListener)
tempEnum.nextElement());
}
listenersToAdd.clear();
}
}
}
- reduces a number of c++<--> java calls
- added NULL checks
- made DOMAccessor to be secure
- added util and tests packages
- wrote test applets
- updated README
a=edburns
bug=32011
This change enables the current webclient API to be called from native
code.
It adds makefile and conditional compilation logic.
If the user defines BAL_INTERFACE in their environment before building
webclient, -DBAL_INTERFACE is added to LCFLAGS. This causes code in
jni_util_export.cpp to behave differently due to the conditional
compilation logic.
I've broken out the 8 functions that are necessary to call into the
Webclient JNI methods into jni_util_export.{h,cpp}.
I've created a new pair of files, bal_util.{h,cpp} that contain function
declarations and definitions that are used when src_moz is built with
BAL_INTERFACE. bal_util.obj is not built, nor added to webclient.dll if
building without BAL_INTERFACE.
See the page
http://www.mozilla.org/projects/blackwood/webclient/design/uno-transition.html
for a design document description of these changes.
r=ashuk
a=edburns
This set of changes replaces all occurrences of
env->Func(args...)
with
::util_Func(env, args...)
Except of course, for the implementations of the above mentioned
::util_Func() functions.
This is done to allow the JNI functions to be called from a non JNI
context, such as UNO.
also modifies EmbeddedMozilla so this code is exercised.
I have changed EmbeddedMozilla to be a stub-like class that simply
displays a Frame with a single Button, titled "New Window". Pressing
this button causes an EMWindow to be created and displayed. EMWindow is
basically the former EmbeddedMozilla renamed, with modifications to the
WindowListener implementation to call the BrowserControl deallocation
method.
I've added a delete() method to ImplObect:
* I know Java has automatic garbage collection and all, but explicitly
* adding a delete method helps the gc algorithm out. <P>
* Subclasses should override this and call super.delete() at the end of
* their overridden delete() method.
* @see org.mozilla.webclient.wrapper_native.ImplObjectNative#delete
and ImplObjectNative:
* Note how we call super.delete() at the end. THIS IS VERY IMPORTANT. <P>
* Also, note how we don't de-allocate nativeWebShell, that is done in
* the class that owns the nativeWebShell reference, WindowControlImpl.
* ImplObjectNative subclasses that further override delete() are <P>
<CODE><PRE>
BookmarksImpl.java
EventRegistrationImpl.java
NativeEventThread.java
WindowControlImpl.java
</PRE><CODE> <P>
* All other ImplObject subclasses don't have any local Ivars and thus
* don't need to override delete().
I've added a delete() method to BrowserControlImpl:
* Called from BrowserControlFactory.deleteBrowserControl() <P>
* The order of deletion of objects is very important! <P>
* We don't allow deletion if the Canvas is showing. <P>
In BrowserControlImpl's delete(), the important delete()s is for
WindowControlImpl:
* First, we delete our eventThread, which causes the eventThread to
* stop running. Then we call nativeDestroyInitContext(), which
* deallocates native resources for this window.
As stated above, NativeEventThread.delete() is called:
* This is a very delicate method, and possibly subject to race
* condition problems. To combat this, our first step is to set our
* browserControlCanvas to null, within a synchronized block which
* synchronizes on the same object used in the run() method's event
* loop. By setting the browserControlCanvas ivar to null, we cause the
* run method to return.
After all of this deleting, we return from
BrowserControlFactory.delete().
Added new api test entries in BWTestClass files
Added UNSUPPORTED methods in BWBaseTest/TestLoader
Update DoucmentImpl accroding to java DOM version.
Did correct check for retrun values in ElementImpl_removeAttribute_String_1.java
ElementImpl_setAttributeNode_Attr_1.java NamedNodeMapImpl_setNamedItem_Node_1.java
Methods of PlugletTagInfo and PlugletTagInfo2 doesn't allow access to pluglet parameters,
PlugletTagInfo2 getAttribute doesn't work properly.
Reviewed by idk@eng.sun.com
a=edburns
bug=20659
Make BrowserControl vend a Canvas instead of
BrowserControlCanvas vending a BrowserControl.
This change has nothing to do with mozilla. It's pure java.
Handle Unicode string correctly in javaDOMEventsGlobals.cpp
18072 r=akhil.arora@sun.com fix=Igor Nekrestyanov <nis@sparc.spb.su>
Sync with changes in Mozilla's DOM Event interfaces
Cosmetic changes to remove warnings generated by Visual C++ compiler
Do not link with unneccessary library raptorgfx in makefile.win
Use JAVAHOME to point to JDK instead of hardcoding the path
