Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Interrogation of Shift-Key state

155 views
Skip to first unread message

Janis Papanagnou

unread,
Jun 25, 2016, 8:59:13 AM6/25/16
to
I want to interrogate the boolean state of the Shift-Key (pressed or not).

I learned it is possible to define event-handlers to control keyup/keydown
events, then I could adjust some global variable that I can interrogate
where I need that information. But that is bulky and seems unnecessary(?)
complex.

My application context is a function that is triggered when a button is
pressed. Is there a simple way to just interrogate the Shift-Key status
in that function?

Janis

Thomas 'PointedEars' Lahn

unread,
Jun 25, 2016, 11:18:34 AM6/25/16
to
Janis Papanagnou wrote:

> I want to interrogate the boolean state of the Shift-Key (pressed or not).
>
> I learned it is possible to define event-handlers to control keyup/keydown
> events, then I could adjust some global variable that I can interrogate
> where I need that information. But that is bulky and seems unnecessary(?)
> complex.

It would be error-prone and unnecessary, indeed.

> My application context is a function that is triggered when a button is
> pressed. Is there a simple way to just interrogate the Shift-Key status
> in that function?

Yes.

--
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

Michael Haufe (TNO)

unread,
Jun 25, 2016, 11:51:06 AM6/25/16
to
I suggest reading a bit on this:

<https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent>

It can be "simple" if you make it so.

Janis Papanagnou

unread,
Jun 25, 2016, 1:47:29 PM6/25/16
to
On 25.06.2016 17:18, Thomas 'PointedEars' Lahn wrote:
> Janis Papanagnou wrote:
>
>> I want to interrogate the boolean state of the Shift-Key (pressed or not).
>>
>> I learned it is possible to define event-handlers to control keyup/keydown
>> events, then I could adjust some global variable that I can interrogate
>> where I need that information. But that is bulky and seems unnecessary(?)
>> complex.
>
> It would be error-prone and unnecessary, indeed.
>
>> My application context is a function that is triggered when a button is
>> pressed. Is there a simple way to just interrogate the Shift-Key status
>> in that function?
>
> Yes.

How?

>

Janis Papanagnou

unread,
Jun 25, 2016, 1:47:58 PM6/25/16
to
Hmm.. - you seem to be very stingy here with providing "simple" information.
If it "can be so simple", would it be possible to just post the way to go,
please?

