Nicky Dasmijn commented at 2022-03-06T23:17:32Z

This seems to be a side effect of:

commit 83127d22992e055b40298724d0cac0de108b6116
Author: Mnikolenko ProductEngine mnikolenko@productengine.com
Date:   Thu Jan 21 19:02:18 2021 +0200

    SL-14720 FIXED Undo function is incorrect on German Mac keyboard

reverting this commit restores the old behavior.

Katarin Kiergarten commented at 2022-03-07T01:35:41Z, updated at 2022-03-07T01:36:45Z

I can reproduce this. The version which the viewer updated itself to before I tested this just now is below. (It does not match the version reported as current for this issue, though I see that the release notes link matches.)

Second Life Release 6.5.3.568554 (64bit)
Release Notes

You are at [redacted]
Second Life Server 2022-02-10.568388
Release Notes

CPU: Apple M1 (2400 MHz)
Memory: 8192 MB
OS Version: Mac OS X 10.16.0 Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Oct 12 18:33:38 PDT 2021; root:xnu-7195.141.8~1/RELEASE_ARM64_T8101 x86_64
Graphics Card Vendor: Apple
Graphics Card: Apple M1

OpenGL Version: 2.1 Metal - 71.7.1

Window size: 2162x996
Font Size Adjustment: 96pt
UI Scaling: 1
Draw distance: 200m
Bandwidth: 3000kbit/s
LOD factor: 1.625
Render quality: 3
Advanced Lighting Model: Enabled
Texture memory: 512MB
Disk cache: Max size 1996.0 MB (100.3% used)
HiDPI display mode: 0

J2C Decoder Version: KDU v7.10.4
Audio Driver Version: FMOD Studio 2.02.03
Dullahan: 1.12.3.202111032211
  CEF: 91.1.21+g9dd45fe+chromium-91.0.4472.114
  Chromium: 91.0.4472.114
LibVLC Version: 3.0.16
Voice Server Version: Not Connected
Packets Lost: 91/4189 (2.2%)
March 06 2022 17:34:13

Dan Linden commented at 2022-03-07T19:38:55Z

Thank you for the report, Anastasia!

Anastasia Horngold commented at 2022-07-30T22:29:47Z

Any progress on this one? It continues to affect all us Mac users.

Dan Linden commented at 2022-08-03T02:29:12Z

This is marked as fixed in Maint Izarra, https://releasenotes.secondlife.com/viewer/6.6.2.573282.html

Let us know if it's still broken there, and we'll reopen this bug.

Whirly Fizzle commented at 2022-09-15T22:18:26Z

I have reopened this issue.
TatianaRuiz reports that this bug still reproduces on the current Mac build of the default LL Viewer which should contain the Izarra fix.
Her language is set to Portugese
This is the screenshot she sent me: https://gyazo.com/5665b06628543cbe34efe6c75fcf28b6

I will get her to comment here now this issue is reopened.

Gwyneth Llewelyn commented at 2022-09-16T00:52:38Z

Thanks @whirly Fizzle for reopening the issue, since, unfortunately, it continues to plague us native non-English-speakers on a Mac.

To be more precise, the issue is not exactly if Option-E produces something or not. That is certainly the case, and it works well; in other words, if you press a key simultaneously with a modifier key (shift, alt, ctrl, fn, option, cmd...), then the expected key will, indeed, be produced.

