When pressed mouse left button on the right seek bar the bar doesn't stop where I pressed the cursor. It keeps moving untill it reached one end following the previous direction.




Widget: Gtk
3 years ago
2 years ago


(Reporter: sabbiralam.cse, Unassigned, NeedInfo)



34 Branch

Firefox Tracking Flags

(firefox35 affected, firefox36 affected, firefox37- affected, firefox38- affected, firefox-esr31 unaffected)




3 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150125222008

Steps to reproduce:

I clicked the left button on my mouse on the right seek bar and kept it pressed.

Actual results:

The seek bar keep moving untill it reached the end of the line.

Expected results:

The bar should stop where I pressed the cursor.

Comment 1

3 years ago
[Tracking Requested - why for this release]: regression since Firefox34.0 on Linux
status-firefox35: --- → affected
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox-esr31: --- → unaffected
tracking-firefox37: --- → ?
tracking-firefox38: --- → ?
Component: Untriaged → Event Handling
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Version: 35 Branch → 34 Branch

Comment 2

3 years ago

Suspect: Bug 803633
Blocks: 803633
Component: Event Handling → Widget: Gtk
With seek bar, do you mean scrollbar? Or is this about video controls?

Is there a system pref that changes the click-in-track behavior on Linux?

Comment 4

3 years ago
(In reply to Markus Stange [:mstange] from comment #3)
> With seek bar, do you mean scrollbar? Or is this about video controls?
> Is there a system pref that changes the click-in-track behavior on Linux?


I just install Ubuntu14.04 LTS 32bit, Setting does not change anything.
Install from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/*/*.en-US.linux-i686.tar.bz2 build
Alexander, is this something you might look at since you submitted the patch for bug 803633? 

Markus, do you think this needs to be tracked for 37? Thanks!
Flags: needinfo?(notting)
Flags: needinfo?(mstange)
It's a regression, so it probably should be tracked. I don't really understand the problem well enough to say how important it is.

I'm very confused by this bug. It sounds like bug 803633 had exactly the opposite effect from what the bug description asked for? I'll check in a Linux VM later, but maybe somebody can explain it to me in the meantime.
Flags: needinfo?(mstange)
tracking-firefox37: ? → +
tracking-firefox38: ? → +

Comment 7

3 years ago
If I right understood the problem, it's feature, not a bug, because all latest versions of GTK (in 2 and 3 branches) has this behavior.

Please read comments #12 and #13 in bug803633 for details (note: left button with ui.scrollToClick=0 has same behavior as right button with ui.scrollToClick=1).
This issue doesn't seem critical enough to track for the release as the scrollbar is still usable. If there is a good reason to push for this fix specifically in 37 or 38, please renom with additional justification.
tracking-firefox37: + → -
tracking-firefox38: + → -

Comment 9

2 years ago
For me with natural scrolling enabled, the steps result in scrolling upwards. This may be related to the cause of the issue.
You need to log in before you can comment on or make changes to this bug.