|
|
|
|
|
[
Permlink
| « Hide
]
Escort DeFarge - 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).
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. 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. 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. An addition to this. We need a MUTE button on permission dialogs, same as we have for being given items.
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 :/
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. 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. 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 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.
Crescent got attacked by a spammer using this a few days ago. I had to relog to get rid of them all.
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.
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).
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.
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. As far as I can repro, only the 2nd and subsequent notify boxes (opening now under the first) are doing this. Patch coming. 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 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/ It's not applied. When are we getting this in the client?
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. 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.
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.
(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. 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. 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.
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.
This will be in the second 1.18.6.x viewer release candidate.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||