The information on that link seems to suggest installing event listener for
keyup/keydown (which I wanted to avoid). Or following the 'keyboardEvent()'
link on the above 'keyboadEvent' link suggests using a KeyboardEvent() object.
My naive tries on the latter (yes, I don't know much of these issues; else I
wouldn't ask the question here), e.g.

var x = new KeyboardEvent("keypress");
if (x.shiftKey) {
alert("shift");
} else {
alert("no shift");
}

were ineffective, though, so more concrete input would be appreciated.

Janis

Thomas 'PointedEars' Lahn

unread,
Jun 25, 2016, 2:07:42 PM6/25/16
to
In the W3C/WHATWG DOM, an event listener is passed a reference to the event
object as first argument (if you need to support the legacy MSHTML DOM as
well, you need to read the “window.event” property instead). Event objects
have a “shiftKey” property whose value is “true” if the Shift key was
pressed when the event was fired, “false” otherwise. And you can pass the
property value to your function.

HTH

Thomas 'PointedEars' Lahn

unread,
Jun 25, 2016, 2:18:02 PM6/25/16
to
Janis Papanagnou wrote:

> On 25.06.2016 17:51, Michael Haufe (TNO) wrote:
>> I suggest reading a bit on this:
>>
>> <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent>
>>
>> It can be "simple" if you make it so.
>
> Hmm.. - you seem to be very stingy here with providing "simple"
> information. If it "can be so simple", would it be possible to just post
> the way to go, please?

No. Do your own homework.

> The information on that link

Resource/document; _not_ “link”. The (hyper)link is the *reference* to the
resource/document instead.

> seems to suggest installing event listener for keyup/keydown […]

It does not.

> (which I wanted to avoid).

Why do you want to avoid using the keydown/keyup events?

> Or following the 'keyboardEvent()' link on the above 'keyboadEvent' link
> suggests using a KeyboardEvent() object. My naive tries on the latter
> (yes, I don't know much of these issues; else I wouldn't ask the question
> here), e.g.
>
> var x = new KeyboardEvent("keypress");
> if (x.shiftKey) {
> alert("shift");
> } else {
> alert("no shift");
> }
>
> were ineffective, though, so more concrete input would be appreciated.

You should read more carefully. With the above you *create* the keyboard
event object (and can simulate keypresses by dispatching it to elements).

You need to use the keyboard event object that the runtime environment
creates for you, and dispatches to your event listener, instead.

<https://www.w3.org/TR/2015/REC-dom-20151119/#events>

Janis Papanagnou

unread,
Jun 25, 2016, 3:16:35 PM6/25/16
to
On 25.06.2016 20:17, Thomas 'PointedEars' Lahn wrote:
[...]
>
> Why do you want to avoid using the keydown/keyup events?

The samples I saw seemed to have suggested to have to install event handler
functions, "addEventListener()", which would be bulky. (There is also an
aspect why events *might* not be appropriate in my case; please see below
for details on "state" vs. "event" in my case.)

>
>> Or following the 'keyboardEvent()' link on the above 'keyboadEvent' link
>> suggests using a KeyboardEvent() object. My naive tries on the latter
>> (yes, I don't know much of these issues; else I wouldn't ask the question
>> here), e.g.
>>
>> var x = new KeyboardEvent("keypress");
>> if (x.shiftKey) {
>> alert("shift");
>> } else {
>> alert("no shift");
>> }
>>
>> were ineffective, though, so more concrete input would be appreciated.
>
> You should read more carefully. With the above you *create* the keyboard
> event object (and can simulate keypresses by dispatching it to elements).

Okay.

>
> You need to use the keyboard event object that the runtime environment
> creates for you, and dispatches to your event listener, instead.

This is obviously what I don't understand. Which one is it? The function
I want to implement is the following; I press the 'shift' key (the event
is irrelevant _at that stage_), and then I click a button. There's a
onclick function associated with that button, and in that function I want
to interrogate the *state* of the 'shift' key (where the 'shift'-pressed
event is long gone; unless I have installed a handler and memorized the
'shift' keypress-event). To me it seems that the concept of an *event*
handler would not be appropriate here (unless I memorize such events
earlier, through an event listener); rather I wanted a simple *state*
interrogation. From what has been posted thus far I cannot see whether
it is possible at all to interrogate keyboard states. Or whether there's
an event based approach that's as simple as I would have hoped there
exists one. All I need is a boolean function, like keyboard.isShift().

>
> <https://www.w3.org/TR/2015/REC-dom-20151119/#events>

Please be aware that posting links to standards is often not that helpful
to non-experts as it is to experts; the documents rely on knowledge that
someone not familiar with many aspects of javascript just doesn't have.
In other words, they often result in yet more questions than the one asked.
Also, spreading many technical terms like "W3C/WHATWG DOM" may show that
you are an expert, but they don't help someone who is comming here to get
information on a specific, small, and isolated question. Not everyone who
is asking questions has the background of being proficient in Javascript,
nor the goal become an expert. I'm, for example, while proficient in many
aspects of Computer Science and IT, not targetting in getting a thorough
understanding on Javascript. I just hope it is possible to get the piece
of a jigsaw I need to solve the problem that is (still) an obstacle to me.

Janis

Michael Haufe (TNO)

unread,
Jun 25, 2016, 3:17:59 PM6/25/16
to
On Saturday, June 25, 2016 at 12:47:58 PM UTC-5, Janis wrote:
> On 25.06.2016 17:51, Michael Haufe (TNO) wrote:
> > On Saturday, June 25, 2016 at 7:59:13 AM UTC-5, Janis wrote:
> >> I want to interrogate the boolean state of the Shift-Key (pressed or not).
> >>
> >> I learned it is possible to define event-handlers to control keyup/keydown
> >> events, then I could adjust some global variable that I can interrogate
> >> where I need that information. But that is bulky and seems unnecessary(?)
> >> complex.
> >>
> >> My application context is a function that is triggered when a button is
> >> pressed. Is there a simple way to just interrogate the Shift-Key status
> >> in that function?
> >
> > I suggest reading a bit on this:
> >
> > <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent>
> >
> > It can be "simple" if you make it so.
>
> Hmm.. - you seem to be very stingy here with providing "simple" information.

From experience I've learned that questions on this particular topic tend to be the wrong questions.

> If it "can be so simple", would it be possible to just post the way to go,
> please?

The point is that it depends. From your question:

"I want to interrogate the boolean state of the Shift-Key (pressed or not)."

But from the reference I provided you can see that:

"When a key is pressed and held down, it begins to auto-repeat. This results in a sequence of events similar to the following being dispatched:"

<https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Auto-repeat_handling>

So depending on your platform targets, there is a good chance you're going to be getting some contradictory information in some cases (keydown followed by a keypress and possibly by keyup somewhere in there in repetition)

Which means you are now looking at the keypress event. Luckily, the event that is raised has a property called "shiftKey" which you can interrogate. So now your left with the problem of telling the difference between someone holding down the shift key and someone mashing on the keyboard in succession.

> The information on that link seems to suggest installing event listener for
> keyup/keydown (which I wanted to avoid). Or following the 'keyboardEvent()'
> link on the above 'keyboadEvent' link suggests using a KeyboardEvent() object.
> My naive tries on the latter (yes, I don't know much of these issues; else I
> wouldn't ask the question here), e.g.
>
> var x = new KeyboardEvent("keypress");
> if (x.shiftKey) {
> alert("shift");
> } else {
> alert("no shift");
> }
>
> were ineffective, though, so more concrete input would be appreciated.


Besides the issues raised thus far, in FireFox Windows (at least), simply hitting the shift key alone is not enough to raise the event. You have to hit another non-special key as well. You can play with this here:

<http://codepen.io/mlhaufe/pen/zBNWXq?editors=0011>

For archival purposes, the linked to code is below:

function shiftListener(e){ console.log("Shift pressed: " + e.shiftKey)}

document.addEventListener("keypress",shiftListener)

Michael Haufe (TNO)

unread,
Jun 25, 2016, 3:20:33 PM6/25/16
to
On Saturday, June 25, 2016 at 12:47:58 PM UTC-5, Janis wrote:

> If it "can be so simple", would it be possible to just post the way to go,
> please?

To respond to this part again in another way:

What are you trying to accomplish at a higher level? The solution may differ

Michael Haufe (TNO)

unread,
Jun 25, 2016, 3:23:16 PM6/25/16
to
On Saturday, June 25, 2016 at 2:17:59 PM UTC-5, Michael Haufe (TNO) wrote:

> Besides the issues raised thus far, in FireFox Windows (at least), simply hitting the shift key alone is not enough to raise the event. You have to hit another non-special key as well. You can play with this here:
>
> <http://codepen.io/mlhaufe/pen/zBNWXq?editors=0011>
>
> For archival purposes, the linked to code is below:
>
> function shiftListener(e){ console.log("Shift pressed: " + e.shiftKey)}
>
> document.addEventListener("keypress",shiftListener)

I've just added a click listener as well which shows that the state of the shiftKey can be interrogated on that event:

document.addEventListener("click",shiftListener)

Thomas 'PointedEars' Lahn

unread,
Jun 25, 2016, 4:34:03 PM6/25/16
to
Janis Papanagnou wrote:

> On 25.06.2016 20:17, Thomas 'PointedEars' Lahn wrote:
>> Why do you want to avoid using the keydown/keyup events?
>
> The samples I saw seemed to have suggested to have to install event
> handler functions, "addEventListener()",

EventTarget::addEventListener() is the DOM method that allows you to *add*
event _listeners_ for an event to an object; it is available on all objects
that implement the EventTarget interface. You do not have to use it if the
markup language, as in the case of HTML5, provides event-handler attributes
(like “onclick”), or if the DOM implementation, as in the case of all of
them (AFAIK), provides short-hand properties (like “.onclick”).

But it has the advantage – despite the possibility of user-defined wrappers
that can do the same – of being able to add *more than one event listener
for an event* to the same object.

You may want to use it if you are sure that all target environments support
it for an event target, and if you want to use event bubbling or separate
script code from markup; for example, it is a good idea if you need the same
*complex* functionality in several documents because if anything changes in
the functionality, you only need to change it in one place in the script,
not in the markup (the markup then only says, e.g. by means of the “class”
attribute, on which elements the functionality should be available).

> which would be bulky.

What is that supposed to mean?

> (There is also an aspect why events *might* not be appropriate in my
> case; please see below for details on "state" vs. "event" in my case.)

Events are appropriate in your case and the only way to solve your problem.
With user interaction in a Web browser at least, you (have to) use event-
driven programming.

>> You need to use the keyboard event object that the runtime environment
>> creates for you, and dispatches to your event listener, instead.
>
> This is obviously what I don't understand. Which one is it?

Pardon?

> The function I want to implement is the following; I press the 'shift' key
> (the event is irrelevant _at that stage_), and then I click a button.
> There's a onclick function associated with that button,

What you call “a onclick function” is an event listener for the “click”
event on that button to which applies what I said before.

> and in that function I want to interrogate the *state* of the 'shift' key
> (where the 'shift'-pressed event is long gone; unless I have installed a
> handler and memorized the 'shift' keypress-event).

Apparently you have not realized yet that the “shiftKey” property is not
only available on keyboard events. However, you would have *known* *had*
*you* *tried* *it* *out*. See also the FAQ on debugging.

>> <https://www.w3.org/TR/2015/REC-dom-20151119/#events>
>
> Please be aware that posting links to standards is often not that helpful
> to non-experts as it is to experts;

In this case it is. (You have not even read what I referred you to, have
you?)

> the documents rely on knowledge that someone not familiar with many
> aspects of javascript just doesn't have.

There is no “javascript”, see the ECMAScript Support Matrix (URI in my sig).

> [rant]

<http://catb.org/esr/faqs/smart-questions.html>

Janis Papanagnou

unread,
Jun 25, 2016, 6:33:57 PM6/25/16
to
(Closing my own question.)
Simple static interrogation of the Shift key seems impossible in Javascript,
as the replies in this thread seem to suggest.

In my system context (Linux) the workaround that I wanted to avoid works as
expected at least. So for folks who want to implement such functionality
and are interested in my workaround I post the code skeleton for reference.

var shiftState = false;
function keyEvent (ev) { shiftState = ev.shiftKey; }
document.addEventListener("keydown", keyEvent);
document.addEventListener("keyup", keyEvent);

function f(arg)
{
if (shiftState) {
alert("shift");
} else {
alert("no shift");
}
...
}


Have fun!

Janis

Janis Papanagnou

unread,
Jun 25, 2016, 6:34:47 PM6/25/16
to
On 25.06.2016 21:17, Michael Haufe (TNO) wrote:
>
> From experience I've learned that questions on this particular topic tend to be the wrong questions.

My original question was: "Is there a simple way to just interrogate the
Shift-Key status in that function?" - I don't see anything that could be
wrong with it. - From my perspective I just saw a lot quibbling responses.

>
>> If it "can be so simple", would it be possible to just post the way to go,
>> please?
>
> The point is that it depends. From your question:
>
> "I want to interrogate the boolean state of the Shift-Key (pressed or not)."
>
> But from the reference I provided you can see that:
>
> "When a key is pressed and held down, it begins to auto-repeat. This results in a sequence of events similar to the following being dispatched:"

When I had been deeper in keyboard issues (25+ years ago) I seem to recall
that the control keys (Alt, Ctrl, Shift, etc.) [typically] won't create
repeating events. Notwithstanding other valid points that were meanwhile
posted, that's why event repetitions might not be an issue here, but yet
more so if the event system could have been avoided for state interrogation.

Thanks anyway for responding.

Janis

Janis Papanagnou

unread,
Jun 25, 2016, 6:49:49 PM6/25/16
to
On 25.06.2016 22:33, Thomas 'PointedEars' Lahn wrote:
> Janis Papanagnou wrote:
>
>> which would be bulky.
>
> What is that supposed to mean?

That is suposed to mean that comparably a lot code is required as opposed
to a static state interrogation. To be more concrete, the workaround that
at least seems to work in my context is

var shiftState = false;
function keyEvent (ev) { shiftState = ev.shiftKey; }
document.addEventListener("keydown", keyEvent);
document.addEventListener("keyup", keyEvent);
...
function f () { if (shiftState) ... }

as opposed to a (desired, but obviously non-existing)

function f () { if (keyboard.shiftPressed()) ... }

Given that I'm not sure that the shift key event will be correctly handled
in other environments as well the former might not only be bulky but also
non-portable. (Portability is no requirement, though, but it would be nice
to have a wider support).

>
>> (There is also an aspect why events *might* not be appropriate in my
>> case; please see below for details on "state" vs. "event" in my case.)
>
> Events are appropriate in your case and the only way to solve your problem.

So that finally answers my questions (Subject: Interrogation of Shift-Key
state); I learned that the keyboard state can not be interrogated directly.
Thanks.

>
>>> You need to use the keyboard event object that the runtime environment
>>> creates for you, and dispatches to your event listener, instead.
>>
>> This is obviously what I don't understand. Which one is it?
>
> Pardon?

You said "the keyboard event object"; I didn't understand which [existing]
object that actually is.

>
>> The function I want to implement is the following; I press the 'shift' key
>> (the event is irrelevant _at that stage_), and then I click a button.
>> There's a onclick function associated with that button,
>
> What you call “a onclick function” is an event listener for the “click”
> event on that button to which applies what I said before.

Obviously I can't put the ties together. :-(

I have
<input type="button" ... onclick="f(10)">

and the function

function f(n)
{
if (SHIFTSTATE) { alert("shift"); } else { alert("no shift"); }
...
}

I still don't see how to access the "event" here to define SHIFTSTATE.

>
>> and in that function I want to interrogate the *state* of the 'shift' key
>> (where the 'shift'-pressed event is long gone; unless I have installed a
>> handler and memorized the 'shift' keypress-event).
>
> Apparently you have not realized yet that the “shiftKey” property is not
> only available on keyboard events.

For my purpose it's in the first place irrelevant; all I wanted to know is
whether there's a simple keyboard shift-key state interrogation or not.[*]

Janis

[*] There was a simple "Yes." statement of yours in your first posting; yet
it seems that this well known sociopathic short reply was wrong, given what
I read in subsequent replies. Anyway; plain answers like "yes" or "no" without
concrete substance are (while "logically" correct) anyway completely useless
as are all the other insinuations, like not having read text behind links,
like not having tried out anything, not knowing how to post questions, etc.
This behaviour of yours is well known. For years. I guess this won't change.
Anyway. Good luck.

Christoph M. Becker

unread,
Jun 25, 2016, 6:53:52 PM6/25/16
to
On 26.06.2016 at 00:33, Janis Papanagnou wrote:

> On 25.06.2016 14:59, Janis Papanagnou wrote:

>> I want to interrogate the boolean state of the Shift-Key (pressed or not).
>
> In my system context (Linux) the workaround that I wanted to avoid works as
> expected at least. So for folks who want to implement such functionality
> and are interested in my workaround I post the code skeleton for reference.
>
> […]

In another reply you've mentioned that you're actually being interested
in interogating whether a shift key is pressed while a mouse button is
clicked. For that purpose you don't need that workaround, but rather
can ask for whether a shift key is pressed in the click event handler
(as has been pointed out by others already[1]):

someElement.addEventListener("click", function (event) {
if (event.shiftKey) {
alert("shift key pressed while mouse button clicked");
}
}

[1] Which have been actually more useful replies than this one, even
though that might not appear so to you. :)

--
Christoph M. Becker

Janis Papanagnou

unread,
Jun 25, 2016, 7:18:56 PM6/25/16
to
On 25.06.2016 23:33, Tim Streater wrote:
> In article <nkmg47$1b8k$2...@gioia.aioe.org>, Janis Papanagnou
> <janis_pa...@hotmail.com> wrote:
>>
>> The information on that link seems to suggest installing event listener for
>> keyup/keydown (which I wanted to avoid).
>
> Why do you want to avoid this?

Mainly because I was; (a) expecting that there might be a static method
that I didn't knew of, and (b) because it's not really an "event" that I
want to obtain, rather a *static* "state" property.

Now language concepts may make it impossible to support events (or to
support static keyboard states). That is important to know. But my JS
skills are very basic so it's necessary to get to know about that.

I don't mind using events for that purpose if that's the only possible
(or sensible) way to go. Actually my workaround is also based on events.
I just wanted to seek an elegant solution or an idiomatic solution.

>
> What is your software doing when you want to know about the shift key?

Briefly; to change the behaviour of the function behind the button.

>
> You may wish to buy a book on javascript and read about events models
> and what happens to events. Once you understand that a bit, by
> experimenting, you can decide how to organise your software around what
> javascript provides.

Yeah, I'm aware of that. But note (as mentioned elsewhere already) that
JS is not my primary proficiency. It appeared to me that I am asking only
a small, easy, and quickly answerable question in one line of code or so.
Despite having coded a couple thousand lines of code in JS I cannot spend
the time to learn it from scratch; there are far too many more important
other things where my focus lies. Despite what another poster had imputed
I searched the net, read specific articles on the issue, and experimented
with my actual code (my own ideas and what I found on the net) before and
also after placed my "small" question here.

>
> Also: ignore PointyHead. As you have discovered, he is a smartarse who
> thinks that it is clever to write one-word answers to people seeking
> help.

Thanks for the support! Though I know him already from other groups where
I am (and he is, or was) active; he is in many killfiles because of such
sociopathic behaviour. It's not that he has not valuable knowledge, but
the problem is that he is incapable of (or just pathologically unwilling)
respecting people, can't focus on other's views, is seemingly inalterably
fixed on his own mindset, which seems to be considered the only valid one.
Usually, because of that, it's not worth discussing with him, so I agree.

Janis

Janis Papanagnou

unread,
Jun 25, 2016, 7:31:37 PM6/25/16
to
On 26.06.2016 00:53, Christoph M. Becker wrote:
> On 26.06.2016 at 00:33, Janis Papanagnou wrote:
>
>> On 25.06.2016 14:59, Janis Papanagnou wrote:
>
>>> I want to interrogate the boolean state of the Shift-Key (pressed or not).
>>
>> In my system context (Linux) the workaround that I wanted to avoid works as
>> expected at least. So for folks who want to implement such functionality
>> and are interested in my workaround I post the code skeleton for reference.
>>
>> […]
>
> In another reply you've mentioned that you're actually being interested
> in interogating whether a shift key is pressed while a mouse button is
> clicked. For that purpose you don't need that workaround, but rather
> can ask for whether a shift key is pressed in the click event handler
> (as has been pointed out by others already[1]):

Oh, I suppose you mean that part where I answered: "Obviously I can't put
the ties together." Obviousy I wasn't able to derive functional code from
that statement. I tried some code variants but none was functional.

>
> someElement.addEventListener("click", function (event) {
> if (event.shiftKey) {
> alert("shift key pressed while mouse button clicked");
> }
> }

Thanks for this code sample; this is very valuable!

Janis

>
> [1] Which have been actually more useful replies than this one, even
> though that might not appear so to you. :)

Even if it might not appear so to you, but your reply was actually much
more useful (to me) than some of the quibbling previous replies. :-)

Joao Rodrigues

unread,
Jun 25, 2016, 7:34:54 PM6/25/16
to
On 06/25/2016 09:59 AM, Janis Papanagnou wrote:
> I want to interrogate the boolean state of the Shift-Key (pressed or not).
>
> I learned it is possible to define event-handlers to control keyup/keydown
> events,

Yes, it is, but the onkeyup event cannot be cancelled just in case you
need to.

> then I could adjust some global variable that I can interrogate
> where I need that information. But that is bulky and seems unnecessary(?)
> complex.

A global variable is not a good idea. And you may capture the shift Key
pressing whenever needed.

>
> My application context is a function that is triggered when a button is
> pressed. Is there a simple way to just interrogate the Shift-Key status
> in that function?

Just a simple example using the onkeydown event to prevent Shift key:

// HTML
<label for="txt1">TextBox1</label>
<input id="txt1" onkeydown="return getKey(event);" type="text" />

<script type="text/javascript">
function getKey(e) {
if (!e) e = window.event;
if (e.shiftKey) {
alert('shiftKey is not allowed.');
return false;
}
return true;
}
</script>

--
Joao Rodrigues

Janis Papanagnou

unread,
Jun 25, 2016, 7:37:44 PM6/25/16
to
On 26.06.2016 01:23, Tim Streater wrote:
>
> Well, you saw Christoph's reply, I hope. That does exactly what you
> want quite simply.

Yeah, it looks very promising. I will check it out as soon as possible.
Thanks again for the valuable hints and code samples!

Janis

Michael Haufe (TNO)

unread,
Jun 25, 2016, 7:50:56 PM6/25/16
to
On Saturday, June 25, 2016 at 5:33:57 PM UTC-5, Janis wrote:
> (Closing my own question.)

> Simple static interrogation of the Shift key seems impossible in Javascript,
> as the replies in this thread seem to suggest.

Nonsense

> In my system context (Linux) the workaround that I wanted to avoid works as
> expected at least. So for folks who want to implement such functionality
> and are interested in my workaround I post the code skeleton for reference.
>
> var shiftState = false;
> function keyEvent (ev) { shiftState = ev.shiftKey; }
> document.addEventListener("keydown", keyEvent);
> document.addEventListener("keyup", keyEvent);
>
> function f(arg)
> {
> if (shiftState) {
> alert("shift");
> } else {
> alert("no shift");
> }
> ...
> }

Which is insufficient as pointed out already

Michael Haufe (TNO)

unread,
Jun 25, 2016, 7:52:59 PM6/25/16
to
On Saturday, June 25, 2016 at 6:31:37 PM UTC-5, Janis wrote:
> On 26.06.2016 00:53, Christoph M. Becker wrote:

> > In another reply you've mentioned that you're actually being interested
> > in interogating whether a shift key is pressed while a mouse button is
> > clicked. For that purpose you don't need that workaround, but rather
> > can ask for whether a shift key is pressed in the click event handler
> > (as has been pointed out by others already[1]):
>
> Oh, I suppose you mean that part where I answered: "Obviously I can't put
> the ties together." Obviousy I wasn't able to derive functional code from
> that statement. I tried some code variants but none was functional.

Which means you didn't click any of the links I provided, nor tried any of the code I posted. Oh well. Horses and water and something something...

Christoph M. Becker

unread,
Jun 25, 2016, 7:56:56 PM6/25/16
to
On 26.06.2016 at 01:31, Janis Papanagnou:
Well, you were hungry, and I gave you a fish – others started to teach
you how to fish for yourself. :)

