Unintentional arrow navigation!

[stam]

Hi all,
I'm finalising an app for work - with different levels of access based on a password system.

On Windows, my beta testers reported that they can navigate all cards (regardless of login) simply by using the arrow keys.
I've reproduced this in several versions of the software, on different Windows machines. On double checking a Mac build, I found the same happens there too, which makes me think this may be the navigationArrows property defaulting to true.

On reading the documentation, it states that "By default, the navigationArrows property is set to true."
I'm not sure I understand the logic of this - if my IDE, where I test, has this set to false, why should this default to true on anything I build? That's just a recipe for insanity
Furthermore, it's not clear if I need to set this to false once in preOpenStack, or have to set it to false in every preOpenCard as well.

This is a potentially nasty gotcha for any environment that relies on limited access to certain cards.
Is it worthy of a bug report?

Stam

[Klaus]

Hi stam,

since this is a global property setting it to FALSE on pre-/openstack ist enough.
I also thought this would be FALSE by default, so a bug report won't hurt!


Best

Klaus

[stam]

Thanks Klaus - it’s a bit of a disaster as on checking, this has affected all my other apps as well. I never thought to use the arrow keys until now so had no idea, and if any user noted this they probably kept it to themselves so the could access restricted sections…. But probably no one thought to use arrow keys until the current beta testers. GRRRRRR!!!!

I’m stunned this is a thing. It should not be the case that the same stack exhibits different behaviour in IDE vs Standalone.

I guess everyone relying on restricted navigation needs to be aware of this potentially massive security hole in their apps, as it only appears in standalones and not in the IDE unless you set navigationArrows to true on purpose in the IDE settings.
What a corker...

Bug report submitted: https://quality.livecode.com/show_bug.cgi?id=24196

[stam]

Annoyingly I found a bug report on this from 2017: https://quality.livecode.com/show_bug.cgi?id=20279

It remains unfixed.
It creates different behaviours in standalone vs IDE for the same stack.
A bit of a faux pas, with massive security implications for me :-/

[richmond62]

!@#£%^&*

Had that bug been sorted out in, say, 2017, those of us,
who at present at least, are working with the open source versions, would not have this round our necks until we,
either:

1. Find enough money to buy a current version of LC.

Or

2. Work out how to hack community 963 to sort this out.

[stam]

Workaround is to put

Code: Select all

Set the navigationArrows to false

In preOpenStack or startUp.

The problem was than I had no idea I was supposed to do this, wrongly assuming that what I saw in IDE would be what would I’d get in standalone :-/

[richmond62]

This finally explains why about 10% of my ESL pupils are faking completing grammar & vocab exercises when I have disabled next card buttons in standalones until each card's activity has been completed.

This should involve no less than about 12 hours recoding the source stacks, spinning off the Linux 64 standalones, installing them across about 16 machines, setting the executable bit on each one, and so on.

At present I have 60 standalone programs on machines in 2 schools in locations that are 30 minutes apart by car.

Not that LC will give a damn about that.

I wonder exactly WHAT the point of the bug reporting system is if LC don't act on those bug reports?

[stam]

Ouch!

Well glad this did help someone at least…

[richmond62]

Thanks for the work around, even if it will be a complete pain in the bum.

Why is my main crit. of LC (well, apart from the 'tomato sauce') that developers have had to worry about 'work arounds' far, far too often?

[FourthWorld]

Some background may be useful:

1987: HyperCard premiered, in which using the arrow keys with no insertion point in text allowed card-to-card navigation. This was a reasonably good default at the time, since much of what HC was used for was multi-page informational stacks. The way to turn that off was to write an empty handler to trap the arrowKey message.

1989: SuperCard premiered, and with the goal of being a true superset of HyperTalk it retained this arrowKey navigation feature.

1992: MetaCard was born, and with both HC and SC having adopted the same arrowKey navigation, and in a world where xTalkers pride themselves in using a language that offers a stronger emphasis on backward compatibility than most others (ever try to move code from Python 2 to Python 3? <g>), MC maintained that long-established feature.

2001(?): MetaCard still maintained the tradition with arrowKey navigation by default, and LiveCode (at that time called Revolution) had not yet acquired the engine. But the sort of work that benefited from arrowKey navigation was often reference content, much of which had long since been migrated to the web. The Rev/LC team saw the difference in the types of things folks were making, recognized that arrowKey navigation was often (but not always) passe, and since they didn't control the engine code they at least cleaned up the development experience by adding a preference to override that in their IDE.

2003-2022: LiveCode acquired the engine and expanded it in a great many ways, but since folks already had a great many years behind them of handling arrowKey navigation as they had, almost nobody cared about adding a line of code to handle arrowKeys as much as they cared about everything else (the number of times I've seen this discussed over the last 20 years can be counted on one hand).

2023: This thread.

Like most xTalkers I value the unusual priority backward compatibility is given to this language. But I'm a bit more lax than some. There's a lot of pressure placed on the team when they make language changes, and even when the rare change or deprecation is called out in bold red letters at the top of the Read Me, there are complaints that the team "broke my software".

Here we see a solid consensus for change. No doubt there will be some edge case giving rise to a complaint, but I agree with everyone here that this engine change is long overdue. Hopefully we'll see more; there's a lot of old stuff lying around from ancient times like this one.

[stam]

Thanks Richard.

Just to clear, this isn’t an issue about or a criticism of the arrowNavigation property itself; I’m sure it’s useful to some.

The issue that is less easy to stomach is that the IDE setting doesn’t dictate the standalone setting and that the latter always defaults to true, and that’s not some one can blame HC or SC for (possibly MC I guess).

Because the two don’t sync and because of the way the IDE is set up, countless desktop standalones will have been affected by this (sadly I know all of mine are, and they deal with patient-confidential data). It’s also not great this was raised 6 years ago, I suspect no one really understood the wide reaching effect this mismatch has caused.

Anyway what’s done is done and it’s good to see the team the team are proactively taking action to mitigate this insidious bug.

For now recognising this is an issue and discussing it on the forum let’s us guard against this until the next version of LC is available (or for those who will not be able to use the next version).

S.