🪰 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.

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

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.

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 a link is embedded in between square brackets, for example [ https://feedback.secondlife.com/ like this] you can hover your mouse over it and a small toast window will pop up with the link in it. However if the link is embedded with an emoji in between the brackets there will be no toast, e.g. [ https://feedback.secondlife.com/ like this 👍]. With all those phishing links being everywhere in SL I find it rather risky that somebody can just hide their link entirely like this.

In the XML files located in the /indra/newview/skins/default/xui/en folder on the 2026-09-13 develop branch, there are four instances where sibling nodes with the same tag name have the same name attribute value. Since this hinders localization, please change them to appropriate names. floater_model_preview.xml ## 983: There are two <text name="quality_label"> elements inside <panel name="physics analysis vhacd"> 1013: <text name="quality_label">Resolution:</text> 2022: <text name="quality_label">Hulls per Mesh:</text> This node is not currently used on Windows, so it could not be tested menu_viewer.xml ## 2143: There are two <menu_item_check name="Rendering Type Glow"> elements inside <menu name="Rendering Types"> 2189: <menu_item_check label="Glow" name="Rendering Type Glow"> 2199: <menu_item_check label="Fullbright" name="Rendering Type Glow"> ## 2841: There are two <menu_item_call name="Force LLError And Crash"> elements inside <menu name="Force Errors"> 2853: <menu_item_call label="Force LLError And Crash" name="Force LLError And Crash"> 2859: <menu_item_call label="Force LLError, Message And Crash" name="Force LLError And Crash"> mime_types.xml 2: There are two <mimetype name="application/octet-stream"> elements inside <mimetypes name="default">. 312: <mimetype name="application/octet-stream"> <label name="application/octet-stream_label">Stream</label> <widgettype>movie</widgettype> <impl>media_plugin_libvlc</impl> </mimetype> 499: <mimetype name="application/octet-stream"> <label name="video/octet-stream">Movie</label> <widgettype>movie</widgettype> <impl>media_plugin_libvlc</impl> </mimetype> Each child has a label element, but the name attribute is set to application/octet-stream_label or video/octet-stream , and the text nodes within them contain strings that should be translated.

This viewer rapidly builds memory and CPU usage while minimized. Doing so for over an hour caused it to not respond when maximizing until memory is released. This is much worse than the current viewer where this mainly happens if you are teleported while the viewer is minimized, which can build 4 GB of memory over the course of 5 - 6 hours, but in this case, that much is built in less than an hour.

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.

llStartObjectAnimation() & llStopObjectAnimation() no longer works on Animesh characters.