Closed Bug 307761 Opened 19 years ago Closed 12 years ago

java is not using the full screen

Categories

(Core Graveyard :: Java: OJI, defect)

1.8 Branch
PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: docbill+bugzilla, Assigned: alfred.peng)

References

()

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

I don't quite understand what causes this bug.  But the above applet uses a
border layout panel.  The scrollbars, which are manually added into the border
are in the right place, but there is a blank area about the size of scroll bars
between the center pannel and the scrollbars.  It is as if the area is size is
being reported with scrollbars already added in, and the the borders are placed
in the right spot.  The net effect however is that an area the size of
scrollbars is not being used.

Reproducible: Always

Steps to Reproduce:
1. Open the applet and take a look.
2.
3.

Actual Results:  
Somehow it double counted the number of pixels needed for the borders and left a
grey border between the inner pannel and the scrollbars.

Expected Results:  
The applet should appear the same as in the older version of Firefox, or Safari.
 With the image taking up 100% of the inner pannel.
Assignee: nobody → yuanyi21
Component: General → Java: OJI
Product: Firefox → Core
QA Contact: general → oji
Version: unspecified → 1.8 Branch
BTW.  The problem is definitely not the applet.  Firefox 1.5 beta 1 on MacOSX is
the only platform that has produced this problem.  Firefox 1.0.6 produces other
problems which have been fixed the the new core, but not the 100% cpu forever bug.

Chances are it is a combination of problems.  For example, the MacOSX versions
of Java do different locking than Sun Java.  This has been known to cause
deadlocks.  It can well be that one browser has a deadlock while another doesn't
running the same code and same version of java just because the timing is
different.  This does not look like a deadlock issue, but it could be some sort
of loop that is happening in the garbage collection thread or such.

Bill


Bill
Please ignore comment #1.  I ment to post that to bug 307757.
Assignee: yuanyi21 → pete.zha
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng
Product: Core → Core Graveyard
Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.