--
Christoph M. Becker

Thomas 'PointedEars' Lahn

unread,
Jun 26, 2016, 5:05:47 AM6/26/16
to
Janis Papanagnou wrote:

> [*] There was a simple "Yes." statement of yours in your first posting;
> [yet it seems that this well known sociopathic short reply was wrong,

No, *you* are wrong.

> given what I read in subsequent replies. Anyway; plain answers like "yes"
> or "no" without concrete substance are (while "logically" correct) anyway
> completely useless as are all the other insinuations, like not having read
> text behind links, like not having tried out anything, not knowing how to
> post questions, etc. This behaviour of yours is well known. For years. I
> guess this won't change. Anyway. Good luck.

Since you had finally posted some code, I had written the (trivial)
correction, and a working solution, further above. Then I had to read this.
As a result, I have cut the rest of my posting. You have yet to deserve it.

*plonk*

F'up2 poster

Thomas 'PointedEars' Lahn

unread,
Aug 18, 2016, 2:29:19 PM8/18/16
to
[Catching up on some old threads, with updated scorefile, in a break.]

Michael Haufe (TNO) wrote:

> On Saturday, June 25, 2016 at 12:47:58 PM UTC-5, Janis wrote:
>> If it "can be so simple", would it be possible to just post the way to
>> go, please?
>
> The point is that it depends. From your question:
>
> "I want to interrogate the boolean state of the Shift-Key (pressed or
> not)."
>
> But from the reference I provided you can see that:
>
> "When a key is pressed and held down, it begins to auto-repeat. This
> results in a sequence of events similar to the following being
> dispatched:"
>
> <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Auto-repeat_handling>

