Re: Bug 11239

On Thu, Apr 28, 2011 at 2:07 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 28 Apr 2011, Benjamin Hawkes-Lewis wrote:
>> On Thu, Apr 28, 2011 at 8:55 PM, Ian Hickson <ian@hixie.ch> wrote:
>> > On Thu, 28 Apr 2011, Benjamin Hawkes-Lewis wrote:
>> >>
>> >> One example would be that the system has no caret. For example, a
>> >> system with no visual output presumably does not have a caret blink
>> >> rate.
>> > [...]
>> > Or to put it another way: what problem does this solve?
>>
>> The problem is if the author wants to use a default blink rate
>> in the absence of better information.
>
> When would such information be absent yet still relevant?
>
> In the only concrete example that you have given, there is no visual
> output, so there's no caret, so the blink rate is irrelevant.
>
>
>> Consider two scenarios:
>>
>>    1. The user has set his caret to not blink. When drawing a custom
>>       canvas caret, the author wants to draw a caret that does not blink.
>
> Sure, this exists (e.g. the caret in RISCOS does not blink) and is
> supported (the period returned is 0).
>
>
>>    2. The UA cannot provide a blink rate (for whatever reason). When
>>       drawing a canvas caret, the author wants to draw a caret with a
>>       default blink rate (apparently this is usually 500ms).
>
> What scenario could there be? If there is no concrete scenario where this
> happens, then there's no point discussing it.

For what it's worth. I don't see that we'd implement this function at
all in firefox. For a few reasons:

1. I don't want people to write text editors using canvas. They are
bound to get a lot of things resulting in worse user experience for
users. *Especially* for users that use AT.
2. It's not worth the engineering time needed. Weeding through the
various platform APIs on which firefox runs to try to get at this
information is non-trivial. The time could be spent on features that
help users more.
3. It's in fact actively harmful for users since it increases
fingerprintability. We're going through great pains to reduce
fingerprintability, adding features that go the other way is not
something we'd take lightly.

So I'd prefer that the feature was just removed. If it isn't, and we
for some reason decide that we want to claim to implement this
function (such as it appearing in a high-profile test suite), we'd
likely just make it return 500ms.

/ Jonas

Received on Thursday, 28 April 2011 21:47:34 UTC