Closed
Bug 267950
Opened 20 years ago
Closed 9 years ago
make extensions Options dialog resizable
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: asqueella, Unassigned)
References
Details
Attachments
(1 file)
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•19 years ago
|
||
This bug isn't trivial. It makes a number of extensions unuseable because their options cannot be accessed.
Comment 2•19 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•19 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•19 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•19 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•19 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•19 years ago
|
Flags: blocking-aviary2.0?
Comment 7•19 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.
Comment 8•19 years ago
|
||
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?
Comment 9•18 years ago
|
||
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.
Updated•18 years ago
|
Assignee: bugs → nobody
QA Contact: bugs → extension.manager
Comment 10•18 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•17 years ago
|
||
Please change severity to normal or major.
Assignee | ||
Updated•16 years ago
|
Product: Firefox → Toolkit
Comment 14•13 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.
Comment 15•9 years ago
|
||
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 16•9 years ago
|
||
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-
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•