Auto-repeat is not supposed to happen for modifier keys like the Shift key.
(Because) there is no logic in that: auto-repeat is a keyboard driver
feature that is intended to make typing on a computer keyboard like on a
typewriter easier. For example, if you need to type a separator line of
dashes or equals signs in a plain-text document, or quickly remove a lot of
characters with Backspace/Delete; also, it is intended to make scrolling
with the arrow keys or the Page Up/Down keys easier.

Some (IMHO borken) keyboard drivers (for Windows) do it anyway. But even
with auto-repeat, while there are several “keydown” and, for non-character
keys, “keypress”, events for the same key code, there is only one “keyup”
event when the key is released. Keyboard events in Web user agents
certainly do not range among the best pieces of software design, but they
are not *that* ill-designed either.

This can be easily tested, for example with

document.onkeydown = document.onkeyup = document.onkeypress =
function (e) {
console.log(e.type, e.keyCode, e.charCode);
};

or, in older user agents:

document.body.innerHTML = "";
document.onkeydown = document.onkeyup = document.onkeypress =
function (e) {
if (!e) e = window.event;
document.body.innerHTML +=
([e.type, e.keyCode, e.charCode].join(", ") + "<br>\n");
};

> So depending on your platform targets, there is a good chance you're going
> to be getting some contradictory information in some cases (keydown
> followed by a keypress and possibly by keyup somewhere in there in
> repetition)

