XUL dialog: getButton API ill-defined

NEW
Unassigned

Status

()

Toolkit
XUL Widgets
7 years ago
7 years ago

People

(Reporter: sid0, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

It is not clear what a XUL dialog's getButton method is meant to return. It currently returns whatever's in _buttons, which is basically defined as "whatever buttons were seen when _configureButtons was last called" as far as I can tell.

I see at least two options for it:
1. It could return one of the implicit buttons. In this case it probably should be renamed to getImplicitButton -- I think this is the right thing to do, and much better defined to boot.
2. It could return the currently or last shown (through any means, especially once bug 667575 is fixed) button of that particular type, but I think this is a lot harder to do.

As it currently stands, however, it's just a terribly leaky abstraction.
Dynamically changing buttons on dialogs just isn't supported. Rather than filing a bug for each specific variant of that underlying issue, I think it would make sense to file a single bug on potentially improving the API for that specific use case.

Comment 2

7 years ago
(In reply to comment #0)
> It is not clear what a XUL dialog's getButton method is meant to return. It
> currently returns whatever's in _buttons, which is basically defined as
> "whatever buttons were seen when _configureButtons was last called" as far
> as I can tell.
I thought it returns the explicit buttons with the given dlgtype attribute at the time the buttons were last configured, or if none then the implicit button with the given dlgtype attribute, or if none then undefined (null in XPFE).
You need to log in before you can comment on or make changes to this bug.