🪰 Viewer Bug Reports

Despite setting Environment to the user's choice, e.g. Midday ( Legacy ) the viewer keeps forcibly resetting Environment to "Use Shared Environment" for a location after teleportation. If reset yet again, upon the next teleport, Environment keeps resetting to the local "Use Shared Environment". UNLESS you "just know" to uncheck a NEW option which is "Switch to Shared After Teleport". This is entirely unnecessary, not intuitive, and creates an extra step of workflow on all accounts. I can't think of a good reason for this except the demand some sim creators have that you must see their work in their chosen EEP. That's not a good enough reason as it adds unnecessary coercion to which should always be a user-selected choice. "Use Shared Environment" should remain a user's choice, not forced on each visitor upon arrival at a location, and forced on them as a default, with the requirement of having to uncheck it to get it to stop. All of this should be put back the way it was before. If you have to move this out of "Bug" to "Feature" that's your call.

It looks like the presence of an emoji in a bracketed link prevents the link preview tooltip from appearing over the string in front of the emoji. This means if you have this for example: [ https://google.com test ❤] The viewer won't show the " https://google.com " tooltip when you hover over the "test" string, but it will show the tooltip when you hover over the heart emoji. If you paste this: [ https://google.com test ❤ test] The first "test" string before the heart will show no tooltip on hover-over, but the heart itself and the second "test" string after it will show the tooltip. Now especially since the AI-written scam messages use bracketed links and emojis, even though I haven't seen one where the emojis were inside the brackets, this is quite risky. The key to protect ourselves from malicious links is to read the tooltip when we hover over the string of the bracketed link, and now a single emoji after the string can disable the tooltip, so I think it is quite clear this is a big problem even if it looks like a minor issue.

Title. I've blocked this event owner who has absolutely SPAMMED me with invites over the past few weeks. It was ridiculous it was something like 3 or 4 notecard invites per day, every time I'd log on I'd have multiples. I blocked the owner and I blocked the object they were being sent from. They've apparently since created a new object and SL isn't giving me the object name this time for some reason so I can't block it. Why on earth are users we've blocked still able to send us things via object? Why aren't all of their objects blocked by default too? Blocking is supposed to block all interaction with them not just direct messages. Please fix this, it's really really irritating and I keep having to delete tons of notecards from this person. They're already blocked, I should see absolutely zero items from them in my inventory.

When you disable a reflection probe in a linkset, with a script, then re-enable it with proper mirror flags, even though the prim properties itself (in the editor) will say 'Mirror everything', the reflection probe effectively just does 'Static' only. And it will not revert to 'Mirror everything' until you manually toggle between, say, 'static' and 'mirror everything.' Best illustrated by the actual script, that disables reflection probe when avatar is above 27.7m, and re-enables it again afterwards (where re-enaabling via script does not have the intended effect): float HEIGHT = 27.5; float CHECK_INTERVAL = 1.0; string KEY_SAVED; string KEY_AMBIANCE; string KEY_CLIP; string KEY_FLAGS; float probeAmbiance; float probeClipDistance; integer probeFlags; integer currentlyDisabled; makeKeys() { string prefix = "probe." + (string)llGetKey() + "."; KEY_SAVED = prefix + "saved"; KEY_AMBIANCE = prefix + "ambiance"; KEY_CLIP = prefix + "clip"; KEY_FLAGS = prefix + "flags"; } saveOriginalSettings() { list settings = llGetPrimitiveParams([ PRIM_REFLECTION_PROBE ]); probeAmbiance = llList2Float(settings, 1); probeClipDistance = llList2Float(settings, 2); probeFlags = llList2Integer(settings, 3); llLinksetDataWrite( KEY_AMBIANCE, (string)probeAmbiance ); llLinksetDataWrite( KEY_CLIP, (string)probeClipDistance ); llLinksetDataWrite( KEY_FLAGS, (string)probeFlags ); llLinksetDataWrite(KEY_SAVED, "1"); } loadOriginalSettings() { probeAmbiance = (float)llLinksetDataRead(KEY_AMBIANCE); probeClipDistance = (float)llLinksetDataRead(KEY_CLIP); probeFlags = (integer)llLinksetDataRead(KEY_FLAGS); } setProbe(integer enabled) { llSetPrimitiveParams([ PRIM_REFLECTION_PROBE, enabled, probeAmbiance, probeClipDistance, probeFlags ]); } default { state_entry() { makeKeys(); if (llLinksetDataRead(KEY_SAVED) == "") saveOriginalSettings(); else loadOriginalSettings(); list currentSettings = llGetPrimitiveParams([ PRIM_REFLECTION_PROBE ]); currentlyDisabled = !llList2Integer(currentSettings, 0); llSetTimerEvent(CHECK_INTERVAL); } timer() { list ownerData = llGetObjectDetails( llGetOwner(), [OBJECT_POS] ); // The owner is not currently in this region. if (ownerData == []) return; vector ownerPosition = llList2Vector(ownerData, 0); if (ownerPosition.z > HEIGHT) { if (!currentlyDisabled) { setProbe(FALSE); currentlyDisabled = TRUE; } } else { if (currentlyDisabled) { setProbe(TRUE); currentlyDisabled = FALSE; } } } }

The issue I reported probably like 10 years ago still exists: * Teleport to a new region * Source region sends circuit info of destination region to viewer * Viewer acknowledges circuit info being received * Simulator of source region transfers agent to simulator of destination region * Simulator of source region immediately closes circuit with agent's viewer * If for some reason to connection to the simulator of the destionation region fails, the viewer has no connection to either the old simulator nor the new simulator and gets logged out after 60 seconds The connection with the viewer must only be closed after the simulator of the destination region confirms the connection with the viewer has been established instead of relying on faith the handover will succeed without any problems.

Rez any prim/object in-world. Place a script inside the object that calls llDie() after a short timer, Set the object temporary, or simply have another user delete the object when instructed to do so. Add any second inventory item into the object (e.g., a notecard, landmark, or script). Right-click the item in the contents tab and select Rename so the inline text edit field is active with keyboard focus. While the text editor still has focus and there is a pending change to the name, trigger the destruction of the object. Observed Result: The viewer crashes to desktop immediately. Expected Result: The rename operation should abort cleanly without crashing the viewer. Suspected cause: The rename isn't canceled when the object is destroyed: When the containing object dies, LLPanelObjectInventory::clearContents() queues the scroller for deletion (die()) and sets mFolders = NULL. However, it never cancels the active rename or drops keyboard focus from the text field (mRenamer). When LLMortician cleans up the views on the next pass, LLFolderView::~LLFolderView() runs first and sets mViewModel = NULL. As the base destructors finish tearing down the view hierarchy, focus is finally stripped from mRenamer. Because the field is set to commit on focus loss, it tries to finish the rename and calls arrange(). Inside arrange(), it calls getFolderViewModel()->sort(this). Since mViewModel was already cleared in step 2, this immediately blows up with a null-pointer dereference (0xC0000005). Fix: The fix is to cleanly cancel the rename and drop focus before destroying the views, rather than letting focus loss trigger a commit during teardown. Add cancelRenaming() to LLFolderView : Disables commit_on_focus_lost , removes the popup, and cleanly releases focus. Cancel renaming during cleanup: Call cancelRenaming() in ~LLFolderView() , deleteAllChildren() , and LLPanelObjectInventory::clearContents() . Add null checks: Guard against a null mViewModel in commitRename() and finishRenamingItem() so arrange() won't attempt to sort a destroyed view. I've created and tested a working fix here as an example https://github.com/soapyf/slviewer/commit/9e7da4917065b857cca6f1954721dcce8e5b2fd7 And I have also submit it as a PR https://github.com/secondlife/viewer/pull/6321

I have now tested the affected alirium grass (e.g. Downy Grass) with three different viewers: • Second Life Viewer 26.3.0.31203661088: grass renders correctly • Firestorm 7.2.4.80712: grass renders correctly • Second Life Viewer 26.4.0.34502396632: grass is completely invisible I tested the same objects at the same location without making any changes to them. This therefore appears to be a rendering regression introduced in the Second Life 26.4 viewer. The affected alirium grass uses older vegetation textures with transparency/alpha. I am currently staying on 26.3.0.31203661088, where all of these objects render correctly.

See this clip from another resident for reference: https://i.gyazo.com/945bfcd536d5ba18e18795f64d159640.mp4 For vehicles in particular, if you alt-click on the root prim of it, while in motion, any child prim that is also moving (by transform or by llTargetOmega), avatars and nametags will follow the normal moving update path while the root will update faster. This is 100% reproducible. This results in a "dislocation" and spasming of the links. Digging through the history, it appears there were possibly some previous tentative fixes in llDrawable.cpp that broke doors and other things. (see MAINT-1742 MAINT-2247, MAINT-2275) But it seems neither of those fixes just simply updated all the child prims along with the root as you would expect it to do.

I've been trying to emulate Firestorm's wonderfully intuitive "Mousewalking" into Second Life Viewer (SLV), because SLV doesn't have it. "Mousewalking" is not the "point to and auto walk" feature already found in most viewers, its a Firestorm Viewer ability to manually move an avatar around with great precision by only using mouse controls. By using "Mousewalking", fewer other keyboard controls are needed, which makes "Mousewalking" a real improvement to people with limited accessibility. In SLV, I've assigned "Double Left Mouse Button" (Double LMB) to the "Alternate 2" control column for "Walk" to emulate Firestorm's "Mousewalking" walking mode. And it works well. But running is a different matter. In Firestorm, double clicking the right side mouse button will make the avatar run. But in SLV, no such "Double RMB" option is available. Could we please have "Double RMB" as a control option in Second Life Viewer? Until then, I've assigned my middle mouse button (MMB) to do the job of a lacking SLV "Double RMB" to do the running, which isn't ideal, because the MMB toggles the voice operation...! :D

When I zoom out far from my own avatar at a club or other texture-heavy areas, say to simply look around, when I return the camera to my own avatar a lot of the textures on my avatar - including materials - are lowered drastically in resolution and it takes the viewer upwards of 20-30 seconds before they go back to full. A resident's own avatar should never have the textures lowered in resolution unless it's specifically set in graphics > advanced, and should always take priority in staying at max quality according to graphics settings. Go to a club that is avatar heavy, so lots of textures are around - shopping events will probably work here too Wait for the viewer to load everything it can do - draw distance was 128 with textures at 2k maximum for this When your own avatar has loaded fully, alt+cam onto yourself and zoom out about half way to the clip plane - just looking around the area for a few seconds will work here too Return the camera to your avatar Lots of your avatar's textures, excluding BoM, are now super blurry, and will take ages to load back again Image 1 shows how my avatar is supposed to look > image 2 is how far I zoomed out (just across the room at this club) > image 3 shows how blurry my avatar's textures become after zooming back in, which stay like this for 20-30 seconds.