Name one.

> Which means you are now looking at the keypress event. Luckily, the event
> that is raised has a property called "shiftKey" which you can interrogate.

The *proprietary/legacy* “keypress” event is not fired for non-character
keys; never has been. This is how you can tell apart, for example, the
right arrow key ({keyCode: 39, charCode: 0}) and the apostrophe key
({keyCode: 39, charCode: 39}}; on my laptop with Swiss German keyboard
layout, YMMV).

[The MSHTML DOM event model up to including IE 8 (and IE 9 in Compatibility
Mode) is a “conflated” one (see “Legacy key models” in the specification
below) that does not have the “charCode” property. Just confirmed again in
resurrected IE 6 to 8, thanks to ievms.]

<https://www.w3.org/TR/uievents/>

> So now your left with the problem of telling the difference between
> someone holding down the shift key and someone mashing on the keyboard in
> succession.

Most certainly not.

Michael Haufe (TNO)

unread,
Aug 18, 2016, 6:18:01 PM8/18/16
to
On Thursday, August 18, 2016 at 1:29:19 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> [Catching up on some old threads, with updated scorefile, in a break.]
>
> Michael Haufe (TNO) wrote:

> > So depending on your platform targets, there is a good chance you're going
> > to be getting some contradictory information in some cases (keydown
> > followed by a keypress and possibly by keyup somewhere in there in
> > repetition)
>
> Name one.

<https://bugzilla.mozilla.org/show_bug.cgi?id=602812>

> > Which means you are now looking at the keypress event. Luckily, the event
> > that is raised has a property called "shiftKey" which you can interrogate.
>
> The *proprietary/legacy* “keypress” event is not fired for non-character
> keys; never has been. This is how you can tell apart, for example, the
> right arrow key ({keyCode: 39, charCode: 0}) and the apostrophe key
> ({keyCode: 39, charCode: 39}}; on my laptop with Swiss German keyboard
> layout, YMMV).

