Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
GeneralPortable MacsHardwareNetworking
Applications
Mac ApplicationsEudoraFirefox / MozillaInternet ExplorerOutlook ExpressMS OfficeEntourageExcelPowerPointWordVirtual PCMedia PlayerOther MS Products
Programming
Mac ProgrammingCodeWarriorPerl
Country Specific
Australian Mac GroupUK Mac Group

Mac Forum / Applications / Firefox / Mozilla / June 2007



Tip: Looking for answers? Try searching our database.

Webclient Mac OS X: no painting

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
edburns - 05 Jun 2007 16:27 GMT
Hello,

I am taking another crack at getting webclient (embed mozilla into
Java)
working on Mac OS X.  I had to make a bunch of changes to
widget/src/mac/nsMacResources to enable loading the libwidget.rsrc
file,
which I'll file in a separate bug.  But even with that, I still cannot
get the darn window to show up.

I am fairly certain that I am correctly hooking the browser window
into
the Java window hierarchy.  Here are some facts to support this claim.

* nsWebBrowser::InitWindow() is returning NS_OK.

* nsWebBrowser::EnsureTopLevelWidget() is returning NS_OK.

* nsMacWindow::StandardCreate() is returning NS_OK.

Here's the way it works.  I have a java.awt.Canvas subclass that has
an
addNotify() method which dives down to the native level and gets the
NSView, gets the NSWindow from the NSView, then gets the windowRef
from
the NSWindow.  This gives me a Mac OS X WindowPtr reference, which is
eventually passed to nsWebBrowser::InitWindow(), which returns NS_OK,
as
stated previously.

I do not override any other java.awt.Canvas methods other than
addNotify().  This approach works fine in Windows.

I'm finding that nsMacWindow::OnPaint() is never getting called, nor
is
nsRegionMac::nsRegionMac().  I think this is my problem.

When debugging firefox on Mac OS X, I find these methods *do* get
called:

#0  nsMacWindow::OnPaint
#1  0x07791640 in nsWindow::UpdateWidget
#2  0x07790860 in nsWindow::PaintUpdateRectProc
#3  0x07791048 in nsWindow::HandleUpdateEvent
#4  0x077905b4 in nsWindow::Update
#5  0x0777a5f0 in nsMacWindow::Update
#6  0x07776870 in nsMacWindow::WindowEventHandler
#7  0x9329a934 in DispatchEventToHandlers
#8  0x9329a08c in SendEventToEventTargetInternal
#9  0x93299f08 in SendEventToEventTargetWithOptions
#10 0x9336d5a4 in HandleWindowEvent
#11 0x932a1234 in ToolboxEventDispatcherHandler
#12 0x9329ab84 in DispatchEventToHandlers
#13 0x9329a08c in SendEventToEventTargetInternal
#14 0x932a0e90 in SendEventToEventTarget
#15 0x932e1c04 in ToolboxEventDispatcher
#16 0x93380a04 in TryEventDispatcher
#17 0x9338065c in GetOrPeekEvent
#18 0x93380398 in GetNextEventMatchingMask
#19 0x93380238 in WNEInternal
#20 0x9338018c in WaitNextEvent
#21 0x07770e30 in nsMacMessagePump::GetEvent
#22 0x07770c8c in nsMacMessagePump::DoMessagePump
#23 0x0775d5c0 in nsAppShell::Run
#24 0x081c5090 in nsAppStartup::Run
#25 0x0000d430 in XRE_main
#26 0x00002f58 in main

