450733 - Deprecate the timed textbox binding

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, defect)

Description

[Dão Gottwald [:dao]]

Attachment: patch

The next step for 1.9.2 I think should be to assign the search binding to type="timed", with a similar warning, since it's fairly backwards compatible. Eventually we should be able to drop support for type="timed". Bug 449045 tracks this.

Comment 1

[Neil Deakin]

Comment on attachment 333912 [details] [diff] [review]
patch

Looks OK, but what incompatibilities exist that would prevent us from using the search binding for this now?

Perhaps the 'command on input' aspect?

Comment 2

[Dão Gottwald [:dao]]

(In reply to comment #1)
> (From update of attachment 333912 [details] [diff] [review])
> Looks OK, but what incompatibilities exist that would prevent us from using the
> search binding for this now?

I can't think of direct incompatibilities. But even if we use the search binding for type="timed", I'd prefer to still keep the timed binding for now (with the warning) as there could be custom bindings that extend it, like we did in the Places organizer.

Comment 3

[Phil Ringnalda (:philor)]

http://mxr.mozilla.org/comm-central/source/mail/base/content/search.xml#52 for one.

Comment 4

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/9d40cd95d9c9

Comment 5

[Wladimir Palant]

Great, deprecating something without giving extension developers a better choice - type="search" isn't supported in Firefox 3.0, and extensions will still have to take Firefox 3.0 into account for a while. Also, there is no good way to test for type="search" support AFAIK. So the best solution for extension developers is removing type="timed" and reimplementing the functionality with a regular textbox. Was that the intention?

Comment 6

[Dão Gottwald [:dao]]

It's still there, it's just deprecated.

Comment 7

[Wladimir Palant]

Yep, and I'll get bugs filed because of the warning...

Comment 8

[Phil Ringnalda (:philor)]

I'm curious: how many things-which-aren't-Firefox using it would cause a reconsideration of deprecating it?

Comment 9

[Dão Gottwald [:dao]]

(In reply to comment #8)
> I'm curious: how many things-which-aren't-Firefox using it would cause a
> reconsideration of deprecating it?

You don't want a fixed number, right? So far this seems to be a hypothetical question, as I know of only one such use (bug 449045 comment 1). Comment 5 doesn't seem to be such a case, as it refers to type="search" being unsupported in Firefox 3 rather than being the wrong solution per se. That's why we didn't drop type="timed" just yet.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

The number of users isn't directly relevant to whether it should be deprecated - presumably those users will get the same benefit we do from switching (simpler code that is better maintained, looks like?).

Of course, switching has a cost, too, and I can understand that this type of forced-deprecation might be annoying, but given the fact that this is a warning, not an error, it hardly seems so onerous that it outweighs the value of notifying developers of the better alternative. Do you disagree?

Comment 11

[Wladimir Palant]

I would expect a deprecation warning to be added after the alternative has been available for at least one release - unless the point of the warning is to be ignored.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Sure, that's a problem for extensions that care to be compatible. I don't mind if developers of such extensions ignore the warning until the new functionality is more widely deployed - do you really think that's too much trouble?

Comment 13

[Wladimir Palant]

If you look at bug 454010, there are already three duplicates filed - and that's only about nightly builds. I had bugs filed about getBoxObjectFor() being deprecated (the warning is only meant for web page authors but who cares), so I don't expect anything to be different for this warning.

Comment 14

[Wladimir Palant]

PS: Yes, reimplementing type="timed" is easier than having code that works both with getBoxObjectFor() and getBoundingClientRect() depending on which one is available - so it should require less time than explaining people the difference between an error and a warning. Nevertheless, I don't like reimplementing functionality that is supposed to be there.