See the above link

> > So now your left with the problem of telling the difference between
> > someone holding down the shift key and someone mashing on the keyboard in
> > succession.
>
> Most certainly not.

Again, see the above link.

Thomas 'PointedEars' Lahn

unread,
Aug 20, 2016, 1:23:08 AM8/20/16
to
Michael Haufe (TNO) wrote:

> On Thursday, August 18, 2016 at 1:29:19 PM UTC-5, Thomas 'PointedEars'
> Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > So depending on your platform targets, there is a good chance you're
>> > going to be getting some contradictory information in some cases
>> > (keydown followed by a keypress and possibly by keyup somewhere in
>> > there in repetition)
>> Name one.
>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=602812>

There is nothing there that corroborates your belief.

>> > Which means you are now looking at the keypress event. Luckily, the
>> > event that is raised has a property called "shiftKey" which you can
>> > interrogate.
>>
>> The *proprietary/legacy* “keypress” event is not fired for non-character
>> keys; never has been. This is how you can tell apart, for example, the
>> right arrow key ({keyCode: 39, charCode: 0}) and the apostrophe key
>> ({keyCode: 39, charCode: 39}}; on my laptop with Swiss German keyboard
>> layout, YMMV).
>
> See the above link

BTDT. It says that *in Firefox*

- “On Windows, CapsLock, NumLock and ScrollLock [did not dispatch the
‘keypress’] event.

- On Linux, CapsLock, NumLock and ScrollLock [dispatched the ‘keypress’]
event.

- On Mac, CapsLock dispatched only [the ‘keydown’] event, [the] NumLock key
(without Fn key, i.e., external keyboard's NumLock key) dispatched the
‘keydown’, ‘keypress’, and ‘keyup’ events. The NumLock key with Fn key
and ScrollLock key don't dispatch any key events.”

from before “2010-10-08 01:55 PDT” when that bug was reported to before
“2013-07-23 11:04:32 PDT” when it was FIXED.

Who cares?

“Currently, neither modifier keys nor dead keys cause keypress event(s).”
(AISB)

>> > So now your left with the problem of telling the difference between
>> > someone holding down the shift key and someone mashing on the keyboard
>> > in succession.
>> Most certainly not.
>
> Again, see the above link.

There is neither a mention that the “keyup” event would be fired while the
Shift key were held down, nor is the Shift key mentioned there.

Michael Haufe (TNO)

unread,
Aug 20, 2016, 3:04:00 AM8/20/16
to
Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Michael Haufe (TNO) wrote:
> >> > So depending on your platform targets, there is a good chance you're
> >> > going to be getting some contradictory information in some cases
> >> > (keydown followed by a keypress and possibly by keyup somewhere in
> >> > there in repetition)
> >> Name one.
> >
> > <https://bugzilla.mozilla.org/show_bug.cgi?id=602812>
>
> There is nothing there that corroborates your belief.

Platforms are listed in there as well as in the original link I posted earlier. What exactly are you trying to criticize here? You don't believe the events repeat as listed in the original MDN article? Or you don't like that I generalized the MDN link to include the Shift key in the list of non-character items?

If you're criticizing the first, that's hard to believe. So I'll assume you're complaining about the latter (which MIGHT be justified depending on platform target), but I hedged my bet by not assuming 100% consistent behavior. I know PPK has discovered inconsistencies in the shift key behavior in the past as well [1], so it isn't unreasonable to be conservative in this case in the absence of information about specific platform targets.

> >> > Which means you are now looking at the keypress event. Luckily, the
> >> > event that is raised has a property called "shiftKey" which you can
> >> > interrogate.
> >>
> >> The *proprietary/legacy* “keypress” event is not fired for non-character
> >> keys; never has been. This is how you can tell apart, for example, the
> >> right arrow key ({keyCode: 39, charCode: 0}) and the apostrophe key
> >> ({keyCode: 39, charCode: 39}}; on my laptop with Swiss German keyboard
> >> layout, YMMV).
> >
> > See the above link
>
> BTDT. It says that *in Firefox*

You said it's not fired, and never has been. The link contradicts that claim.

