The Strange Version Viewer Window That Opens and Scans

[Prokofy Neva]

@Oz Linden

@Whirly Fizzle

So to the others, let's be scientists and not robots and note that this is definitely not about "media on a prim" as it was captured in an area where there is no "media on a prim" here.

1. The capture is only ONE of the cases of the appearance of this annoyance -- repeat ONE. 

So I have finally succeeded in capturing this phenomenon in the wild  in one of its types of occurences -- and it's not about using Light or any other screen shot.

2. Obviously you can use "Print Screen" but print screen *does not work* on this capture. Also the inworld screenshotting function doesn't work to capture this EITHER. That is, you can see it on the screen, and not just not be quick enough to not get it, it simply does not show up. That's because it is visible inworld while logged on, but happening outside the SL browser?

Yet if I tab down SL I don't see it on my desk top. This may be just a function of "not being quick enough" -- in years past, it was very fast AND had no green lettering visible so you couldn't tell what it was. Now it has green lettering which is indeed about CHECKING new versions.

3. "Being precise" about the wording of this message isn't the issue. It doesn't say SCANNING but it is still a nuisance. I have said multiple times the issue was that it was looking for new versions of the viewer and it shouldn't do that.

4. It appears NOT just at log-on but a half hour, an hour after log-on, while inworld. Why? 

ONE way it happens is if you have reached for a SLURL OUTSIDE the viewer -- which the entire SL set-up always implies you can do -- by drawing it from a blog or even the Destinations pages of the secondlife.com web page.

In this case, we're going from one to another of the 50L Friday stores. So while standing in one 50L Friday store, from SeraphimSL an outside blog about SL events, we grab a SLURL from the ad for 50L for the next store.

5. When that "outside SLURL" is put into your outside browser (in my case Opera which I prefer to all others for various reasons), I get a screen like this, as anyone would on any browser -- the SL map with a "VISIT THIS LOCATION" on it (see first image below).

6. Next, I click on that link VISIT THIS LOCATION and THEN the annoyance occurs -- which I am forced to capture with an outside camera phone because it simply does not register when you SEE it on the screen yet it does not capture inside the SL viewer/inworld (second photo). In fact, you can even see the reflection of me in RL on the computer screen because I am forced to take this with a camera phone.

7. You can see in the next shot that the NEW SLURL from the NEXT store is now ready for teleportation -- THAT is what triggered the annoyance screen checking for versions of the viewer (third image below)

8. So the moral of the story is: if you use a SLURL from outside of SL and click VISIT THIS LOCATION on the SL map produced, that will force Second Life's software to check for the latest version of the viewer, even though you are already logged in and that shouldn't happen. It does that, BTW, WITHOUT giving you a new log-on screen. You get no new log-on screen, only the annoyance of the screen checking for the new version of the browser.

Again, the third picture shows you the new location ready to be teleported from, obtained from the SLURL outside of SL and the VISIT THIS LOCATION map that results from clicking on a SLURL outside of SL.

9. What is the workaround for THIS PARTICULAR INSTANCE BUT NOT ONLY INSTANCE of this annoyance? Never use an outside SLURL. That's an annoyance, because you're supposed to be able to do that without annoyances like CHECKING...coming up in your face, lagging and freezing you, and sometimes crashing you. But whatever, the SLURL can be put in chat, and clicked on from inworld, and then there's no contraptions running and no annoyance. Again, inconvenient, it's much faster and useful to click on a blog or even the Destinations pages on the web page (not the frames inworld) to "go places" in SL but whatever, it's a virtual world, let's not pretend it's all hooked up seemlessly to the rest of the Internet.

10. Would that were the only occasion of this annoyance! It's not! This annoyance of CHECKING screens popping up -- which are very hard to capture because you can't use the inworld screenshot capacity OR the printscreen of your own computer to capture -- that simply doesn't register it. Perhaps Light or Nimbus which works with Opera can -- that's not material. The inability of inworld and Printscreen to even capture a thing you can see on your screen suggests that it is happening "outside the viewer" of course. But then you should be able to see it on your desktop as you do at log on, and I don't. Maybe it's just quicker than you can tab down your SL window? AND if the outside SLURL were the only trigger, you'd never see that screen executing while just flying around over water. And yet I do.

11. So this annoyance also pops up:

1. When crossing sims

2. When teleporting between sims (after you arrive) from a landmark or someone's sent TP

3. When you are just flying around inworld on one sim.

So sure, I can spend hours trying to capture these other forms of the annoyance and try to figure out what may make this happen outside the viewer, in conjunction with my browser Opera, or anything else. BUT

But one can also ask: why is this damn thing triggered all the time just from outside slurls or teleportation or crossing sims? If it is triggered, God bless it, but it can be kept out of the view of the customer as most things are happening in the underpinnings of SL.

And...for extra credit -- why, if you aren't logging on, is it executing at all? It need not. It's feral checking needs to be shut off. Maybe there's a thing that can be set somewhere to undo that by the user, or maybe the Lindens can make it stop doing that.

And yes, for even more extra credit, maybe this only happens with Opera, which isn't used as much as Google Chrome (used by Linden geeks) or Microsoft Edge (used by many average customers). Sure, I can test that but I'm not going to stop using Opera and shut that down just for the sake of this annoyance -- which, I hope I have established, should not be executing like this all the time. It should only execute on log on.

 

 

 

 

Edited February 16, 2018 by Prokofy Neva

[LittleMe Jewell]

I have actually seen either this or something very similar.  First off, I use Firestorm primarily and the SL viewer only sometimes.  Additionally, I have an app installed to force the handling of SLURLs to go to Firestorm.

After I installed the latest update of the SL viewer, when I clicked on a map in the browser (as shown in the screen print above), then the tiny SL Viewer window shown above would flash, but then my Firestorm session was given control of the SLURL the way I wanted.  When I pulled up my SLURL application, it was no longer showing Firestorm as the default SLURL handler and after I reset that, I no longer saw the SL viewer window pop up.  

So my guess is that the SLURL handling is invoking the updater executable rather than the actual SL viewer executable and that is why the window is flashing up briefly.

[Love Zhaoying]

I am better understanding this. Weird that only Prok is reporting it here (except for viewer launch).

[LittleMe Jewell]

23 minutes ago, Love Zhaoying said:

I am better understanding this. Weird that only Prok is reporting it here (except for viewer launch).

There were times where my Firestorm viewer seemed to maintain focus control and I simply saw the SL Viewer icon flash in my task bar.  Thus it is possible that something similar happens to others, but it is not necessarily noticed.

[Oz Linden]

Thanks for the detail, Prokofy.

It isn't our intention that SLURLs would trigger the update check; we'll fix that.

Some of the other cases you mention are harder to explain, especially 

1. When crossing sims
2. When teleporting between sims (after you arrive) from a landmark or someone's sent TP
3. When you are just flying around inworld on one sim.

but I'll alert our QA people to be watching for those.  If you can narrow down a specific circumstance, by all means let us know.

[Whirly Fizzle]

On 16/02/2018 at 9:26 PM, Oz Linden said:

It isn't our intention that SLURLs would trigger the update check; we'll fix that.

There is a fix upstream for this now.
https://bitbucket.org/lindenlab/viewer-451/commits/28cdaded3b3993cdb92ae21922b5aa6523584041

[Love Zhaoying]

6 minutes ago, Whirly Fizzle said:

There is a fix upstream for this now.
https://bitbucket.org/lindenlab/viewer-451/commits/28cdaded3b3993cdb92ae21922b5aa6523584041

The technocommunists will rejoice, Prost!