The problem appears when you have to press a sequence of keys (usually two, on accented Western European languages, which are basically all except English and possibly Dutch...). The accent comes from a different key (traditionally, on the right side of the keyboard, because that's where old mechanical keyboards used to place them...), which is pressed first (usually briefly showing what accent was typed with an underscore or similar mark to show that the input is waiting), followed by another key. So, instead of pressing two or more keys {}simultaneously{}, when typing accented characters, the convention (again, coming from mechanical typewriters...) is to type a {}sequence{}, usually of just two keys (note: Asian and/or Arab keyboards may have more complex rules).

To give an example, in German, if you wish to get the vowels with a trema ({}Umlaut{} in German), you press the key for the trema first, producing a {}¨{}, and then press a vowel, say, {}u{}, to get the final {}ü{}. A Portuguese keyboard (which is what I've got as well) will have at least four accents (as well as the trema is actually also included, since the ü still appears in a handful of words, especially on Brazilian Portuguese); I understand that at least the French and Spanish keyboards have those four additional keys as well (even if each country has them on slightly different places).

Note that before the mentioned revision, accented characters worked flawlessly on any part of the viewer that accepted Unicode characters — text chat (including IMs, group IMs, etc.), notecards, scripts, and on the land and user profiles. Things like object names and descriptions, as well as inventory entries, have always been ASCII and not Unicode, so there was no way to add accented characters there.

But, as said, the issue is not about supporting Unicode characters typed via the keyboard — those that can be produced via modifier keys pressed simultaneously with a key will work. Similarly, you can copy & paste Unicode characters (including all possible accented characters!) from outside the viewer into those areas accepting Unicode, and that will work as well. Loading/saving scripts to an external editor will also allow Unicode characters, produced externally, to be saved back into the script via the SL Viewer. All that works well, and, to the best of my knowledge, never stopped working.

It's just combination of keys that is broken. Note that the SL Viewer did not always support such combinations. It is present on the Windows version since time immemorial (or rather when Unicode replaced ASCII on notecards, Display Names, etc.), but on the Mac, I'd say it's something that appeared a little over a decade ago, and which worked well over the many upgrades...

As reported elsewhere, interestingly, the Firestorm Viewer did also incorporate the 'broken' revision — a few days after it has been released — and therefore also suffers from the same problem. They refer to this issue internally, in the sense that 'it will be fixed when Linden Lab fixes their own Viewer'.

And, while unimportant, let me add, for the sake of completeness, my current environment:

Second Life Release 6.6.4.575022 (64bit)
Release Notes

CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (2800 MHz)
Memory: 16384 MB
OS Version: Mac OS X 10.16.0 Darwin 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 29 04:31:06 PDT 2022; root:xnu-7195.141.39~2/RELEASE_X86_64 x86_64
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce GT 750M OpenGL Engine

OpenGL Version: 2.1 NVIDIA-16.0.13 

Window size: 2806x1614
Font Size Adjustment: 96pt
UI Scaling: 1
Draw distance: 64m
Bandwidth: 10000kbit/s
LOD factor: 0.5
Render quality: 0
Advanced Lighting Model: Disabled
Texture memory: 512MB
Disk cache: Max size 1996.0 MB (23.0% used)
HiDPI display mode: 1

J2C Decoder Version: KDU v7.10.4
Audio Driver Version: FMOD Studio 2.02.06
Dullahan: 1.12.4.202209142017
  CEF: 91.1.21+g9dd45fe+chromium-91.0.4472.114
  Chromium: 91.0.4472.114
LibVLC Version: 3.0.16
Voice Server Version: Not Connected
September 15 2022 15:44:51

mariaa Barbosa commented at 2022-09-16T16:29:58Z, updated at 2022-09-16T17:03:27Z

Hello,

Few things to add after the excellent post from Gwyneth. I'd like to remember that this issue affects all Mac users with almost all western languages but english. I'm spanish, we use accents and there are words with different meanings with/without accent.

These issue lasts for the last 4-6 months, three Firestorm releases ago.

For instance, "sólo" (only) or "solo" (alone), "ésta" (pronoun) or "esta" (adjective) or "está" (he/she/it is) or "inglés" (native from England) , "ingles" (crotches)

Thank you :)

JIRAUSER342662 commented at 2022-09-16T19:58:37Z

Exactly, I also agree with Mariaa Barbosa.
And as I said to Whirly Fizzle, also in LL viewer I still don't have graphic accents in Portuguese (Brazil).
The accents acute (´), grave (), circumflex (^), backtick (), umlaut (ü), quotation marks ("), cedilla (ç).
All are substantially needed in our language and others as I am reading here.
Please fix this, thank you!

https://gyazo.com/3627670059b9e2f6197d3243137f5dc2

AndreyK ProductEngine commented at 2022-12-13T11:35:29Z

Is this still an issue? I press option-e then a and get á in viewer's chat.

Whirly Fizzle commented at 2022-12-13T18:20:41Z

This bug still reproduces, please see BUG-233073

Whirly Fizzle commented at 2022-12-13T18:22:14Z

You should all be able to comment on this issue now :)

mariaa Barbosa commented at 2022-12-13T18:33:11Z

After being the thread reopened for comments, I'm able to answer to AndeyK Productions.

(Thanks!)

The issue is about the way that western languages (all but english) users write on the keyboard. We press the accent (diacritical sign) key and immediately the letter we want to appear accented.

This has been working for years on Mac systems and suddenly stopped working. Please read the Gwyneth comment, which is a fantastic reporting of what's happening and why.

This issue is still happening and at the time I'm writing I'm not able to write accented letters.

Please keep in mind the big importance of that for western languages other than english, because there are many words with different meanings with/without the accents.

JIRAUSER342662 commented at 2022-12-13T20:27:53Z

yes it still happens
nothing has been resolved

AndreyK ProductEngine commented at 2022-12-14T13:26:58Z, updated at 2022-12-14T17:33:06Z

Ok thank you, I can print things like ü and ñ that require option key without issues in viewer 6.6.8.576863 on MacOS's German 'input'. But now I see that í doesn't work in viewer.

mariaa Barbosa commented at 2022-12-14T18:53:24Z, updated at 2022-12-14T18:57:35Z

Again, that's not an issue about the Mac "option key".
The issue is about writing diacritical accents in the way we use the keyboard in every single application.
We press the diacritical sign key (`, ´. ¨, ^) immediately followed by the vowel we want to be accented (á, à, â, ä, etc). We press the sign key and immediately the vowel, no "option key" is needed. That's not working on SL chat window nor general chat input textbox (in fact anywhere we can type in).

Please, read the comment from Gwyneth in this very thread, it fully explains the problem and, I guess, some of the causes.

These are the keys that don't work. For example, to write "ò" first we press the "`"key and then "o" 

AndreyK ProductEngine commented at 2022-12-14T21:22:31Z, updated at 2022-12-15T22:23:38Z

The problem is that I can input a sequence like ¨ then u to get ü on German layout, and it works. Gwyneth's explanation specifically covers ü. I assume people who looked into this before me just couldn't reproduce the issue as well. But I managed to repro with other symbols (I assume it's the same issue).

Please check, hopefully this fixes it: https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/108698/946651/Second_Life_Test_6_6_9_577303_x86_64.dmg

Gwyneth Llewelyn commented at 2022-12-16T01:14:37Z

@andreyk ProductEngine success!

Whatever magic you have worked into 6.6.9.577303 has fixed things for me :) Thank you so much!

You can scroll down to the bit I marked on the snapshot below, showing the accents as I've typed them — and I did type them out as a sequence of accent + character, not merely done a copy & paste :D

I really hope that others have the same experience, and that this Jira report can be successfully closed! What a nice Christmas present ;)


P. S. I deliberately left the Help > About Second Life dialogue box opened, in case you wish to confirm things such as the hardware type, graphics card, macOS version, drivers, software components, etc. — so that at least you guys know that there is a specific combination of all of those things that does work.

AndreyK ProductEngine commented at 2022-12-16T14:30:17Z, updated at 2022-12-16T14:33:57Z

Thanks for the confirmation, fix will go into DRTVWR-570, but I doubt it will get deployed this year.

mariaa Barbosa commented at 2022-12-16T16:56:40Z

 Thank you, AndreyK!

The beta version you offer worked also for me, typing with a spanish keyboard. I hope this fix will be included in your next public release.

Now the problem I'm facing is with Firestorm, where the problem persists. As far as I understand Firestorm is built around  the LL APIs. So... that means that they won't be able to fix it until LL publishes the new version?

I know this is now a Firestorm issue, but I'd appreciate you explain it so I could get a time expectation for this being solved.

AndreyK ProductEngine commented at 2022-12-16T17:17:49Z

So... that means that they won't be able to fix it until LL publishes the new version?
As far as I know, Firestorm developers often merge fixes long before LL releases them. There is a chance Firestorm will pick this up early.

I hope this fix will be included in your next public release.
There likely will be at least one other viewer release before this fix goes out (release process might take a while). Fix is likely to be released as SL-18384 in release notes.

mariaa Barbosa commented at 2022-12-16T17:22:57Z

Thank you very much, Andrey K for replying so quickly.

Dan Linden commented at 2023-01-13T19:16:21Z

This fix is in the Maint-Q RC viewer which is available on https://releasenotes.secondlife.com/viewer/6.6.9.577418.html

Gwyneth Llewelyn commented at 2023-01-27T17:06:32Z

Just to report (as shown on the picture I've posted earlier) that using diacritocs/accents now work perfectly on all versions of the SL Viewer I tested, as well as on Firestorm — so it seems that this correction (actually, a reversion) has been picked up by all current projects relying on the 'main' codebase.

Thanks for looking into this, and I'm sure this ticket can now be closed and marked 'fixed' :)