Accessibility degradation due to Bug 1621570
Categories
(Firefox :: Address Bar, defect)
Tracking
()
People
(Reporter: justin, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
It is very disappointing that Mozilla has chosen to ignore its users by closing comments on that bug, especially as the official responses contain some misinformation and hubris.
"This is expected, to put text in the primary selection you can triple click, to put the cursor at a certain point just click twice, like on any other OS or common browser."
I'm not sure what this is trying to say, but for me, triple click selects all again, clicking twice selects the token nearest to the cursor, so clearly not like on any other OS. What is this vague reference to a "common browser"? Do you mean Chrome?
"It was a special behavior only implemented for Linux"
This is blatantly incorrect. Prior to 75, browser.urlbar.clickSelectsAll: False was working for me on Windows. In fact, I was using Firefox on Windows when I discovered that this behavior had been removed. As many of the other commenters have said, as a technical user, I am routinely editing the URL. Having to fight with the selection each time is really disruptive.
"The prefs were causing broken edge cases complicate to handle, taking into account all the possible pref combinations"
I can understand this, but at least provide an unsupported workaround. Can this behavior even be changed with a plugin, or do you plan to reallow the feature after the "evolv[ing] things"?
"While the final words have not yet been spoken, I'm now restricting comments on this bug because I think most had the possibility to express feedback, concerns and workarounds."
I looked over the comments many times and saw no real workarounds. Are there any? I would even be willing to learn and write my own plugin if I have to. Are there no keyboard shortcuts?
"This is totally unrelated, we made that change for accessibility reasons, and it's not related to this change."
I am trying to not respond in anger, but I find this comment somewhat ironic and exceedingly tone-deaf. I am high functioning autistic, so sundry stimuli provoke extreme discomfort for me. I used to have to disassemble my phones and physically remove the vibrator, for example, because android for a long time didn't allow for a global disable of vibrations.
I (and thousands like me) have been living with this urlbar issue for months, trying unsuccessfully to adapt, but each time (100+ times/day) irritated at how it slows me down in my job and interrupts my focus. I find myself hesitating now, contrary to your claims, clicking into any other text box or text field, trying to remember where click selects all and where it doesn't.
In general, Google's UI choices seem to have been calibrated to exact maximum irritation for my autistic sensibilities. Yet, as I implied earlier, and to their great credit, the Android team added two configs in their accessibility settings to disable animations and vibrations across the whole OS, and every app that lives on it. Why can't Mozilla support one different functional mode for the URLbar? Does it really require so many testing resources? In so many areas of my life I expend great effort to conform and appear intellectually normal, but at least let me be myself on my own computer.
|
||
Updated•4 years ago
|
|
||
Comment 1•4 years ago
|
||
As said in the original bug, we keep monitoring feedback and we'll see what to do.
But please, don't file duplicates of a bug requesting the same thing, it won't go differently than the original report unless it brings completely new and unheard points.
When you do not want duplicate bugs, do not restrict the comments for the main bug.
You could reopen it and reopen the comments. If and how it gets resolved is another question, but currently you're limiting an important forum for many people who have problems with the new default that does not even has an opt-out.
And there are still many problems. Try to use the selection clipboard on Linux and you'll see that this became much more complicated with the new behaviour. At least the single click does not copy to this clipboard (this would be a serious bug), but actually copying to it then means deselecting and selecting again. I guess the feature was developed with Windows in mind and not tested enough by experienced Linux users.
|
||
Comment 3•4 years ago
|
||
Marco, could you direct us to appropriate communication channel you currently use for monitoring said feedback?
You stated clearly that Bugzilla reports are either not suitable or oversaturated in this regard at this moment, so mentioning such channel after freezing / locking comments would perhaps prevent creations of this kind of duplicates.
|
|
||
Comment 4•4 years ago
|
||
It is totally uderstandable if a new user didn't find the original report and filed a new duplicate, but copying the same stuff from the original bug looks pointless. There's already plenty of dupes with open comments.
The product has a Report Feedback option in the Help menu, there are public forums that are normally visited by Mozilla employees (The Firefox Reddit, Mozillazine, for example), and there is a direct messaging service (Matrix) where you can directly speak with other people from the community and developers.
That said, the problem is clear to everyone at this point, so it's just matter of deciding what to do and when.
The report feedback option does not get you an answer and you have no idea if it gets ignored (I never saw that some feedback there achieved any change).
The forums may be an option, but we're talking here about a bug/feature request/regression tracking that is what a bugtracker is made for and not a forum.
Chat is no good option, as it moves the tracking of an issue to a personal discussion. Even when a chatlog is archived, it is not well-suited for tracking the discussion and the changes that were made or not made.
That said, the problem is clear to everyone at this point, so it's just matter of deciding what to do and when.
People are adding their thoughts, votes and discussion here, because nothing happend, yet. Mozilla decided to stop the discussion, without an resolution of the issue, even when more and more duplicates keep coming in.
When you close the discussion in the main bug, you should not assign other bugs as duplicates to move the discussion there, because the discussion there is locked.
At least there is an overview about the other bug, but with "Duplicate of this bug: 1653688" it is no good overview as not even the headline is cited (except in the tooltip). And duplicates often do not have a meaningful headline at all.
So unlock the discussion there and direct people from duplicates to the main bug. Consider reopening the bug, as there obviously is a need for that feature / removal of the new feature / option to enable or disable the feature.
Description
•