• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-2046
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Tofu Linden
Reporter: roberto salubrius
Votes: 32
Watchers: 10
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

Focus is sent to menu/money/notification window

Created: 05/Aug/07 10:23 PM   Updated: 25/Oct/08 06:32 PM
Component/s: User Interface
Affects Version/s: 1.18.3 Release Candidate, 1.18.1.2
Fix Version/s: Source code

File Attachments: 1. Text File 2076_notification_windows_steal_focus.patch (2 kB)

Environment: Windows ( maybe others )
Issue Links:
Duplicate
 
Relates

Linden Lab Issue ID: SL-50808
Patch attached: Patch attached


 Description  « Hide
Description:

Whenever a menu screen pops up ( money transfer, notice, menu, Group message etc )
the focus is changed to the menu screen that just appeared, taking you out of inventory, chats, IM, etc.

How to reproduce it:
Just write and wait until you get a menu pop up, it will change focus.

Potential fix. ( not really a fix but makes it a bit better)
Set money Transfer notices off, Group notices off



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Escort DeFarge added a comment - 11/Aug/07 08:02 AM
This is a repeat bug and is UNBELIEVABLY ANNOYING and a total timewaste. It also takes focus from just MOVING AROUND. Resulting in having to refocus the client window where you were DOING THINGS. (Yes, I am NOT IMPRESSED).

Benja Kepler added a comment - 21/Aug/07 04:38 AM
I don't see why this is a problem.

The purpose of a message box is to give the user a message, and the purpose of giving it focus is to allow the user to click the OK button to confirm that they have seen the message.


Torley Linden added a comment - 21/Aug/07 10:28 AM
Linked to another issue containing blue dialog popup intricacies.

We discussed this at our UI Bug Triage... it'd be good to have more comments and votes because there are clearly differing opinions on it.

Imported for further discussion.


Ryozu Kojima added a comment - 11/Sep/07 02:54 PM
I'm upgrading the priority on this one to major. While I understand there are differing opinions on how this should be handled, I don't believe many have fallen victim to one of it's potential misuses: Permissions request spam.

A scripted object can totally disable a person by requesting permission to animate their avatar at a rate of 10 requests per second. Because the dialog takes focus when it appears, a user is locked into that dialog loop unable to move, speak, interact aside from simple touches, interact with inventory, or many other interface elements. A user trapped by this has no option left except to log off, or teleport home using the keyboard shortcut.

I believe there are multiple fixes necessary to combat this problem.

1) Dialogs should not take focus.

  • Would fix accidental selection of a dialog button by users not paying attention to the screen while typing.
  • Would fix users being more or less totally disabled by a continuous barrage of permissions requests.
    2) Mute (Player, Object, Object by name) should also prevent permission requests.
    3) A mute button should be added in addition to the "Accept" and "Decline" buttons to permission request dialogs.

I'm unsure if items 2 and 3 are already in effect. Last night I was caught in a gray goo permission spam trap during an attack on a sandbox, and nothing short of leaving the area would stop them from coming in.


WarKirby Magojiro added a comment - 12/Sep/07 08:37 PM
An addition to this. We need a MUTE button on permission dialogs, same as we have for being given items.

Funk Schnook added a comment - 15/Sep/07 05:31 PM
Ive never noticed this issue until I started using the 1.18.3 RC. Yeah it can get really annoying. Most times Im typing away and dont even realise that focus was lost after the first word I had typed :/

Cubey Terra added a comment - 16/Sep/07 09:37 AM
This one must be fixed. I don't know when the behaviour changed, but whenever one of those blue dialogs appears, it takes focus from other SL windows. The result is that, if you are typing in chat or scripting, you are constantly interrupted by these popups. Very annoying.

Recently this bug was exploited by a spam bomb that repeatedly requested animation permissions, several times per seconds. The result: anyone within scan range of the griefer object was unable to use the UI. Completely crippling.


Davey Callisto added a comment - 17/Sep/07 12:37 PM
Please remove the focus stealing. It's incredibly frustrating and as Cubey says, completely crippling. This has been a major problem recently with a lot of griefing objects spamming requests for permissions, and thus every time you are typing in chat, IM, or even in the preferences window, these blue popups steal focus and focus on the little >> arrow every time, making it impossible to communicate other than with voice.

You've given griefers a primary way of disrupting us again, and they're using it.


Armand Callisto added a comment - 17/Sep/07 01:24 PM
Dear Torley,
Long time no ZEE! The focus issue in general is an annoyance as many have already posted however it has been in the past and the present a major ENHANCEMENT to SPAM BOMBS and other griefing devices. Many small mechanics in SL can and are used to diable ones ability to remove devices off ones land or property but this single issue all by itself is used by most creators of dasterdly devices as a key component. Not only can it prevent a land owner from resolving the issue but can render even the ON-SITE Lindens helpless to resolve the issue. Today some VALUED and CONCERNED citizens had to resort to crashing the effected sims to resolve a issue involving several devices using this mechanic. Most of these types of griefing devices do not even rely on having to be on the land to effect it so that combined with timed temp replicators that can actually surf the GOO threshold are extreamly annoying and hard to remove (even by the gods). I understand that focus for these CLASS of popups perhaps can not be removed but could we at least allow a user to DISABLE focus borrowing or even disable/block certain types of messages to be able to allow the residents as well as the Linden support staff to work around the issues it can cause?

