Last Comment Bug 44075 - need to be attached to a WindowBrowserControlCanvas should not need to be attached to a Window
: need to be attached to a WindowBrowserControlCanvas should not need to be att...
Status: RESOLVED INCOMPLETE
[nsbeta3-]
:
Product: Core
Classification: Components
Component: Embedding: APIs (show other bugs)
: Trunk
: All All
: P3 enhancement with 2 votes (vote)
: ---
Assigned To: edburns
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-06-28 04:19 PDT by Nathan Kirkham
Modified: 2016-06-23 10:45 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase for this bug, untar into webclient and run runnv.bat (12.39 KB, application/octet-stream)
2000-08-04 14:17 PDT, edburns
no flags Details

Description Nathan Kirkham 2000-06-28 04:19:18 PDT
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)
> 
(edburns@acm.org 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] 2000-06-28 10:57:56 PDT
setting bug status to NEW
Comment 2 edburns 2000-06-28 14:28:48 PDT
a
Comment 3 edburns 2000-08-04 14:09:26 PDT
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 2000-08-04 14:17:30 PDT
Created attachment 12377 [details]
Testcase for this bug, untar into webclient and run runnv.bat
Comment 5 edburns 2000-08-04 14:18:11 PDT
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 2000-08-04 16:20:19 PDT
Added myself on CC.
Comment 7 Judson Valeski 2000-08-08 10:51:30 PDT
-> adam
Comment 8 Adam Lock 2000-08-10 06:22:14 PDT
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 2000-08-10 11:33:30 PDT
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 2000-08-11 05:19:16 PDT
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 2000-08-14 02:28:26 PDT
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 2000-08-14 10:30:32 PDT
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 2000-08-14 11:10:50 PDT
Will reassign.
Comment 14 edburns 2000-08-14 11:11:18 PDT
Reassign.
Comment 15 edburns 2000-08-24 18:20:07 PDT
a
Comment 16 lchiang 2000-09-26 14:52:13 PDT
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 2001-01-10 09:36:16 PST
Updating QA Contact
Comment 18 Michael Dunn 2001-04-18 10:22:57 PDT
Correction: Changing QA contact for the Embed API bugs to David Epstein.
Comment 19 Jeet Shahani 2001-08-06 11:24:13 PDT
Issue 82134 might also be related to this issue.
Comment 20 Sean Aitken 2005-07-30 08:48:14 PDT
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 2005-12-13 09:44:11 PST
add myself to CC
Comment 22 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2016-06-23 10:45:50 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.