Web/Marketplace Bugs

Copied from https://jira.secondlife.com/browse/BUG-235009 ---- What just happened? Search asked me to accept cookies despite previously accepting them What were you doing when it happened? Opening search What were you expecting to happen instead? I expected the saved cookies to remain. I operate no system level adblocker nor had I cleared cache. Other information This happens each time I relaunch the client and open search

exclude demo items via checkbox left side of page set price to 0 - anything else L$ (setting to return only 0L$ items shows it up most) sort by newest first this search... https://marketplace.secondlife.com/products/search?utf8=%E2%9C%93&search%5Blayout%5D=gallery&search%5Bcategory_id%5D=&search%5Bsort%5D=released_at_desc&search%5Bper_page%5D=96&search%5Bkeywords%5D=&search%5Bprice_low%5D=0&search%5Bprice_high%5D=0&search%5Bland_impact_low%5D=&search%5Bland_impact_high%5D=&search%5Bcopy_permission%5D=0&search%5Bmodify_permission%5D=0&search%5Btransfer_permission%5D=0&search%5Blimited_quantities%5D=0&search%5Bis_demo%5D=0&search%5Bis_demo%5D=1 This returns lots of properly set up Demo listing (these are NOT items where the Demo has not been linked to a full version).

Open the web search in the viewer, select places, set the maturity to "Adult" and search for "sex" .. 0 results. Change maturity to GMA and search again, 2010 results, most of them on Adult land. I have no words ... this is so broken / dumb.

This seems to be an intermittent, or random, bug. It's not serious, but it confuses new users. For some users, when they claim a Linden Home on the land page, the TP link which is supposed to take them directly to their new home instead leaves them in the center of the region. Sometimes this also happens when users use the button to copy the SLURL to the clipboard. For most users, this never happens. This forum thread discusses it, and a few people give examples of their setup to try and narrow down the circumstances that trigger the issue. https://community.secondlife.com/forums/topic/515493-cant-find-my-linden-home/#comment-2794000 My apologies if this bug is not in the jurisdiction of the LDPW. Please feel free to move it to the correct category.

I really couldn't find a good category for this thing, so move it as appropriate, if possible. This issue regards the FAQ at https://wiki.secondlife.com/wiki/Linden_Lab_Official:Gacha_policy specifically the example given to the "Conveyor Belt Vendor" rule, both description and image example linked to does not actually say / show the next two (or more) items on the figurative belt, as laid out in the given rule. The text example should be saying that the following items should be made known to the customer, they may not change order after being put on display, but may be randomly selected before display, such as when a timer or a purchase pulls the next item into focus from the belt and a new item is added onto the conveyor belt. Likewise, the image example linked to is currently showing a generic title for the items in the vendor, except for the one in focus: it is not known what the following variants are. The following items should show for example "Dragon Avatar #3" and "Dragon Avatar # 2".

I search "full perm" AND animation AND "bento ears". I get 104 pages of irrelevant search results, including sex poses and vomiting.

https://accounts.secondlife.com/transaction_history/?lang=en-US& ..... This page has been progressively deteriorating over the last few weeks. I encounter 2 problems: 1) While trying to view only 1 day at a time, the page often remains stuck on "More than 1000 results..." or "More than 6000 results..." or "More than 11000 results..." 2) If I finally manage to view all the transactions for a specific day and try to download them I get the error "Internal Server Error - Your request failed to rez." All this happens regardless of which browser I use (Chrome-Firefox-Edge are the ones I tried) and it seems to get worse at the beginning/end of SL Day. I also checked my Internet connection and found no problems. I know the same problem has occurred at other SLSGOs as well

for almost a week I've been trying to send the Partnership and it constantly gives me this error "The resident specified could not be found or may not be an active resident.", the name I write is correct, I've checked about ten times and when they try to send me the Partnership request it gives the same error. it's not a typo because I also tried with another avatar to see if I was doing something wrong but it gives the same error

Hello, when I type outfit or dress in marketplace searches, the results have been the same for days. I would be glad if you could take care of this problem.

I have a "slippy map" interface to the SL map. You can try it at https://www.animats.com/sl/map You can rotate, tilt, and fly over the SL map. Hold down CTRL and left mouse button for that. It gives a nice sense of the scale of the world. It's not accessing the SL maps via Akamai directly. It's going through a second proxy server to work around a problem with cross-origin protection. This works slowly, and if the map is used too much, the proxy server sometimes shuts off. So, as a general service for SL users, it's not reliable. There's a URL that directly accesses the SL map tile service, without a proxy server. That's at https://www.animats.com/sl/map/noproxy.html Right now, that will just produce a blank screen. If you look at browser errors, Firefox reports "CORS missing allow origin". A typical URL https://secondlife-maps-cdn.akamaized.net/map-2-998-1000-objects.jpg will display the image of a map tile. What's going on is that browser rules will allow viewing an image regardless of CORS status (that's grandfathered in), but the same image can't be used with WebGL for rotating, tilting, and perspective. For this to work in standard browsers, an option needs to be set at Akamai. See https://techdocs.akamai.com/api-definitions/docs/cross-origin-resource-sharing-cors for the section that reads: In the Allowed origins text box, enter the hostnames that you want to allow via the Access-Control-Allow-Origin response header. The hostnames that you enter must start with http or https. For detailed hostname syntax requirements, refer to RFC-952 and RFC-1123 specifications. If you did not allow credentials, you can enter the wildcard (*) sign to accept all hostnames. This is 1) obscure, 2) easy to fix, and 3) from a discussion at Server User Group was thought to be fixed already. Previously reported years ago via the JIRA system, but the request has been lost. Thanks.