make extensions Options dialog resizable

RESOLVED WONTFIX

Status

()

defect
--
trivial
RESOLVED WONTFIX
15 years ago
4 years ago

People

(Reporter: asqueella, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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

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

Comment 2

14 years ago
Is this as simple as giving EM child windows permission to resize?  If it is,
can this be nominated and fixed by 1.1?
(Reporter)

Comment 3

14 years ago
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.
Version: unspecified → Trunk

Comment 4

14 years ago
(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?
(Reporter)

Comment 5

14 years ago
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

14 years ago
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.

Updated

14 years ago
Flags: blocking-aviary2.0?

Comment 7

14 years ago
Though I admit that trick is pretty clever, unfortunately, it leaves a "residue"
dialog behind, so it doesn't quite solve the problem.
Clearing nomination for the moment, there's a much bigger set of changes that should address this being tossed around on the wiki.
Flags: blocking-aviary2?
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.
Assignee: bugs → nobody
QA Contact: bugs → extension.manager

Comment 10

13 years ago
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

12 years ago
Please change severity to normal or major.
(Assignee)

Updated

11 years ago
Product: Firefox → Toolkit
Duplicate of this bug: 495199
Duplicate of this bug: 478674

Comment 14

9 years ago
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.
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>
Attachment #8674870 - Flags: review?(dtownsend)
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.
Attachment #8674870 - Flags: review?(dtownsend) → feedback-
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.