#0  nsRegionMac::nsRegionMac
#1  0x0a239054 in nsRegionMac::nsRegionMac
#2  0x0a2332e4 in nsRegionMacConstructor
#3  0x0100f2c8 in nsGenericFactory::CreateInstance
#4  0x0bc76c0c in CallCreateInstance<nsIRegion>
#5  0x0b9ab140 in nsViewManager::CreateRegion
#6  0x0b9afcf0 in nsViewManager::DispatchEvent
#7  0x0b9a453c in HandleEvent
#8  0x07791cbc in nsWindow::DispatchEvent
#9  0x07791e20 in nsWindow::DispatchWindowEvent
#10 0x07791678 in nsWindow::UpdateWidget
#11 0x07791794 in nsWindow::UpdateWidget
#12 0x07790860 in nsWindow::PaintUpdateRectProc
#13 0x07791048 in nsWindow::HandleUpdateEvent
#14 0x077905b4 in nsWindow::Update
#15 0x0777a5f0 in nsMacWindow::Update
#16 0x07776870 in nsMacWindow::WindowEventHandler
#17 0x9329a934 in DispatchEventToHandlers
#18 0x9329a08c in SendEventToEventTargetInternal
#19 0x93299f08 in SendEventToEventTargetWithOptions
#20 0x9336d5a4 in HandleWindowEvent
#21 0x932a1234 in ToolboxEventDispatcherHandler
#22 0x9329ab84 in DispatchEventToHandlers
#23 0x9329a08c in SendEventToEventTargetInternal
#24 0x932a0e90 in SendEventToEventTarget
#25 0x932e1c04 in ToolboxEventDispatcher
#26 0x93380a04 in TryEventDispatcher
#27 0x9338065c in GetOrPeekEvent
#28 0x93380398 in GetNextEventMatchingMask
#29 0x93380238 in WNEInternal
#30 0x9338018c in WaitNextEvent
#31 0x07770e30 in nsMacMessagePump::GetEvent
#32 0x07770c8c in nsMacMessagePump::DoMessagePump
#33 0x0775d5c0 in nsAppShell::Run
#34 0x081c5090 in nsAppStartup::Run
#35 0x0000d430 in XRE_main
#36 0x00002f58 in main

Why is my browser not painting in Mac OS X?

Any help would be greatly appreciated.

Ed
Javier Pedemonte - 05 Jun 2007 17:25 GMT
> Here's the way it works.  I have a java.awt.Canvas subclass that has
> an
[quoted text clipped - 5 lines]
> as
> stated previously.

Embedding with Carbon should be doable.

The problem you have is that you are getting the underlying window
handle from a java.awt.Canvas, which returns an NSView, which is in
compositing mode, which means none of the drawing/updating methods are
called when using XULRunner with Carbon widgets.

I already went through this, and it is all explained in this Eclipse
bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=154597.

The short version is that Mozilla with Carbon widgets depends on the
kEventWindowUpdate event to draw, but that event is never sent when a
window is in compositing mode.  Mozilla with Cocoa widgets properly
handles compositing mode.

So you have several options:
1) Get a handle that represents a window with compositing mode disabled.
    * I don't think this is possible.  Java always uses compositing
      mode for its windows.
2) Develop a shim that receives kEventControlDraw (used during
HIView/NSView drawing) events and maps it to the
kEventWindowUpdate/kEventWindowDraw events that the Mozilla Carbon code
expects.
    * Not sure if this is even doable, but it would probably be
      difficult.
3) Use Mozilla with Cocoa widgets.

javier pedemonte
edburns - 10 Jun 2007 17:42 GMT
> 3) Use Mozilla with Cocoa widgets.

Thanks,

Yes, I used this option and it worked.  There was only one additional
problem, which was pretty bothersome to surmount.  I was getting a ton
of thread safety assertions because my existing architecture did all
the mozilla interaction in a custom thread, rather than on the AWT
thread or the main thread.  In Mac, there's stuff that just has to
happen on the AppKit thread.  My solution was to do all the mozilla
interaction on the AppKit thread.  I had to do some JNI contortions to
get it working, but it works!

I'll produce a binary when I can get the fix for bug that I found:
https://bugzilla.mozilla.org/show_bug.cgi?id=383929 checked in.

Ed
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.