Yours Truely
Armand "Phil You Still Owe me $5" Callisto


Torley Linden added a comment - 18/Sep/07 11:42 AM
Thanks all for sharing how you feel! This has been annoying me like heck – especially when there's a lot of popups – I hope we can revert this to the older, non-focus-stealing behavior, our Resident eXperience Team will investigate this further.

WarKirby Magojiro added a comment - 19/Sep/07 06:30 AM
Crescent got attacked by a spammer using this a few days ago. I had to relog to get rid of them all.

Debbie Trilling added a comment - 22/Sep/07 08:19 AM
As stated above, this is incredibly annoying & just plain silly many times that is occurs. It presupposes that the dialog box is of more importance than anything you happen to be chatting about, or any movement that you happen to be making.

Funk Schnook added a comment - 22/Sep/07 02:06 PM
I'm changing this to critical. More and more people are starting to use this bug for attacks and spam bombs. This renders the client useless. You cant do anything except shut down the client (just as good as a crash).

Latif Khalifa added a comment - 25/Sep/07 07:36 PM
This is indeed a big annoyance and a good weapon to griefers. The dialogs should not take focus form whatever you're a doing if your moneytree happens to pay $L1 to a newbie.

Nicholaz Beresford added a comment - 26/Sep/07 09:57 AM

This is a side effect of the pop-under change (notify boxes opening under each other instead of on top of each other). Will attempt to fix.


Nicholaz Beresford added a comment - 26/Sep/07 10:18 AM

As far as I can repro, only the 2nd and subsequent notify boxes (opening now under the first) are doing this.

Patch coming.


Nicholaz Beresford added a comment - 26/Sep/07 10:32 AM

Patch here. Solution is to only set the focus, when the moveToBack function is called from user interaction (there is an comment with an assumption (in the moveToBack source) which is no longer true).

I did test the patch in both situation (automatic opening of notifications and clicking them on the yellow next button).

However, the patch also contains the fixes for VWR-2524 because they are related and in the moveToBack function the changes are too close for comfort, so they'll collide either way.


Which Linden added a comment - 26/Sep/07 11:52 AM
(SL-52472 was a dupe of SL-50808)

Nicholaz Beresford added a comment - 30/Sep/07 12:06 PM

Btw, to those who are annoyed about this behavior and willing to use a 3rd part viewer, it's fixed on my BE-q version.
http://nicholaz-beresford.blogspot.com/


Tofu Linden added a comment - 02/Oct/07 04:52 AM
Thanks Nicholaz - applied.

WarKirby Magojiro added a comment - 11/Nov/07 09:20 AM
It's not applied. When are we getting this in the client?

Cubey Terra added a comment - 11/Nov/07 01:40 PM
Today the grid was hit (again) by a replicating permissions spam bomb that exploits this bug. Are we likely to see the fix soon?

Ayu Sura added a comment - 11/Nov/07 08:57 PM
I don't think this bug is "resolved". Even after muting the person, logging off, and tp'ing out, my husband was stuck clicking the animate requests off for about 15 minutes before they went away.

WarKirby Magojiro added a comment - 12/Nov/07 06:59 AM
Ayu. Read it carefully. It is fixed internally, meaning that Lindens have the fix, and have yet to put it in a public release. Since it was marked as such over a month ago though, I think it's getting beyond a joke.

Gillian Waldman added a comment - 13/Nov/07 09:30 AM
It's happening constantly in numerous regions. The only fix is to log off. I would vote for this but voting isn't an option when it's labeled as fixed.

Ordinal Malaprop added a comment - 13/Nov/07 02:17 PM
(a) This needs to be fixed pronto as a matter of urgency. There are reports of it being used in griefing scripts dating from September for heaven's sake - there have been client updates since then - and it was a major factor of recent gridwide attacks. There is no defence against it.

(b) The fact that it is no longer possible to vote for something to indicate its importance when something is marked "resolved internally" is a problem with the Jira as it stands, and this behaviour should be changed. "Resolved internally" is not the same as "resolved". It should be possible to continue voting for what is basically an unresolved issue until it has actually been resolved, to show that this is something which a lot of people care about.


Prokofy Neva added a comment - 30/Nov/07 04:38 AM
Yet another example of something marked RESOLVED with frozen votes that was getting quite a bunch of votes and I would have liked to vote for it.

MORE than annoying – a total crippler. It absolutely harms business. Those suggesting that you should shut off payment and group notices in favour of a workaround to this nonsense must not run any kind of business and spend the entire day in the sandbox.


WarKirby Magojiro added a comment - 30/Nov/07 06:47 AM
For once,. we agree on something, Prokofy. Please send an Im to Tofu linden inworld and tell him to hurry up. This exploit cripples people. He's the one responsible for fixing this, and already has a patch to do so.

Tofu Linden added a comment - 03/Dec/07 12:30 AM
The patch was applied when I said it was, but it's taking ages to propagate to a release. I'm trying to expedite this change.

Tofu Linden added a comment - 03/Dec/07 10:58 AM
This will be in the second 1.18.6.x viewer release candidate.

WarKirby Magojiro added a comment - 05/Dec/07 04:27 PM
This is now publicly available in the new 1.18.6 RC client, and it works perfectly. Thank you Tofu.

This is a great step forward, and massively reduces the problem. But the issue of blue dialogs being used as a weapon cannot truly be defeated until VWR-3561, VWR-3558 and VWR-2502 are all fixed.