Bug 83731 - (javadoc update) WindowEvent location and size fields are in terms of shell size, not browser control size
Summary: (javadoc update) WindowEvent location and size fields are in terms of shell s...
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Christophe Cornu CLA
QA Contact:
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2005-01-26 12:49 EST by Nick Edgar CLA
Modified: 2005-04-08 16:10 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Edgar CLA 2005-01-26 12:49:03 EST
build I20050118

The location and size fields in WindowEvent talk about the desired location and
size of the shell containing the Browser control, not the desired location and
size of the Browser control itself.

If the Browser control is inside a shell with other controls and/or trim, it may
not be large enough to show the desired content, and may not be aligned as desired.

Can the spec for these be clarified?  Or does it really not matter what location
and size the Browser control itself has?
Comment 1 Christophe Cornu CLA 2005-01-26 19:01:45 EST
The javadoc for the VisibilityWindowListener.show is hopefully more explicit - 
or do you want us to add more to it?

<li>(in) location the requested location for the <code>Shell</code> 
hosting the browser. It is <code>null</code> if no location is set. 
<li>(in) size the requested size for the <code>Browser</code>.
The client area of the <code>Shell</code> hosting the
<code>Browser</code> should be large enough to accomodate that size.


Nick: most of the time the size is only set by popups with no style of any 
kind (no menubar, no addressbar ...). It is now considered bad javascript 
practice to request a specific size/location so these are not too frequent - 
except for popups that usually people want to filter. Even native browsers 
take some liberty with these hints. e.g. Safari does not show status bar by 
default and the menubar is always visible at the top most part of the screen.
Comment 2 Nick Edgar CLA 2005-01-27 10:09:34 EST
Thanks for clarifying.  I had missed both the VisibilityWindowListener, and the
Javadoc specifying which WindowEvent fields are applicable.  The existing
Javadoc is quite clear, I just hadn't read it thoroughly.

It might be good to describe the overall flow of control in Browser's Javadoc,
with a brief description of the responsibilities of the different listeners, and
refer to that from the various listeners (in addition to the existing @see tags).

From the existing Javadoc, it's unclear to me whether the OpenWindowListener
should open the shell, or just create it and wait for
VisibilityWindowListener.show to open the shell.
Comment 3 Nick Edgar CLA 2005-01-27 10:11:26 EST
There seems to be an inconsistency in how the size is described in
VisibilityWindowListener.show and WindowEvent.size.  The latter says it's the
shell size, not the Brower size.
Comment 4 Christophe Cornu CLA 2005-01-27 11:09:27 EST
Regarding comment 3: corrected javadoc for WindowEvent

Regarding comment 2: WindowEvent javadoc contains a short example illustrating 
common use. Not currently sure if we want to be more verbose and write down 
the sequence of events as they commonly occur (is there any similar javadoc in 
Eclipse or elsewhere?).
Comment 5 Nick Edgar CLA 2005-01-27 13:30:09 EST
The example is nice to have in addition to a specification of the browser
lifecycle and expected behaviour of listeners.  For sketching out the lifecycle,
I'm thinking of something similar to what we have in WorkbenchAdvisor.
Comment 6 Christophe Cornu CLA 2005-04-08 16:10:18 EDT
v>20050408 WindowEvent javadoc updated to describe sequence of events when a 
new document is opened