Closed Bug 1173434 Opened 6 years ago Closed 6 years ago

Add option to return to scrollbar style optimized for desktop in nightly, 20150610

Categories

(Firefox :: Theme, defect)

41 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mozilla, Unassigned)

References

Details

Attachments

(4 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150608152125

Steps to reproduce:

Whenever firefox brings up enough information to require a scrollbar, the scrollbar always defaults to a style optimized for mobile touchscreen.  This is clumsy and inefficient on a desktop with a keyboard and pointing device.  I became annoyed enough to open this bugzilla when I was trying to select fonts in nightly, edit->preferences->content->advanced, and clicked on one of the font selection boxes.


Actual results:

The fonts showed up as a list, but the only way to scroll the list was to use the click to / drag to position scrollbar, or the wheel on the mouse.  I couldn't just click in the scrollbar and have it move up or down a page of content.  I couldn't right click to put the focus in the window, so I could use the arrow keys, or the page-up / page-down keys or home / end keys.  The click to position is very crude with a mouse in a large list.  Pure frustration.


Expected results:

A list comes up that is fully navigable with arrow keys once right clicking has placed the focus in the window; paging keys, home, end, and that clicking in the scrollbar below the marker moves down a page, clicking above the marker moves up a page.  Dragging the marker can still work, but while that works great with a finger, not so much with a pointer.
Confirming on Mac: cannot scroll using a wheel-less mouse because there's no scrollbar and clicking where there should be one does nothing. Unless you have a wheel to start scrolling, or can use the arrow keys to start scrolling (which is awkward in some contexts, such as typing in this <textarea>) you're out of luck. If the focus is on a web page (and not in an <input>) a single up/down arrow brings back the scrollbar, but in a dropdown like the font selection list you have to arrow enough times to get the list to shift before the scrollbars show up.

(I had no problem getting focus and using arrow keys in the font selection box on Mac--reporter is on Linux--but that's a separate side issue to the general usability problems with the current subtle scrollbars, nice-looking though they are).

Gijs: is "Theme" the correct component for this kind of bug? Or is it a Toolkit or Widget bug?
Status: UNCONFIRMED → NEW
Component: Untriaged → Theme
Ever confirmed: true
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Daniel Veditz [:dveditz] from comment #1)
> Confirming on Mac: cannot scroll using a wheel-less mouse because there's no
> scrollbar and clicking where there should be one does nothing. Unless you
> have a wheel to start scrolling, or can use the arrow keys to start
> scrolling (which is awkward in some contexts, such as typing in this
> <textarea>) you're out of luck. If the focus is on a web page (and not in an
> <input>) a single up/down arrow brings back the scrollbar, but in a dropdown
> like the font selection list you have to arrow enough times to get the list
> to shift before the scrollbars show up.
> 
> (I had no problem getting focus and using arrow keys in the font selection
> box on Mac--reporter is on Linux--but that's a separate side issue to the
> general usability problems with the current subtle scrollbars, nice-looking
> though they are).
> 
> Gijs: is "Theme" the correct component for this kind of bug? Or is it a
> Toolkit or Widget bug?

I don't know.

I don't think what you're seeing (no scrollbar on mac because of your OS preferences - you can change those, and Firefox will listen!) and what the reporter are seeing (scrollbar that does click-to-position rather than click-to-pgup/pgdn) are the same.

I don't actually understand what the reporter is seeing because I can't reproduce it and there are no screenshots or further details regarding the system.

The report also says "return to", implying that this is a regression, but I don't think we have recently changed anything here.

comment #0 also says "whenever Firefox brings up enough information to require a scrollbar", and then talks about the preferences only. Does this affect normal webpage scrollbars such as on this page as well? Just the preferences? Just lists in general?

Finally, comment #0 says "I couldn't right click". What do you mean? Are you using a device that doesn't have a right click? ("Expected results" seems to imply that you're not...)

As it is I'm just struggling to understand the report, really. :-(

The only thing I did just notice is that on Nightly I can't see focus rectangles for closed list dropdowns in about:preferences on Linux, which is a bug, but I *can* focus them and use them with the keyboard...

stan, can you clarify, maybe with some screenshots (before/after, if this used to work?)? What build and what flavour of Linux are you using?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(stanl-mozilla)
I can't seem to get a screenshot of the selection window.  The moment I hit any key with the selection window open, it closes.
Flags: needinfo?(stanl-mozilla)
I'm on Fedora 21, x86_64.

Yes, this affects all scrollbars.  Though, on other pages I can left click in an empty section of the window to put focus there, and the navigation keys on the keyboard work.  Not in this selection window.  There seems to be no way to get focus into the window.  Right click is ignored, left click selects.

And your description of the issue is great.
"scrollbar that does click-to-position rather than click-to-pgup/pgdn"
The latter used to be the behavior in firefox, but it changed to the former at some point.  I see this in other apps, and I attribute it to the desire to satisfy mobile users.  What I'm asking for is a way to put focus into the menu window in the advanced font selection screen, and a way to configure firefox to return to the behavior that you call click-to-pgup/pgdn.  It's much more convenient on a desktop that click-to-position.  The code is somewhere in your repository, since firefox used to do that.

Sort of related, is that the color selection screen brought up by the color button, doesn't show any colors in the selection grids.  I've attached a screen shot.
Again, I can't show the actual grid which is all gray, because when it is open the moment I hit a key, it disappears.
(In reply to stan from comment #4)
> I'm on Fedora 21, x86_64.
> 
> Yes, this affects all scrollbars.  Though, on other pages I can left click
> in an empty section of the window to put focus there, and the navigation
> keys on the keyboard work.  Not in this selection window.  There seems to be
> no way to get focus into the window.  Right click is ignored, left click
> selects.
> 
> And your description of the issue is great.
> "scrollbar that does click-to-position rather than click-to-pgup/pgdn"
> The latter used to be the behavior in firefox, but it changed to the former
> at some point.

If you create a new profile ( https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles ) without all those add-ons and your changed preferences, can you still reproduce this?

If so, can you try using mozregression ( http://mozilla.github.io/mozregression/ ) to find out when this changed? Because I don't see this on Nightly on my Ubuntu VM, and so I expect that the behaviour is dependent on an add-on or some OS or GTK pref or whatever.

>  I see this in other apps, and I attribute it to the desire
> to satisfy mobile users.  What I'm asking for is a way to put focus into the
> menu window in the advanced font selection screen, and a way to configure
> firefox to return to the behavior that you call click-to-pgup/pgdn.  It's
> much more convenient on a desktop that click-to-position.  The code is
> somewhere in your repository, since firefox used to do that.
> 
> Sort of related, is that the color selection screen brought up by the color
> button, doesn't show any colors in the selection grids.  I've attached a
> screen shot.

This is bug 1047595, and that sounds like "Override the colors specified by the page with my selections above:" is set to "Always".
Flags: needinfo?(stanl-mozilla)
"The only thing I did just notice is that on Nightly I can't see focus rectangles for closed list dropdowns in about:preferences on Linux, which is a bug, but I *can* focus them and use them with the keyboard..."

I'm not sure I understand this.  What do you mean by focus rectangles?  And what do you mean by "*can* focus them and use them with the keyboard"?

Would a fix of this allow focus to be put into the closed list dropdown?  That would answer one of my issues.  The other is really just a wish for the old behavior as an option.

Thanks for taking the time to look at this.
(In reply to stan from comment #7)
> "The only thing I did just notice is that on Nightly I can't see focus
> rectangles for closed list dropdowns in about:preferences on Linux, which is
> a bug, but I *can* focus them and use them with the keyboard..."
> 
> I'm not sure I understand this.  What do you mean by focus rectangles?

I mean that I can't see where focus is. There is no visual indication of the focus on these dropdowns (but there is on buttons, checkboxes etc... though that might not be visible in your case either because of your color override settings... I'm not sure.)

>  And
> what do you mean by "*can* focus them and use them with the keyboard"?

I mean that I can right-click a drop-down, then hit tab, then hit alt+down-arrow to open a dropdown list.

> Would a fix of this allow focus to be put into the closed list dropdown? 

I'm saying that I can already do this. I don't know why it doesn't work on your machine.
fwiw, see http://askubuntu.com/questions/504733/from-gnome-screenshot-command-line-how-do-you-predefine-the-are for --delay options on screenshot tools so you can get a screenshot of these dropdowns (so you can run that tool with --delay 10 or whatever and then you have 10 seconds to open the dropdown and then just wait until the screenshot is taken). They probably also exist in GUI tools, but this was what a quick search found me.
"This is bug 1047595, and that sounds like "Override the colors specified by the page with my selections above:" is set to "Always"."

It's the same no matter what I select for the override: always, high contrast, never.  A gray grid of squares.

Thanks for pointing me to that bug.  I can follow that to look for progress.

"If you create a new profile"
Next up, I'll try this.
(In reply to stan from comment #10)
> "This is bug 1047595, and that sounds like "Override the colors specified by
> the page with my selections above:" is set to "Always"."
> 
> It's the same no matter what I select for the override: always, high
> contrast, never.  A gray grid of squares.

If you set that to "never", ** and then click OK **, that will change.
"This is bug 1047595, and that sounds like "Override the colors specified by the page with my selections above:" is set to "Always"."

It's the same no matter what I select for the override: always, high contrast, never.  A gray grid of squares.

Thanks for pointing me to that bug.  I can follow that to look for progress.

"If you create a new profile"
Next up, I'll try this.
Collisions caused the duplication in comment 12.  Anyway I'll try your suggestion.  I was also able to capture delayed screenshots.  Which I'll be attaching.

And then the new profile.
Flags: needinfo?(stanl-mozilla)
"If you set that to "never", ** and then click OK **, that will change."
Confirmed.  Color grids show up then.  A workaround.
This shows the menu when the dropdown is open.
This is the colors menu of the font selection in firefox with the all gray color grid open.
With a new profile the closed list dropdown was automatically in focus.  In fact, the focus could not leave it.  So this isn't really a bug, since it is my configuration causing the problem, not the underlying behavior in firefox.  

But the scrollbar was still the click-to-position instead of click-to-pgup-pgdn.  I'll look at the regression testing, though I'm not sure when the behavior switch actually occurred.  Probably years.  28?  I'll play around with it.
Here is the final result of the mozregression.  Is that slick or what?  Wonderful tool.  Anyway, I only tested the behavior of the dropdown menu scrollbar in the advanced font selection window.  It turns out that this behavior only started last year, between 20140814 and 20140815.  mozregression couldn't narrow it any further than that.  I have the hg repository installed, and can probably do a local bisection on those two days, but it takes ~ 1 hr for each compile, so I would rather not.  Is 1 day close enough?

12:33.40 LOG: MainThread Test Runner INFO Running nightly for 2014-08-15
12:43.90 LOG: MainThread Test Runner INFO Launching /tmp/tmpmu8GIK/firefox/firefox
12:43.91 LOG: MainThread mozversion INFO application_buildid: 20140815030202
12:43.91 LOG: MainThread mozversion INFO application_changeset: c9f8cc9ce89c
12:43.91 LOG: MainThread mozversion INFO application_display_name: Nightly
12:43.91 LOG: MainThread mozversion INFO application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
12:43.91 LOG: MainThread mozversion INFO application_name: Firefox
12:43.91 LOG: MainThread mozversion INFO application_repository: https://hg.mozilla.org/mozilla-central
12:43.91 LOG: MainThread mozversion INFO application_vendor: Mozilla
12:43.91 LOG: MainThread mozversion INFO application_version: 34.0a1
12:43.91 LOG: MainThread mozversion INFO platform_buildid: 20140815030202
12:43.91 LOG: MainThread mozversion INFO platform_changeset: c9f8cc9ce89c
12:43.91 LOG: MainThread mozversion INFO platform_repository: https://hg.mozilla.org/mozilla-central
12:43.91 LOG: MainThread mozversion INFO platform_version: 34.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): bad
13:17.61 LOG: MainThread Bisector INFO Narrowed nightly regression window from [2014-08-14, 2014-08-16] (2 days) to [2014-08-14, 2014-08-15] (1 days) (~0 steps left)
13:17.61 LOG: MainThread Bisector INFO Got as far as we can go bisecting nightlies...
13:17.61 LOG: MainThread Bisector INFO Last good revision: 5299864050ee
13:17.61 LOG: MainThread Bisector INFO First bad revision: c9f8cc9ce89c
13:17.61 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5299864050ee&tochange=c9f8cc9ce89c

13:17.61 LOG: MainThread Bisector INFO ... attempting to bisect inbound builds (starting from 4 days ago, to make sure no inbound revision is missed)
13:18.14 LOG: MainThread Bisector INFO Getting inbound builds between 70be728521e3 and c9f8cc9ce89c
13:29.08 LOG: MainThread Bisector INFO No inbound data found.
13:29.08 LOG: MainThread Bisector INFO There are no build dirs on inbound for these changesets.
(In reply to stan from comment #18)
> Here is the final result of the mozregression.  Is that slick or what? 
> Wonderful tool.

Yes, it's pretty neat. :-)

> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=5299864050ee&tochange=c9f8cc9ce89c

Looks like bug 803633 to me. That says it's respecting a new GTK+ system preference, which would explain why you're saying "more and more" applications are doing this. It sounds like you may want to set the "gtk-primary-button-warps-slider" gtk pref to false. I don't know how to do that because I don't know much about GTK, but there we are. The first comment there also suggests that right clicking in the scrollbar might do what you want. The same might go for holding down shift when you click (as far as I can tell from reading the code quickly, I could be wrong).

Because we're essentially obeying a system-level pref, I don't think there's much else Firefox should be doing here... does that sound right?
Blocks: 803633
Flags: needinfo?(stanl-mozilla)
Yes, it looks like this was a spurious bug from firefox's point of view.  firefox is working as designed, and correctly.  It's my system configuration causing the problem.

Thanks for all your help.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(stanl-mozilla)
Resolution: --- → INVALID
In case anyone else running linux and firefox has this problem, I did two things, and the drop down menu box in font selection advanced started working properly.  The scrollbar became click-to-pgup-pgdn, and the focus was in the menu, though there was no highlight.  The up-down arrow keys worked, as did pgup and pgdn, and home and end.  Automatically.

First, I used the suggestion from the arch wiki at 
https://wiki.archlinux.org/index.php/GTK%2B
~/.config/gtk-3.0/settings.ini

[Settings]
gtk-primary-button-warps-slider = false
except I changed it to =0 like the rest of the settings in the file.

And from comment 42 in
https://bugzilla.mozilla.org/show_bug.cgi?id=803633

Note, I figured a way that works for all gtk 2.0 applications while keeping Adwaita:

Create a $HOME/.themes/Adwaita/gtk-2.0/gtkrc file with the following content:

include "/usr/share/themes/Adwaita/gtk-2.0/gtkrc"
gtk-primary-button-warps-slider = 0

Now firefox works, but as the arch wiki says, not all applications respect this setting.  So it doesn't fix everything with this behavior.
You need to log in before you can comment on or make changes to this bug.