44075 - need to be attached to a WindowBrowserControlCanvas should not need to be attached to a Window

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: APIs, enhancement, P3)

Description

[Nathan Kirkham]

Currently BrowserControlCanvas needs to be attached to a window before it is 
usable.
(From a newgroup thread)
> > Does a BrowserControlCanvas have to be attached
> > to a Window to work or can it just be created
> > and used without any visual parent.  (IE - Yes
> > it does otherwise a crash occurs)
> 
([e-mail] wrote:)
> Currently much work happens on
> BrowserControlCanvas.addNotify(), so yes it does
> require to be added.  I think this is a bug.  Can
> you file it in bugzilla category "Java APIS to
> WebShell"?

It should be possible to create the object and then use it without any visual 
component. 

Reproducible: Always

Currently the specification doesn't cover this issue at a all.

Comment 1

[Asa Dotzler [:asa]]

setting bug status to NEW

Comment 2

[edburns]

a

Comment 3

[edburns]

The reason for this bug is that we need the parent HWND to properly initialize
the underlying mozilla browser implementation.  I tried to do it without
initializing the underlying mozilla browser implementation, but I get a
assertion from mozilla-land:

Here's the stack trace:

NTDLL! 77f76148()
nsDebug::Assertion(const char * 0x061c3530, const char * 0x061c34f8, const char
* 0x061c34b4, int 514) line 242 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x061c3530, const char * 0x061c34f8, const
char * 0x061c34b4, int 514) line 300 + 21 bytes
nsWebBrowser::Create(nsWebBrowser * const 0x060a2e10) line 514 + 71 bytes
InitMozillaStuff(WebShellInitContext * 0x05ae4230) line 632 + 35 bytes
Java_org_mozilla_webclient_wrapper_1native_NativeEventThread_nativeInitialize
(JNIEnv_ * 0x00884e60, _jobject * 0x05cef984, long 95306288) line 203 + 9 bytes
JVM! 504a2d7c()
JVM! 5049a397()
NTDLL! 77f76148()
nsDebug::Assertion(const char * 0x061c3530, const char * 0x061c34f8, const char
* 0x061c34b4, int 514) line 242 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x061c3530, const char * 0x061c34f8, const
char * 0x061c34b4, int 514) line 300 + 21 bytes
nsWebBrowser::Create(nsWebBrowser * const 0x060a2e10) line 514 + 71 bytes
InitMozillaStuff(WebShellInitContext * 0x05ae4230) line 632 + 35 bytes
Java_org_mozilla_webclient_wrapper_1native_NativeEventThread_nativeInitialize
(JNIEnv_ * 0x00884e60, _jobject * 0x05cef984, long 95306288) line 203 + 9 bytes
JVM! 504a2d7c()
JVM! 5049a397()

I'm going to change this to the embedding component.

Comment 4

[edburns]

Attachment: Testcase for this bug, untar into webclient and run runnv.bat

Comment 5

[edburns]

Investigated the cause.  While webclient does require a canvas it
    could be made to not rely on it with little modification.  However,
    the mozilla embedding api requires the parent hwnd.  Reassigning for
    investatigation.

    Also will post my testcase.

Comment 6

[edburns]

Added myself on CC.

Comment 7

[Judson Valeski]

-> adam

Comment 8

[Adam Lock]

Is your problem that you can't get an HWND from Java, or that you want to use 
the webbrowser object *without* an HWND? If it's the latter, then what are you 
trying to accomplish?

Comment 9

[edburns]

It's the latter (use embedding without HWND), and I'll leave it up to the
reporter to say what they're trying to accomplish.  One possible use case of
"headless" functionality would be a webcrawler app that wishes to use the DOM.

Comment 10

[Adam Lock]

If this is the intention, then I'm tempted to reject this bug. The webbrowser 
object is designed to live in a window and to show web pages.

Of course Java might allow you to create the webbrowser in an invisible window, 
or one off-screen. That would probably do the trick.

Comment 11

[Nathan Kirkham]

One example is printing on the server when you don't want any visuals.  For 
example generating invoices and quotes as HTML, we then use the server to do the 
printing.
If it can be attached to a window that is never visible then that is acceptable.
Part of my thinking when I reported this bug is that there is nothing in the 
documentation or code to tell the user what the requirements are to using the 
browser.
The wrapper should at least have a clear warning when the browser is used 
incorrectly.
Perhaps an IllegalStateException with an approprate message whenever a method is 
called on a browser not attached to a window first.  I would certainly not 
expect any mozilla side exceptions such as the one shown to be thrown.

Comment 12

[Adam Lock]

I'm marking this bug as INVALID since I think you can already do what you want 
to do - make the webbrowser's parent window or offscreen and you won't see it. 
Feel free to reopen if that strategy doesn't work.

Comment 13

[edburns]

Will reassign.

Comment 14

[edburns]

Reassign.

Comment 15

[edburns]

a

Comment 16

[lchiang]

per email with Jud, changing nsbeta3+ to nsbeta3- on all "embed" keyword bugs
since embedding changes will not be made in the mn6 branch. If you feel this bug
fix needs to go into mn6 branch, please list the reasons/user impact/risk and
nominate for rtm. Thanks.

Comment 17

[Paul Wyskoczka]

Updating QA Contact

Comment 18

[Michael Dunn]

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Comment 19

[Jeet Shahani]

Issue 82134 might also be related to this issue.

Comment 20

[Sean Aitken]

A perfect example of how this could be useful is in the design of an automated
web data analysis package.  In this case, it makes sense to manupulate and work
against a DOM that is in memory rather than depend on a client raster device.

Comment 21

[Valerio Schiavoni]

add myself to CC

Comment 22

[Benjamin Smedberg]

Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.