Closed Bug 56165 Opened 24 years ago Closed 18 years ago

Linux/Solaris popup windows have no controls

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: junruh, Assigned: pavlov)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [rtm-]) 

1.) Visit the above url and click on "here's why" near the bottom of the page, 
or visit home.netscape.com or www.aol.com and you may get a popup window.
What happens: The window has no controls on the title bar.
What is expected: Left mouse button controls (close, resize, minimize).
Netscape 6 branch and trunk Linux builds. Not reproducible on mozilla builds.
Setting rtm and regression keywords. This greatly impacts the functioning of 
child windows in the Netscape 6 Security Advisor.
Netscape 6 branch and trunk Linux builds. Not reproducible on mozilla builds.
Keywords: regression, rtm
So, no way to close these windows?

Browser, not engine. Reassigning to Layout -
Assignee: rogerl → clayton
Component: Javascript Engine → Layout
QA Contact: pschwartau → petersen
  I notice junruh is the QA contact on this bug and bug 46564, so I'm hesitant to 
say this because you'd think he'd already have noticed, but isn't this bug a 
straight out duplicate of that one?
  Note also that I can't reproduce this in my Netscape trunk build (a personal 
build, not a downloaded/installed one.) As mentioned in the much more copious 
notes in that other bug, this seems to happen only on the Netscape branch build. 
I don't have one of those at the moment; just a Mozilla and Netscape trunk. I 
haven't been able to reproduce this problem.

*** Bug 46564 has been marked as a duplicate of this bug. ***
Adding danm's comments from bug 46564 so that it can be marked duplicate.
John asked me to take a look at this. (By the way Asa: I'm told this is bug only
known to show up on a Netscape rtm branch build, not Mozilla.) Following the
steps given above to reproduce, the website issues a window.open call with this
features parameter:

"width=350,height=350,directories=0,location=0,menubar=0,resizable=0,scrollbars=
yes,status=0,titlebar=0,toolbar=0"

As you can see, they're explicitly trying to turn the titlebar off, though not
the closebox. Still, this is very rude, since the window they're creating
contains no "close" button in its content, and the OS close widget is nearly
always located on the titlebar. However, Mozilla is supposed to disallow turning
off the titlebar by unprivileged JavaScript.

So perhaps there's some code change in the affected tree that makes it pay a
kind of partial attention to the titlebar=0 line. To help pin this down, I
suggest someone spend some time with the affected build, opening windows with
various combinations of titlebar/closebar on/off and see what happens.

With unprivileged JS, you shouldn't be able to affect the presence of the
titlebar at all, but you should be able to get rid of the close box. This
experiment is most easily done using the sample XUL source that you can get to
with a debug Mozilla build from the Debug menu -> XPToolkit -> Dialog page.
That's missing from the Netscape builds, so you'll have to grab the source for
that page yourself. You want dexopenchrome.xul and dexparamdialog.* from the
mozilla/xpfe/browser/samples/ directory. Attempt to turn off the titlebar by
leaving the "titlebar" checkbox unchecked, but checking the "explicit" checkbox
next to it.

Again, I'm thinking perhaps this particular build interprets strangely the
"features" parameter used by this website when opening a window. Pinning down
what combination of features would be helpful.
danm writes: "As mentioned in the much more copious notes in that other bug,
this seems to happen only on the Netscape branch build. I don't have one of
those at the moment; just a Mozilla and Netscape trunk. I haven't been able to
reproduce this problem."

danm - would you mind emailing seamonkey-leads to see who has a branch build to
help debug this?  I don't know how serious this is for rtm, but perhaps we
should investigate.
  D'oh! Now it's a matter of public record! Alright, I just built a Netscape rtm 
branch commercial linux build. I haven't been able to reproduce this bug as 
described in any build. The "here's why" popup always has an OS close widget. 
Maybe this bug is dependent on the window manager you're using (in which case, is 
there much we can do about it?)
  Bouncing to Unlucky Pavlov, who knows more about these things.
Assignee: clayton → pavlov
Requesting a triage on this bug. It's nominated but doesn't have a - or +. Are
we going to fix this for rtm ?

I hear anecdotally that this is not very reproducible.  could we get that info
in the bug report, please?
What window manager are you using?  I am unable to reproduce this bug.  There is
no (standard) way with X to turn off the close button on the titlebar of a
window, but different window managers treat the different hints we provide them
for the window decorations differently.  Until I know what WM you are using, it
will be hard for me to figure out exactly what is going on.
Whiteboard: [NEED INFO]
I'm using Solaris Common Desktop Environment 1.3 logged into Red Hat Linux, and 
I see no controls on the title bar of the popup windows. When logged into the 
Red Had box directly, the controls are there.
By the way, when logged in directly to Red Hat, I still cannot edit Certificate 
Authority certs in the Security Manager.
*** Bug 53042 has been marked as a duplicate of this bug. ***
rtm-/future
Whiteboard: [NEED INFO] → [rtm-]
Target Milestone: --- → Future
This shouldn't be hard to fix.  I am seeing this with CDE as well.
Target Milestone: Future → ---
*** Bug 50066 has been marked as a duplicate of this bug. ***
Changed subject to reflect last dupe (added Solaris)
Summary: Linux-popup windows have no controls → Linux/Solaris popup windows have no controls
Target Milestone: --- → Future
I remember on Mozilla near 0.6 (Netscape 6.0),
preference dialog can be resized because it has
control.

But now, on 0.9.1, preference dialog also does
not control on Solaris CDE.

This isn't layout.  Taking a WAG at the correct component.
Component: Layout → XP Toolkit/Widgets
This bug has not been touched for nearly 2 years. In most cases, that 
means it has "slipped through the net".
Could someone please take a moment to add a comment to the bug with current
status, and/or close it.

btw: I cannot reproduce this bug using mozilla 1.6.
Anyone still having a problem with this bug? Or can it be Resolved?
WFM, SeaMonkey trunk Linux

-> WORKSFORME
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.