267950 - make extensions Options dialog resizable

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Nickolay_Ponomarev]

It would be nice if Extension Manager opened a *resizable* window for
extension's Options dialog. Ie. when you click on the Options button in EM, it
should open a resizable window. Instead it does:
> openDialog(optionsURL, "", "chrome,modal");

It is real pain for extensions with big options window. Authors have to make it
very small for people with 640x480 and 800x600 resolutions.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041028
Firefox/1.0RC1

Comment 1

[Chris Wood]

This bug isn't trivial. It makes a number of extensions unuseable because their
options cannot be accessed.

Comment 2

[Dan Fischbach]

Is this as simple as giving EM child windows permission to resize?  If it is,
can this be nominated and fixed by 1.1?

Comment 3

[Nickolay_Ponomarev]

Well, yes, it's as simple as changing a single line, but some extensions may not
want this (e.g. those that use new prefwindow on platform with auto-resizing
enabled, like on Mac).

Also, it seems that for some reason Firefox team likes non-resizable Options
dialogs, so I think this will be eventually wontfixed.

Comment 4

[Michael Bolin]

(In reply to comment #3)
> Well, yes, it's as simple as changing a single line, but some extensions may not
> want this (e.g. those that use new prefwindow on platform with auto-resizing
> enabled, like on Mac).

Would it be possible to allow for auto-resizing by default, but then to let the
extension author specify whether his Options pane can be resized?

> Also, it seems that for some reason Firefox team likes non-resizable Options
> dialogs, so I think this will be eventually wontfixed.

If users cannot resize dialogs, and authors want users to be able to have large
dialogs (as extensions get more complex and offer more customizations), then
they will have to specify them at large sizes. Obviously, it is hard to pick the
right size for a dialog so that it looks correct on every platform, so it seems
important to allow users to resize dialogs.

As an example, look at the Firefox Options dialog itself -- it is resizable
because it offers a lot of customizations and it's important for users to be
able to resize it to see everything in some of the long listboxes. Nickolay --
why do you say that the Firefox team likes non-resiable Options dialogs?

Comment 5

[Nickolay_Ponomarev]

1- it's not trivial to implement what you've described, as unlike many other
"properties" of window, its resizability is set in caller (EM in our case). So
the "resizable" flag would have to be specified in a place like install.rdf,
which seems rather unelegant to me.
2- The Firefox's Options dialog is not resizable in Firefox 1.1a (aka Deer Park
Alpha 1) on Windows.

I would like to keep this bug short, so if you wish to discuss this further,
please start a thread on MozillaZine forums instead.

Comment 6

[Stefan Breunig]

In install.rdf siply change the Optionsdialog line from eg.

<em:optionsURL>chrome://redirectremover/content/prefs.xul</em:optionsURL>

to

<em:optionsURL>javascript:opener.openDialog('chrome://redirectremover/content/redirremPref.xul','redirectremoveroptions','dialog,all,dependent');</em:optionsURL>

and everything is just fine.

The first dialog can't be resized, while the 2nd can. I don't see the point in
adding a flag, well it would be maybe easier for developing but it wouldn't be
"that" new feature at all.

Comment 7

[Michael Bolin]

Though I admit that trick is pretty clever, unfortunately, it leaves a "residue"
dialog behind, so it doesn't quite solve the problem.

Comment 8

[Mike Connor [:mconnor]]

Clearing nomination for the moment, there's a much bigger set of changes that should address this being tossed around on the wiki.

Comment 9

[Robert Strong (they/them - no direct email)]

Extension authors can do this in the same way that chatzilla accomplishes it by specifying an optionsURL like so:
javascript:opener.openDialog('chrome://extchromename/content/options.xul','','chrome,modal,resizable');window.close();

I didn't see any residue left behind.

Comment 10

[zoombronco]

This is not just a problem for extensions, but all preference menus. in FF2, buttons and text are often cut off and inaccessible.


(In reply to comment #9)

> Extension authors can do this in the same way that chatzilla accomplishes it by
> specifying an optionsURL like so:
> javascript:opener.openDialog('chrome://extchromename/content/options.xul','','chrome,modal,resizable');window.close();
> 
> I didn't see any residue left behind.
> 

Comment 11

[Chris Wood]

Please change severity to normal or major.

Comment 14

[Chuck Baker]

This is ridiculous. This bug has been open for over six years and hasn't been fixed.  It is *NOT* trivial, it is a major pain in the ass.  If the persist variables get stored with values that place the top of the options window off screen, you're stuck.

Comment 15

[Anthony Lieuallen]

Attachment: An proposed solution for this bug, exposes the options dialog "features" to extension author.

Please be kind, this is my first patch ever submitted to Firefox.

Anyway, this is basic/early and I'd like discussion/confirmation that the approach is sound first, then we can worry about cleaning it up to be an acceptable patch (tests? style? etc.).  The approach is just adding a new entry to install.rdf which allows the extension author to specify features for openDialog() when opening the optionsURL.  e.g.

    <em:optionsDialogFeatures>resizable</em:optionsDialogFeatures>

Comment 16

[Dave Townsend [:mossop]]

Comment on attachment 8674870 [details] [diff] [review]
An proposed solution for this bug, exposes the options dialog "features" to extension author.

Review of attachment 8674870 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry but given that we're planning to move away from these types of extensions I don't think it makes sense to be adding new functionality for them now.