🪰 Viewer Bug Reports

Summary: After the most recent forced update to the official Second Life viewer (August 2025), the Left Mouse Button (LMB) behavior has changed. When set to “Interact,” LMB no longer triggers weapon scripts that rely on CONTROL_LBUTTON. This breaks functionality for multiple no-mod weapons from different creators that previously worked without issue. Steps to Reproduce: Use the official Second Life viewer (latest version as of August 2025). Equip any scripted weapon that uses llTakeControls() and listens for CONTROL_LBUTTON. Ensure LMB is set to “Interact” in Preferences > Controls. Attempt to fire the weapon using LMB. Expected Behavior: Clicking LMB should trigger the weapon’s firing script, as it did in previous viewer versions. Actual Behavior: Clicking LMB does not trigger the weapon. Instead, it appears to be intercepted by the UI or treated as a generic “Interact” action, preventing the script from receiving the input. Additional Notes: Issue affects multiple no-mod weapons from different creators. Rolling back to the previous viewer version restores functionality. Firestorm viewer does not exhibit this issue—LMB still triggers weapon scripts correctly. No workaround is available within the official viewer, as “Interact” cannot be disabled or reassigned to raw object click. Suggested Fixes: Allow users to reassign LMB to “None” or “Click Object” instead of “Interact.” Add a toggle to disable UI-level interception of LMB. Restore legacy behavior where LMB input is passed to in-world scripts unless explicitly overridden by HUD/UI elements.

When at an event and clicking on to to demo sign. It opens the map. There is no button on the map to teleport

Tldr: I used wireshark to dig into the requests and saw multiple requests for the same file. I figured this might be buggy behavior. Where's the cache? Background: Ive been using nginx through privoxy as an alternative to secondlifes caching because 20GB can fill on just driving through 4 sims, presuming you actually wanted to look around in each of them. Anyways... I noticed repeat requests and figured maybe I was mis-serving things to the viewer and causing problems. Then, I got wireshark and tried without my proxy/cache, just the viewers native one. Issue: Assuming i can read these logs (debatable)... it appears the same files are being http-requested multiple times even when they should be served from cache (as in, there is room and there has been time since last request for it to get saved. While I do have a 20 minute wireshark capture, its 500MB so I found one texture that was re-downloaded 13 times within that 20 minutes and I'm giving that as an example. This particular texture seems to be someones jacket, so no jumpscares. The image attached shows a search was for "Range: bytes" which is showing the Range request bytes and Content-Range response bytes, so you can see what requests were made, and what was served. The viewer is requesting upper ranges of null, 180631, 704919, and 2802071 (I want to guess these are relevant to discard levels). It even once asked for 98181-2802071 which is outside of the range of the file. This is why I'm most suspicious of an issue, because asking for byte 98181 in a 98182 byte long file is asking for the last byte of the file, plus more - which it should know doesn't exist. So, the server rightfully gives it 1 byte and reminds the viewer that the file is 98192 long. Unless that one byte was being used for a check, it seems odd to knowingly request it - so as a programmer I want to guess there's a one-by-one error somewhere. Sorry for being rant-ey but I don't know enough about general network diagnostics in order to give this information in a clear and concise manner.

Description When moving the avatar forward on the ground (walk or run), the camera follows immediately without any noticeable lag, regardless of the DynamicCameraStrength setting in Debug Settings. However, during Fly and Fall the camera lag works as expected. This bug is reproducible with: Default avatar (classic) Legacy, Maitreya, Kemono mesh bodies With AO, HUD, and all attachments removed (clean avatar) Sub-accounts as well (not account-specific) Note on small avatars: Some smaller rigged avatars sometimes do not show this issue, or the behavior can change depending on avatar height/hover height. However, humanoid avatars (Legacy, Maitreya, Kemono, Default) are always affected and never corrected by these changes. Confirmed in: Second Life Viewer Release 7.2.0.16729091892 (64bit) Firestorm Viewer 7.1.13 (78266) and 7.2.0 (78879) (Firestorm inherits this issue from the SL viewer) ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ Steps to Reproduce Log in with the official Second Life Viewer. Remove all AO, HUD, and attachments. Reset camera with Ctrl+9. Open Debug Settings → set DynamicCameraStrength to various values. Move the avatar forward (walk or run). Observe the camera: no visible lag. Compare by Flying or Falling → camera lag works correctly. ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ Expected Result Camera lag should smoothly delay the camera when moving forward on the ground, as it does during Fly or Fall. Actual Result During ground movement (walk/run), the camera ignores lag and follows immediately. The DynamicCameraStrength debug setting has no visible effect.

In the appearance pane, when searching for things in "my outfits", they only come up in the search result if I open a folder than contains it first, in that session. Current workaround to make the search behave as it did before is just to expand all folders and collapse them all (only works if expanded in "my outfits", not in the full inventory view). This has to be done every session. Tested and confirmed in both Maintenance X and Materials Featurette viewers 7.1.7.8974243247 7.1.8.9103842320 Image 1, before expanding folders and collapsing them again Image 2, after Cleared cache, reduced number of outfits. Issue persists. Search works in regular inventory view just fine, it is ONLY not functioning correctly in the outfits pane. Seems to have been introduced in Maintenance X

upon initial log in after installing the block list is fine block list is empty upon a new log in every log in after that the block list remains empty even after adding avatars to the block list again after clearing cache block list comes back but empties once relogging and letting inventory load completely also happens on the latest firestorm release edit: cannot update to add photo of empty block list

Upload a model with: * 3 materials A, B, C in the highest LOD * 2 Materials A, B in a lower LOD Error occurs. This was an error in the SL viewer for many years. The server permits fewer materials in lower LOD levels as long as every material is found in the highest LOD. This intentional feature (been there since Mesh went live) permits better optimization of low LOD mesh. This error was already fixed. This is a regression. See: https://github.com/secondlife/viewer/issues/1529 Issue passed QA in 7.1.9.9469671545

It seems that now we have deterministic link order when uploading multiple meshes in a DAE or GLTF/GLB file, however even though it puts the first object as root, based on alphanumerical order, it puts the rest of the links in reverse order. Test this: Create a DAE or GLTF file where each mesh is named A through E. Confirm that the file has the meshes listed in order of A....E by opening it in a text editor (doesn't work for GLB, obviously, but does for GLTF or DAE) Upload 'as you do' Check link order, and find them to be in the order A, E, D, C, B where A is root.*** *** In the case of DAE, this seems to be true for uploading in the latest FS Beta (7.2.0.78879), but besides root being 'A' in all my tests, the other links seems to end up random when uploaded with the SL Viewer, not even just in reverse order. Expected behaviour is to have all links in alphanumerical order, where A is root and is then followed by B, C, D, E, regardless of GLTF or DAE. Related Canny, which can be closed: https://feedback.secondlife.com/bug-reports/p/random-root-object-assignment-upon-upload-of-multi-object-dae-file

If I search for an attachment in the ouftits/avatar window, I get no results, but if I expand the list for the outfit I'm looking the attachment for in, it does show up on search, but at that point I have essentially found it manually, rendering the search kind of useless.

I was able to confirm in 7.2.0, outfit search is quick and responsive. In 7.2.1, searching an outfit causes immense lag, to the point the whole viewer locks up for seconds. Have a lot of outfits Open the Outfit window (cmd+o or ctrl+o for windows/linux) Search This does not affect inventory search. Videos of this: https://gyazo.com/28bcaf2ef71953105a58a83a8bbf0e4c - 7.2.0 (no issue) https://gyazo.com/d0c2bcf775f7f6a287d5b9a1ce6669f5 - 7.2.1 (issue)