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

RESOLVED INCOMPLETE

Status

()

Core
Embedding: APIs
P3
enhancement
RESOLVED INCOMPLETE
17 years ago
10 months ago

People

(Reporter: Nathan Kirkham, Assigned: edburns)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-])

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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

17 years ago
setting bug status to NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

17 years ago
a
Status: NEW → ASSIGNED
(Assignee)

Comment 3

17 years ago
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
(Assignee)

Comment 4

17 years ago
Created attachment 12377 [details]
Testcase for this bug, untar into webclient and run runnv.bat
(Assignee)

Comment 5

17 years ago
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.
(Assignee)

Comment 6

17 years ago
Added myself on CC.

Comment 7

17 years ago
-> 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+]

Comment 8

17 years ago
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?
(Assignee)

Comment 9

17 years ago
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

17 years ago
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.
(Reporter)

Comment 11

17 years ago
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

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Assignee)

Comment 13

17 years ago
Will reassign.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 14

17 years ago
Reassign.
Assignee: adamlock → edburns
Status: REOPENED → NEW
(Assignee)

Comment 15

17 years ago
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

Comment 16

17 years ago
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-]

Comment 17

17 years ago
Updating QA Contact
QA Contact: jrgm → mdunn

Updated

16 years ago
Keywords: embed

Comment 18

16 years ago
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein

Comment 19

16 years ago
Issue 82134 might also be related to this issue.

Updated

14 years ago
QA Contact: depstein → mdunn

Comment 20

12 years ago
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

12 years ago
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
Last Resolved: 17 years ago10 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.