87972 - window.open() with 'resizable=no' is still resizable

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect, P2)

Description

[Bernd K.]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; de-AT; rv:0.9.1) Gecko/20010607
BuildID:    2001060713

I tried to fix a new popup window in its size and found that I could still
change the size of the window by pulling at the corners of the window. (didn't
work for me in NS 4.77, too).


Reproducible: Always
Steps to Reproduce:
I'll attach a testcase for that, but in general, it doesn't work at any site
that uses it (click on 'faq' in the lower right part of the screen at the given
URL for a further example)

using KDE 2.01 as window manager

Comment 1

[Bernd K.]

Attachment: test files for this

Comment 2

[Johnny Stenback (:jst)]

Works on Win2k, over to danm.

Comment 3

[Dan M]

  I've traced through the code: when "resizable=no" is requested, we're doing 
everything we can think of to hint to the wm that a window not be sizeable (we're 
setting gdk window decorations to (GDK_DECOR_BORDER | GDK_DECOR_TITLE); 
GDK_DECOR_RESIZEH conspicuous by its absence). That said, all of the WMs I've 
tried (sawfish, enlightenment and twm) seem to ignore the hint. Gotta be 
suspicious because of the unanimous verdict.
  But Navigator 4.x alert windows -- which should also be unsizeable -- are also 
sizeable. In fact the only windows I could find in any application that were 
truly unsizeable were either borderless or had a sizing handle but seemed to 
ignore it.
  In my opinion, it's a widespread window manager bug; one that most apps don't 
attempt to correct. We could probably improve our behaviour the way that the one 
example I could find seems to do it: set the window's min and max sizes equal to 
its current size, once we've figured out what the window's size should be. It's 
probably not particularly difficult, but our failure to do this isn't making me 
lose any sleep.

Comment 4

[Fabian Schach]

As Gerv mentioned in n.p.m.general: Doesn't it make a difference if you spell
resizeable instead of resizable?

Comment 5

[Justin H.]

According to the Netscape docs for JS 1.3, it's resizable (no "e").

Comment 6

[Prashant Desale]

Attachment: New Testcase.

Adding new testcase.

Comment 7

[Prashant Desale]

Adding keyword testcase. Nominating for nsbeta1 because of backward 
compatibility & also whole purpose of resizable=no is getting defeated.
Setting Priority=p2.

Comment 8

[Peter Trudelle]

nsbeta1- per ADT triage team

Comment 9

[Prashant Desale]

Nominating for RTM again.  whole purpose of resizable=no is getting defeated & 
issue of backward compatibility. Visibility could be high.

Comment 10

[Chris Casciano]

Added Back Summary... must have cut it instead of pasting it... sorry all

Comment 11

[Samir Gehani]

adt: nsbeta1-

Comment 12

[Lars Bilharz]

Attachment: Testcase: resizability depending on status= yes/no

Within winXP the resizability is depending on the "status" yes or no flag.

when status=no then resizable=no == true
when status=yes then resizable=no != true

Comment 13

[Mathias Aebischer]

In Win2K I have the same behaviour as described by Lars Bilharz. I think this
makes no sense and should be fixed.

Comment 14

[Dan M]

Lars, Mathias: That's a different bug, believe it or not. This bug is about our
inability to control whether gtk windows have sizing borders. It seems like a
window manager bug. In the situation you're describing, notice the WinXP window
borders in fact do not have sizing borders (WS_THICKFRAME style). The problem is
the statusbar contains a sizing widget.

It's a different bug because the solution is very different. In your case, the
statusbar should hide its sizing widget when in an unsizable window. Would you
be kind enough to open a new bug and assign it to XPApps component?

Comment 15

[Boris Zbarsky [:bzbarsky]]

So... we should hint to the WM that the window should not be resizable.  If it
chooses to make it be resizable anyway, we shouldn't be overriding it -- that
may be desired behavior by the user of the WM.

In my opinion, this bug is invalid...

Comment 16

[Dan M]

It does seem like a window manager bug. But note there's one thing more we could
do that would probably help (last paragraph of comment 3).

Comment 17

[Boris Zbarsky [:bzbarsky]]

See, I view this as a WM feature, not a WM bug..... ;)

Comment 18

[Dan M]

Last time I had a Linux box I hadn't made any settings instructing the WM to
override window nonsizabilitynessitude. Yet it was still giving me sizable
windows. English funny. I would think a proper WM could give you unsizable
windows when asked, unless the user had overridden that capability. Perhaps the
override is active by default.

I don't have access to a Linux box right now. If you or someone can show an
example of an unsizable window, even if you have to go out of your way to ask
the WM, I'd be happy to invalidate this bug. Or would an implementation of
comment 3 para 3 chafe more linuxheads than it soothed?

Comment 19

[Boris Zbarsky [:bzbarsky]]

It all depends on the WM.  With fvwm2, resizable=no works fine in the default
config.  Some WM's (like Afterstep) don't allow a program to demand
non-resizable windows at all, etc.  In the end, it's a design decision by the WM
programmer.... I doubt implementing your suggestion would actually affect the
behavior of any WMs, so I doubt it would chafe people much. ;)

Comment 20

[Dan M]

It's true, I'm suggestible. Closing invalid.