Closed Bug 44075 Opened 24 years ago Closed 8 years ago

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

Categories

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

enhancement

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: nathan, Assigned: edburns)

Details

(Whiteboard: [nsbeta3-])

Attachments

(1 file)

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.
setting bug status to NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
a
Status: NEW → ASSIGNED
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.

Assignee: edburns → valeski
Status: ASSIGNED → NEW
Component: Java APIs to WebShell → Embedding APIs
QA Contact: geetha.vaidyanaathan → jrgm
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.
Added myself on CC.
-> adam
Assignee: valeski → adamlock
Keywords: embed, nsbeta3
Summary: BrowserControlCanvas should not need to be attached to a Window → ot need to be attached to a WindowBrowserControlCanvas should not need to be attached to a Window
Whiteboard: [nsbeta3+]
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?
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.
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.
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.
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.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Will reassign.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Reassign.
Assignee: adamlock → edburns
Status: REOPENED → NEW
a
Status: NEW → ASSIGNED
Summary: ot 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 attached to a Window
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.
Whiteboard: [nsbeta3+] → [nsbeta3-]
Updating QA Contact
QA Contact: jrgm → mdunn
Keywords: embed
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
Issue 82134 might also be related to this issue.
QA Contact: depstein → mdunn
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.
add myself to CC
QA Contact: dunn5557 → apis
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.