> - “On Windows, CapsLock, NumLock and ScrollLock [did not dispatch the
> ‘keypress’] event.
>
> - On Linux, CapsLock, NumLock and ScrollLock [dispatched the ‘keypress’]
> event.
>
> - On Mac, CapsLock dispatched only [the ‘keydown’] event, [the] NumLock key
> (without Fn key, i.e., external keyboard's NumLock key) dispatched the
> ‘keydown’, ‘keypress’, and ‘keyup’ events. The NumLock key with Fn key
> and ScrollLock key don't dispatch any key events.”
>
> from before “2010-10-08 01:55 PDT” when that bug was reported to before
> “2013-07-23 11:04:32 PDT” when it was FIXED.
>
> Who cares?

Apparently you. You claimed:

"The *proprietary/legacy* “keypress” event is not fired for non-character keys; never has been."

Which is evidently not true, but when presented with reference you now no longer care? Seems like a bad faith criticism from where I'm sitting.

> “Currently, neither modifier keys nor dead keys cause keypress event(s).”
> (AISB)

That's not what you said before. You've added the qualifier "Currently" where earlier you said "never".

> >> > So now your left with the problem of telling the difference between
> >> > someone holding down the shift key and someone mashing on the keyboard
> >> > in succession.
> >> Most certainly not.
> >
> > Again, see the above link.
>
> There is neither a mention that the “keyup” event would be fired while the
> Shift key were held down, nor is the Shift key mentioned there.

I don't know what you're trying to criticize here either then. "Most certainly not" what?

The link I posted earlier states:

"Auto-repeat on some GTK environments such as Ubuntu 9.4

In some GTK-based environments, auto-repeat dispatches a native key-up event automatically during auto-repeat, and there's no way for Gecko to know the difference between a repeated series of keypresses and an auto-repeat. On those platforms, then, an auto-repeat key will generate the following sequence of events:

keydown
keypress
keyup
keydown
keypress
keyup
<<repeating until the user releases the key>>
keyup"

Can you summarize your criticism(s) into a single paragraph for clarity?

[1] <http://www.quirksmode.org/dom/events/keys.html>

Thomas 'PointedEars' Lahn

unread,
Aug 20, 2016, 5:48:09 AM8/20/16
to
Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> Michael Haufe (TNO) wrote:
>> >> > So depending on your platform targets, there is a good chance you're
>> >> > going to be getting some contradictory information in some cases
>> >> > (keydown followed by a keypress and possibly by keyup somewhere in
>> >> > there in repetition)
>> >> Name one.
>> > <https://bugzilla.mozilla.org/show_bug.cgi?id=602812>
>> There is nothing there that corroborates your belief.
>
> Platforms are listed in there as well as in the original link I posted
> earlier. What exactly are you trying to criticize here?

That you are jumping to conclusions, (unintentionally, I trust) spreading
FUD.

> You don't believe the events repeat as listed in the original MDN article?

No. First of all, I am trained in *scientific* thinking, so I am naturally
skeptic: I do not just believe, I demand *evidence* supporting statements.
Second, as a result, I *think* that statements made in such a way cannot be
a solid basis for design decisions. Third, my *tests* in
navigator.userAgent === "Mozilla/5.0 (X11; Linux x86_64; rv:38.0)
Gecko/20100101 Firefox/38.0 Iceweasel/38.1.0" (note the Gecko version),
using the test code I posted, do not confirm the statements: in all
instances, there is only one “keyup” event for such keys.

> Or you don't like that I generalized the MDN link to include the Shift key
> in the list of non-character items?

Once again, this is not personal; it does not matter whether *I* *like* it.
It was *fallacious*.

You have claimed “a good chance” that what you describe is going to happen.
Evidently it is not such, not even remotely.

> If you're criticizing the first, that's hard to believe.

How so? It is a wiki, not reference material written solely by Mozilla.org
developers or developers working for the Mozilla Corporation. It is peer-
reviewed, (which is good; although not on a regular basis, AFAIK, which is
not so good) but until that happened, anyone could have written any nonsense
there.

As you can see, I am using a rather old Firefox on GNU/Linux (due to
distribution limitations: I do not want systemd running on my computers) in
which I cannot confirm those claims.

It is possible that I do not meet the requirements of the (imprecisely
formulated) observations there: I am using Debian GNU/Linux, not Ubuntu
(which is Debian-based), so I am using (naturally) the GTK(+) variant of
Firefox (then rebranded by Debian as “Iceweasel” due to licensing issues,
but the relevant codebase should be the same), and I am running it from
KDE, not a GNOME-based desktop environment.

However, I find it more likely that the person writing this part of the
article (which would have been about 7 years ago; the history will tell for
sure) has encountered the edge-case bug fixed three years ago or earlier,
if that. (See below.)

> […] I know PPK has discovered inconsistencies in the shift key
> behavior in the past as well [1],
>
> [1] <http://www.quirksmode.org/dom/events/keys.html>

How far in the past, and how detailed? You are wrong if you think that
descriptions like “Shift keys” in “FF 7.0 Win” are detailed enough findings.
It is curious that you do not realize that as the bug report that you
referred to shows it.

> so it isn't unreasonable to be conservative in this case in the absence of
> information about specific platform targets.

It is unreasonable in the absence of platform target information if the
versions in question have met their end-of-life long ago, and the browser
bugs in that regard, that existed only for a short period of time, have been
fixed long ago. For what we now know, it is possible that PPK has tested
those versions of Firefox, and only those, where the bug described in the
bug report existed.

Also, PPK does not say anything about “keyup” events repeating when a key is
held down. Was his testing insufficient, or is the MDN article section the
result of superficial testing? They cannot be both correct unless there
were edge-case bugs.

>> >> > Which means you are now looking at the keypress event. Luckily, the
>> >> > event that is raised has a property called "shiftKey" which you can
>> >> > interrogate.
>> >> The *proprietary/legacy* “keypress” event is not fired for
>> >> non-character
>> >> keys; never has been. This is how you can tell apart, for example,
>> >> the right arrow key ({keyCode: 39, charCode: 0}) and the apostrophe
>> >> key ({keyCode: 39, charCode: 39}}; on my laptop with Swiss German
>> >> keyboard layout, YMMV).
>> >
>> > See the above link
>>
>> BTDT. It says that *in Firefox*
>
> You said it's not fired, and never has been. The link contradicts that
> claim.

Edge-case bugs aside of course. You make it sound as if this had not been
an edge-case bug and it would be reasonable to be considered everywhere for
all eternity.

> […] You claimed:
>
> "The *proprietary/legacy* “keypress” event is not fired for non-character
> keys; never has been."
>
> Which is evidently not true, but when presented with reference you now no
> longer care? Seems like a bad faith criticism from where I'm sitting.
>
>> “Currently, neither modifier keys nor dead keys cause keypress event(s).”
>> (AISB)
>
> That's not what you said before. You've added the qualifier "Currently"
> where earlier you said "never".

I am well aware that the bug report disproves the “never has been” in my
statement. However, it does not disprove the argument as it was meant: This
behavior was not by design, it *was* a *bug*. It *existed* only on *one*
browser on *one* platform for a *short* period of time, a considerable time
ago. And it did not occur with the key in question.

> Can you summarize your criticism(s) into a single paragraph for clarity?

The claim made in MDN, which you are primarily basing your argument on, is
too vague to begin with. It is also specious: There never was a 9.4 version
of Ubuntu. Ubuntu versions are released semianually, where the major
version indicates the year, and the *two-digit* minor version indicates the
month of the release. There was a Ubuntu _9.04_ (“Jaunty Jackalope”)
released in 2009-04; it was not a Long Term Support release, so support for
it ended 2010-10-23 with Ubuntu 10.10 (“Maverick Meerkat”) [that was 6 to 7
years ago; nobody in their right mind should use that version anymore]. And
Ubuntu is particularly quick in adopting new Firefox versions.

I implore you to apply more critical thinking to *everything* that you read.

Michael Haufe (TNO)

unread,
Aug 25, 2016, 4:39:53 PM8/25/16
to
Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

> > Platforms are listed in there as well as in the original link I posted
> > earlier. What exactly are you trying to criticize here?
>
> That you are jumping to conclusions, (unintentionally, I trust) spreading
> FUD.
>
> > You don't believe the events repeat as listed in the original MDN article?
>
> No. First of all, I am trained in *scientific* thinking, so I am naturally
> skeptic: I do not just believe, I demand *evidence* supporting statements.
> Second, as a result, I *think* that statements made in such a way cannot be
> a solid basis for design decisions. Third, my *tests* in
> navigator.userAgent === "Mozilla/5.0 (X11; Linux x86_64; rv:38.0)
> Gecko/20100101 Firefox/38.0 Iceweasel/38.1.0" (note the Gecko version),
> using the test code I posted, do not confirm the statements: in all
> instances, there is only one “keyup” event for such keys.

