🪰 Viewer Bug Reports

When opening the inventory, it's missing many items. I have to open a second inventory window for everything to show. Clearing cache and even reinstalling doesn't seem to solve this problem. I always have to open a second inventory window to gain access to my full inventory, The first window that opens mostly shows empty folders. The recents filters don't seem to work in the first inventory window either, I always have to open a second Inventory window and then everything only shows up in the second inventory window.

If I try to save multiple gestures to current outfit through the gesture window, it just disables them without populating the outfit with the gestures. It doesn't actually save or copy links to the outfit. Thus, end up losing the gesture setup. I had this happen to me twice now, once before I realized what was happening and again when trying to figure out what happened. It takes HOURS to go through inventory, find, and set it all up/reenable again. Also, the whole save to current outfit is not intuitive at all. Ideally, it should be "save to outfit" then have a popup allowing you to select what outfit you want to save the current selected(hilighted) or activated gestures to. This would allow you to easily make sets of gestures that can be applied to any outfit without having to mess around with what you are wearing or modding the outfit to remove unnecessary things since you can't apply an empty outfit after creating a blank one in order to even use save to current from the gesture window. As far as whether to use selected (highlighted) or active gestures when saving, I'd say selected as it reduces steps to achieve the task, however there may be people that don't even realize you can select multiple using shift... so idk that's a toss up and ultimately should be a poll or something to figure out what people would prefer, or you could just have two options.. 1. save active gestures 2. save selected gestures.

Rez a no-copy item from your inventory into a place where you do not have rez rights OR onto most pieces of mesh (eg, not a SL prim, not the bare ground). You get a message saying that you can't rez the item here. The item is no longer in your inventory The item will only be restored to you if you quit SL and restart your viewer. So, the server knows that the item isn't going to be rezzed, the viewer knows that the item did not rez, the server knows the item is still in your inventory...and yet the viewer will not show that item until it is completely restarted. It should be clear why this is undesirable. This behavior currently occurs in all viewers, and has done so for many, many years.

This might need a large inventory or an inventory with many items in the root folder to reproduce Login and open inventory In the "My Inventory" tab, right click the root "My Inventory" folder. Observe the viewer freezes & never recovers, needing a force quit in Task Manager The freeze also reproduces when right clicking the "My Inventory" folder in the Recent tab of inventory if inventory folders are set to show items newer then 100 days. The number of days is unlikely to be important, it's probably the number of items showing in the root folder that matter. I attached my log from a session where I reproduced this - observe in the log that right clicking the root inventory folder appears to cause a cache purge & it might be the cache purge that is causing the viewer to freeze? You can see the last log lines are 2025-02-03T19:23:58Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes 2025-02-03T19:24:58Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes 2025-02-03T19:25:58Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes 2025-02-03T19:26:58Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes 2025-02-03T19:27:58Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes 2025-02-03T19:28:59Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes 2025-02-03T19:29:59Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes 2025-02-03T19:30:59Z INFO # llfilesystem/lldiskcache.cpp(143) LLDiskCache::purge : Purging cache to a maximum of 1717986918 bytes Feel free to hijack Whirly Fizzle if you can't reproduce this. Freeze also reproduces on ForeverFPS & Firestorm

uploaded texture turns blurry when uploaded yet local version shows fine. I uploaded it twice now wasting 80 lindens :(

this issue happens on some folders created by me before the Preview Image feature released. https://i.imgur.com/0lCMyxH.png

In some cases, 1024 images can be set for the inventory preview image, in other cases, they cannot. When selecting from the texture selection window in the image window, 1024 resolution images can be selected, but when trying to drag and drop from inventory, an error message appears. Which is correct? I would like it to be consistent.

Create a new notecard in your inventory somewhere. Right click to copy it. Go to another folder and right click, select paste as link. Nothing happens. If you edit the notecard so it has something in it (a single x for instance), you can do paste as link just fine. You can also then edit the notecard so it has nothing in it again, and the link carries on working.

Open inventory and create a new folder. right click that folder and select copy. past folder as linked. navigate to original folder and right click> select image. assign an image to that folder. navigate to linked folder and try to double click or right click and find linked. viewer should crash. if viewer does not crash > open the folder that contains the linked folder in "a new window" and repeat step 6 within that new window. viewer will crash video of issue attached Second Life viewer and Firestorm viewer effected

Place a Material within a Prim inventory. Apply it to object faces with LSL ApplyRenderMaterial Function. Edit Material in Prim Inventory. Press "Save". Observe it is not updated. This further complicates things when attempting to use Local Textures. PBR materials exist in two different copies: 1 : Stored inside an inventory.  ( Personal or Prim ) 2 : When applied to an Object, in the object face "Inventory" << reason for these quotes below. This makes sense in the context of an LSL script, or any other editable asset within SL, but those objects appear within the inventory of the Prim when Applied. PBR materials function identically, but there is no UI notification to alert the user of this. When you apply a PBR material to an entity ( logically of course ) it makes a copy of itself, thus letting someone else with full perms adjust it, while the original remains unaltered. Local textures are able to be applied to both In-User-Inventory PBR materials, In-Object-Inventory (the visible one) , as well as In-Face- "Inventory" PBR materials ( that are actively applied to faces) However, you can edit the ones in your personal inventory, as well as the ones in the object inventory, and the ones actively displayed upon the object WILL NOT UPDATE ( as they are in face "Inventory" ) even after "Save" is clicked.   The only time that pressing "Save" on the material that you have chosen to edit, actively updates the visible material is when the Material that is currently being edited resides in the object face "Inventory" .  Personal inventory, and Object Inventory updates are not-re-broadcast until the newly saved material is either dragged and dropped from Inventory >> Face "Inventory" or an LSL script event transfers it from Object Inventory >> Face "Inventory" .  This makes logical sense, when you understand the mechanics of what is taking place, but it does not make user sense; due to the configuration of the UI, and our previous mental patterns regarding how textures are applied don't align with this.  As such a lot of our expectations regarding how things should work do not match reality. While I am unsure precisely what to do about this predicament.  My best suggestion is as follows : I believe Materials residing in the inventory of the object should auto-update all related Face "Inventories" when they are modified and the user clicks the "Save" button on the Material Asset residing within a prim inventory.  This material is discrete and does not have additional copies, unless it is removed so force updating it makes sense.  This has parity with what happens when you delete the Material Asset from the Prim inventory, and it reverts to a pine box. I also believe User-Inventory materials should not be allowed to contain Local Texture links, as this starts to become exceedingly confusing from the end-user perspective.  Either place a large notification on the "Local" Tab of PBR materials with "This item resides in your inventory, and changes will not be updated until re-applied to objects, please place a copy in prim inventory to use this."  or remove the functionality altogether and replace with a similar message.