Join the club, but this is more an issue of engineering (management of complexity in the face of the unknown) than science (discovery of truth through experimentation). The latter obviously takes more time than the former.


> > Or you don't like that I generalized the MDN link to include the Shift key
> > in the list of non-character items?
>
> Once again, this is not personal; it does not matter whether *I* *like* it.
> It was *fallacious*.
>
> You have claimed “a good chance” that what you describe is going to happen.
> Evidently it is not such, not even remotely.

*one* experiment on your environment is not sufficient to dismiss the evidence raised in the linked articles, neither MDN's nor PPK's. At best it's additional information.

> > If you're criticizing the first, that's hard to believe.
>
> How so? It is a wiki, not reference material written solely by Mozilla.org
> developers or developers working for the Mozilla Corporation. It is peer-
> reviewed, (which is good; although not on a regular basis, AFAIK, which is
> not so good) but until that happened, anyone could have written any nonsense
> there.

Wouldn't the same criticism apply to your presentation?

> As you can see, I am using a rather old Firefox on GNU/Linux (due to
> distribution limitations: I do not want systemd running on my computers) in
> which I cannot confirm those claims.

nor rule it out.

> It is possible that I do not meet the requirements of the (imprecisely
> formulated) observations there: I am using Debian GNU/Linux, not Ubuntu
> (which is Debian-based), so I am using (naturally) the GTK(+) variant of
> Firefox (then rebranded by Debian as “Iceweasel” due to licensing issues,
> but the relevant codebase should be the same), and I am running it from
> KDE, not a GNOME-based desktop environment.

> However, I find it more likely that the person writing this part of the
> article (which would have been about 7 years ago; the history will tell for
> sure) has encountered the edge-case bug fixed three years ago or earlier,
> if that. (See below.)

But there is insufficient evidence to conclude such as neither you or I have any intention of running a gamut of tests across all combinations of OSes and browsers in order to get a definite answer on the state of affairs.

> > […] I know PPK has discovered inconsistencies in the shift key
> > behavior in the past as well [1],
> >
> > [1] <http://www.quirksmode.org/dom/events/keys.html>
>
> How far in the past, and how detailed? You are wrong if you think that
> descriptions like “Shift keys” in “FF 7.0 Win” are detailed enough findings.
> It is curious that you do not realize that as the bug report that you
> referred to shows it.

The result of your single experiment isn't much better. It's simply more information

> > so it isn't unreasonable to be conservative in this case in the absence of
> > information about specific platform targets.
>
> It is unreasonable in the absence of platform target information if the
> versions in question have met their end-of-life long ago, and the browser
> bugs in that regard, that existed only for a short period of time, have been
> fixed long ago. For what we now know, it is possible that PPK has tested
> those versions of Firefox, and only those, where the bug described in the
> bug report existed.

but

1- We don't have a range of target browsers nor OSes from the OP.
2- OSes outlive browsers
3- Evidence of which combinations no longer exhibit the bug(s) are not available
------
Therefore we can't conclude the absence nor presence in general

> Also, PPK does not say anything about “keyup” events repeating when a key is
> held down. Was his testing insufficient, or is the MDN article section the
> result of superficial testing? They cannot be both correct unless there
> were edge-case bugs.

Or they are both superficial and insufficient.

> > You said it's not fired, and never has been. The link contradicts that
> > claim.
>
> Edge-case bugs aside of course. You make it sound as if this had not been
> an edge-case bug and it would be reasonable to be considered everywhere for
> all eternity.

We know all-too-well that defensive programming is the name of the game in Web Development. As such I still hold that it is reasonable to assume the existence of the bug and program accordingly until sufficient evidence is presented
showing that it's no longer necessary to be concerned with.

Granted: MDN, PPK, and Bugzilla are not enough to come to a decision on this matter, nor is the addition of your one experiment and a handful that I would do on my systems. Thus I assume the worst. You want to call that FUD? Feel free.

> > […] You claimed:
> >
> > "The *proprietary/legacy* “keypress” event is not fired for non-character
> > keys; never has been."
> >
> > Which is evidently not true, but when presented with reference you now no
> > longer care? Seems like a bad faith criticism from where I'm sitting.
> >
> >> “Currently, neither modifier keys nor dead keys cause keypress event(s).”
> >> (AISB)
> >
> > That's not what you said before. You've added the qualifier "Currently"
> > where earlier you said "never".
>
> I am well aware that the bug report disproves the “never has been” in my
> statement. However, it does not disprove the argument as it was meant: This
> behavior was not by design, it *was* a *bug*. It *existed* only on *one*
> browser on *one* platform for a *short* period of time, a considerable time
> ago. And it did not occur with the key in question.

I'll look again, but I am still skeptical of it's limitation to such a specific instance.

> > Can you summarize your criticism(s) into a single paragraph for clarity?
>
> The claim made in MDN, which you are primarily basing your argument on, is
> too vague to begin with. It is also specious: There never was a 9.4 version
> of Ubuntu. Ubuntu versions are released semianually, where the major
> version indicates the year, and the *two-digit* minor version indicates the
> month of the release. There was a Ubuntu _9.04_ (“Jaunty Jackalope”)
> released in 2009-04; it was not a Long Term Support release, so support for
> it ended 2010-10-23 with Ubuntu 10.10 (“Maverick Meerkat”) [that was 6 to 7
> years ago; nobody in their right mind should use that version anymore]. And
> Ubuntu is particularly quick in adopting new Firefox versions.

Thank you for the summary. This is my summary claim:

forAll(browsers x operatingSystems)
thereExists( (browser,operatingSystem) )
suchThat bug(keyPress) exists

therefore
write code in a manner that won't expose this bug.

If the de-facto truth is that a subset of that cross product is in use that doesn't have the issues mentioned, then of course the excessive defensiveness if unnecessary.

> I implore you to apply more critical thinking to *everything* that you read.

Unnecessary, and excessive on the web. If there are what appear to be credible claims of the past and possible still present bugs, then spending an inordinate time in verifying and reproducing those bugs is unreasonable. Again, I'm pointing to Engineering over Science.

Feel free to build another test framework like you did for your thesis[1], and we might put this matter to rest with enough volunteers for concrete evidence.

[1] <http://pointedears.de/scripts/test/es-matrix/>
0 new messages