1294707 - Since FF48 I can no longer use mouse click/drag for scrolling

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Toolbar, defect, P2)

Description

[fox4ever]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

Update to FF48 on both devices with Android 4.4.2 and 5.1


Actual results:

Click-Drag in webpage is marking texts


Expected results:

Since as far as I can remember, my external keyboard and air mouse use to scroll up and down in pages when I click-drag up and down. Since FF48 on both an android 4.4.2 and 5.1 devices, the click-drag now is marking text which makes mouse base browsing near impossible.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

[Tracking Requested - why for this release]: regression from apz

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Is this something we actually want to support? My default position is that mouse on Android should behave roughly the same as mouse on desktop - that is, dragging the mouse should do text selection rather than panning. If your mouse has a wheel you should be able to use that to scroll.

ni? to antlam for UX opinion.

Comment 3

[fox4ever]

"My default position is that mouse on Android should behave roughly the same as mouse on desktop" But it never did behave like a desktop before. Why was it changed in FF48?

Plus all other android apps have the grab and move/scroll behavior even the native browser, PLEASE BRING IT BACK to where it was. Most external keyboards and air mice compatible with android devices do not have a SCROLL wheel.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

(In reply to fox4ever from comment #3)
> "My default position is that mouse on Android should behave roughly the same
> as mouse on desktop" But it never did behave like a desktop before. Why was
> it changed in FF48?

It changed as a side-effect of changing our panning implementation. I think bug 1251346 is where the change was made that caused the divergence between the old panning implementation and the new one. In the new one we explicitly treat Android touch events with TOOL_TYPE_MOUSE as mouse events, whereas in the old implementation we just treated them as touch events.

Comment 5

[fox4ever]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #4)
> In the new one we explicitly
> treat Android touch events with TOOL_TYPE_MOUSE as mouse events, whereas in
> the old implementation we just treated them as touch events.

I see, can we have a user configurable parameter TYPE_MOUSE with the option to be "mouse events" or "touch events"? It's a shame the add-on "grab and drag" does not work on Android FF. Because it does exactly what we are looking for.

Comment 6

[James Willcox (:snorp) ([e-mail]) (he/him)]

Randall if you get a chance could you look at this and see what Chrome and other apps do?

Comment 7

[fox4ever]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #6)
> Randall if you get a chance could you look at this and see what Chrome and
> other apps do?

I hate Chrome, that's why I use FF... But I just installed it on my Android devices to check. Chrome also do click/scroll and not mark text. ie same as FF 47 and prior versions.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

If we decide to change this back it should be pretty straightforward, we just need to stop special-casing the TOOL_TYPE_MOUSE at [1]. There might be some test failures from the APZ mochitests that synthesize mouse inputs though, in which case we can just disable test_group_mouseevents.html on Android.

[1] http://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/gecko/gfx/NativePanZoomController.java#167

Comment 9

[Randall Barker [:rbarker]]

Attachment: 0001-Bug-1293472-Part-4-Test-that-single-frame-and-animated-decodes-can-coexist-for-the-same-image.-r-edwin-16081816-c7bab65.patch

While I don't want to revert the scrolling behavior, adding a pref for legacy scrolling for the rare device that does not have a scroll wheel seems reasonable.

Comment 10

[Randall Barker [:rbarker]]

Comment on attachment 8782686 [details] [diff] [review]
0001-Bug-1293472-Part-4-Test-that-single-frame-and-animated-decodes-can-coexist-for-the-same-image.-r-edwin-16081816-c7bab65.patch

Uploaded wrong patch

Comment 11

[Randall Barker [:rbarker]]

Attachment: 0001-Bug-1294707-Added-ui.scrolling.legacy_mouse_scrolling-pref-so-that-legacy-mouse-scrolling-may-be-enabled-in-Fennec-r-snorp-16081816-bbb29fc.patch

Comment 12

[fox4ever]

(In reply to Randall Barker [:rbarker] from comment #11)
> Created attachment 8782688 [details] [diff] [review]
> 0001-Bug-1294707-Added-ui.scrolling.legacy_mouse_scrolling-pref-so-that-
> legacy-mouse-scrolling-may-be-enabled-in-Fennec-r-snorp-16081816-bbb29fc.
> patch

The use of "legacy-mouse" is misleading. There is nothing legacy with state of the art Android TVs and Android media players which are all operated by remote controls keyboards/touch-pads/air mice all without scroll wheels. I don't think these devices qualify as rare. They are not as prevalent as phones or tablet but they are current hardware with a fairly large community of users. This is probably why most other apps except for text editors use scroll as default.

Comment 13

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Randall Barker [:rbarker] from comment #9)
> Created attachment 8782686 [details] [diff] [review]
> 0001-Bug-1293472-Part-4-Test-that-single-frame-and-animated-decodes-can-
> coexist-for-the-same-image.-r-edwin-16081816-c7bab65.patch
> 
> While I don't want to revert the scrolling behavior, adding a pref for
> legacy scrolling for the rare device that does not have a scroll wheel seems
> reasonable.

Let's hold off on adding a pref. I'd like us to be more diligent about these preferences we're adding as it easily spirals into issues down the line.

I'm going to NI Barbara here for her product input as well.

From a UX point of view I think we should match the system. 

Click + drag should highlight. Just like it is on phones - long=press + drag.

But, just "dragging" (or 'flicking' as the gesture mostly resembles) should pan the page.

Comment 14

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #8)
> If we decide to change this back it should be pretty straightforward, we
> just need to stop special-casing the TOOL_TYPE_MOUSE at [1]. There might be
> some test failures from the APZ mochitests that synthesize mouse inputs
> though, in which case we can just disable test_group_mouseevents.html on
> Android.
> 
> [1]
> http://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/
> main/java/org/mozilla/gecko/gfx/NativePanZoomController.java#167

Just saw this, will this change affect anything else?

Comment 15

[Kartikaya Gupta (email:[e-mail])]

(In reply to Anthony Lam (:antlam) from comment #14)
> 
> Just saw this, will this change affect anything else?

Not sure what you're asking. The test failures that will result are not really important, and shouldn't block doing the "right thing" whatever we decide that to be.

Comment 16

[fox4ever]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #15)
> (In reply to Anthony Lam (:antlam) from comment #14)
> shouldn't block doing the "right thing" whatever we decide that to be.

Android running as "Desktop" we can get regular connected or wireless table mice with scroll wheels. FF Fine as it is.
Android running on phones and tablets - FF Touch events works fine as it is.

The problem is with Android running TV boxes and media players with basic remote controls / keyboard and/or mouse. All other applications including browsers are configured to drag-scroll instead of marking text . This is to mimic touch screens behavior without actually touching the screen. To add to the problem, which is not FF fault, devices OSs does not recognize the arrow keys events on the remote when it is running as a mouse. So without the drag-scroll and the lost of arrow keys we loose all ability to see beyond the display. Which make apps without scroll bars such as FF for Android unusable.

Comment 17

[Randall Barker [:rbarker]]

Attachment: 0001-Bug-1294707-Fennec-on-Android-TV-reverts-to-click-and-drag-for-scrolling-16081915-0e77991.patch

This patch attempts to detect Android TV UI and reverts to click and drag for scrolling. I don't have an Android TV so this is untested. I place an apk here: http://people.mozilla.org/~rbarker/fennec-51.0a1.atv.apk (40MB) if any one with an Android TV wants to test it.

Comment 18

[fox4ever]

(In reply to Randall Barker [:rbarker] from comment #17)
> This patch attempts to detect Android TV UI and reverts to click and drag
> for scrolling. I don't have an Android TV so this is untested. I place an
> apk here: http://people.mozilla.org/~rbarker/fennec-51.0a1.atv.apk (40MB) if
> any one with an Android TV wants to test it.

Many thanks! I have 3 different boxes from 2 vendors. I will try them all and report. back.

Comment 19

[fox4ever]

(In reply to Randall Barker [:rbarker] from comment #17)
> Created attachment 8783093 [details] [diff] [review]
> http://people.mozilla.org/~rbarker/fennec-51.0a1.atv.apk (40MB) if
> any one with an Android TV wants to test it.

Does not work on Himedia Q10 Pro with Android 5.1 - Still marking text
Same for Mygica AC1900 (Android 5.0), MyGica 1800 (Android 4.4.2) and MyGica 582 w Android 4.4.2.

But it is not all lost. The up down arrows are working.

Ask anything about the setup, the installation, If you want me to try some parameters... I'm all yours.

Comment 20

[Randall Barker [:rbarker]]

(In reply to fox4ever from comment #19)
> (In reply to Randall Barker [:rbarker] from comment #17)
> > Created attachment 8783093 [details] [diff] [review]
> > http://people.mozilla.org/~rbarker/fennec-51.0a1.atv.apk (40MB) if
> > any one with an Android TV wants to test it.
> 
> Does not work on Himedia Q10 Pro with Android 5.1 - Still marking text
> Same for Mygica AC1900 (Android 5.0), MyGica 1800 (Android 4.4.2) and MyGica
> 582 w Android 4.4.2.
> 
> But it is not all lost. The up down arrows are working.
> 
> Ask anything about the setup, the installation, If you want me to try some
> parameters... I'm all yours.

Are these devices using the Android TV UI or are they a tablet or phone UI? If they are using the TV UI then I'm not sure what I can do with out access to a device.

Comment 21

[Randall Barker [:rbarker]]

(In reply to fox4ever from comment #19)
> (In reply to Randall Barker [:rbarker] from comment #17)
> > Created attachment 8783093 [details] [diff] [review]
> > http://people.mozilla.org/~rbarker/fennec-51.0a1.atv.apk (40MB) if
> > any one with an Android TV wants to test it.
> 
> Does not work on Himedia Q10 Pro with Android 5.1 - Still marking text
> Same for Mygica AC1900 (Android 5.0), MyGica 1800 (Android 4.4.2) and MyGica
> 582 w Android 4.4.2.
> 
> But it is not all lost. The up down arrows are working.
> 
> Ask anything about the setup, the installation, If you want me to try some
> parameters... I'm all yours.

Sorry, just to verify you were running the correct application, did you run "fennec rbarker"?

Comment 22

[fox4ever]

(In reply to Randall Barker [:rbarker] from comment #20)
> Are these devices using the Android TV UI or are they a tablet or phone UI?
> If they are using the TV UI then I'm not sure what I can do with out access
> to a device.

It looks like Standard android interface. But I bet they are phone UI's As I recall one putting the no sim-card inserted alert. 
How can I validate what kind of UI?

But why don't you put a switch to force CLICK/DRAG? And again, pre FF48 was doing like all the others for these types of box. CLICK/DRAG works in the OS UI, in most apps and browser.

Comment 23

[fox4ever]

(In reply to Randall Barker [:rbarker] from comment #21)
> (In reply to fox4ever from comment #19)
> 
> Sorry, just to verify you were running the correct application, did you run
> "fennec rbarker"?

Yes :-)

Comment 24

[Randall Barker [:rbarker]]

(In reply to fox4ever from comment #22)
> (In reply to Randall Barker [:rbarker] from comment #20)
> > Are these devices using the Android TV UI or are they a tablet or phone UI?
> > If they are using the TV UI then I'm not sure what I can do with out access
> > to a device.
> 
> It looks like Standard android interface. But I bet they are phone UI's As I
> recall one putting the no sim-card inserted alert. 
> How can I validate what kind of UI?
> 
> But why don't you put a switch to force CLICK/DRAG? And again, pre FF48 was
> doing like all the others for these types of box. CLICK/DRAG works in the OS
> UI, in most apps and browser.

Okay, my fix would probably only work if the device is using the Android TV interface.

Comment 25

[Gerry Chang [:gchang]]

Track 49+/50+/51+ as this is a regression from APZ and changes click/drag for scrolling behavior.

Comment 26

[Kartikaya Gupta (email:[e-mail])]

I think we're still waiting for UX/product clarification here.

Comment 27

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Sorry, this thread is a bit hard to follow for me. Hopefully I can clear some things up.

If this is a bug (and it sounds like it from the initial comments) then we should fix it to the previous experience. Unless I am missing something? If click-and-drag was for scrolling, how does highlighting text work?

Comment 28

[Randall Barker [:rbarker]]

(In reply to Anthony Lam (:antlam) from comment #27)
> Sorry, this thread is a bit hard to follow for me. Hopefully I can clear
> some things up.
> 
> If this is a bug (and it sounds like it from the initial comments) then we
> should fix it to the previous experience. Unless I am missing something? If
> click-and-drag was for scrolling, how does highlighting text work?

This change was intentional. The idea being as Android becomes more prevalent on desktop style devices and people start using mice and touch pads with Fennec we wanted the experience to match desktop. This change was introduced when we switched from JPZ to APZ. It would be nice to know how many users are actually using Fennec on a TV which is the only place this might be considered a regression. I tried to detect when Fennec was running on a TV and revert to the old behavior however it appears most of these "Android TV" boxes are not using the actual Android TV interface so detection was not possible because they just look like a phone to Fennec.

Comment 29

[fox4ever]

(In reply to Randall Barker [:rbarker] from comment #28)
 
> This change was intentional. The idea being as Android becomes more
> prevalent on desktop style devices and people start using mice and touch
> pads with Fennec we wanted the experience to match desktop. This change was
> introduced when we switched from JPZ to APZ. It would be nice to know how
> many users are actually using Fennec on a TV which is the only place this
> might be considered a regression. I tried to detect when Fennec was running
> on a TV and revert to the old behavior however it appears most of these
> "Android TV" boxes are not using the actual Android TV interface so
> detection was not possible because they just look like a phone to Fennec.

There is a whole line of products of Android devices use for media players with its non-techie community. Android TV interface have limitations that these boxes don't have. As this community is not technical they don't know where to complain about it. On some of their forums, the answer is DO NOT USE FF48 because it's broken. Maybe Android desktops are growing in popularity and I understand the reason to have a mouse that act the same way for desktop users regardless on the OS. But there is an already established community were click-drag for scroll is prevalent in every aspect of the User Interface. Prior to 48 FF mouse behavior was standard and appreciated. Now it's non-standard and kills FF usability on all theses devices operated with air mice and alike. Think touch screen but the screen is your TV and you operate it from your couch. 

Google image "android air mouse" you will find hundreds of mice and remotes. Next to none with scroll wheel. Do you think they would make so many products for a narrow nice market? This is bigger than you think. Please quit diminishing the importance of our community and the impact this regression is doing on us. This change makes FF inoperable.

http://i0.wp.com/androidpcreview.com/wp-content/uploads/2015/08/best-airmouse-size-comparison.jpg

Comment 30

[Kartikaya Gupta (email:[e-mail])]

(In reply to Randall Barker [:rbarker] from comment #28)
> I tried to detect when Fennec was running
> on a TV and revert to the old behavior however it appears most of these
> "Android TV" boxes are not using the actual Android TV interface so
> detection was not possible because they just look like a phone to Fennec.

Can we detect it some other way? Maybe the InputDevice on the MotionEvent exposes whether or not there is a wheel? Then we could do drag-scroll for devices that don't have wheels.

Comment 31

[Kartikaya Gupta (email:[e-mail])]

And I guess if we can't find some way to detect it, then we should probably just revert to the old behaviour.

Comment 32

[fox4ever]

(In reply to Randall Barker [:rbarker] from comment #28)
> It would be nice to know how  many users are actually using Fennec on a TV which is the only place this
> might be considered a regression.

Quite a few, there is a whole industry supporting it. How can I demonstrate it to you without been tagged with "advocacy"?

Comment 33

[Kartikaya Gupta (email:[e-mail])]

You could try to find actual numbers or hard data instead of conjecturing. Ideally the percentage of Firefox for Android installs affected, but some approximation thereof would be good too.

Comment 34

[Randall Barker [:rbarker]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #30)
> (In reply to Randall Barker [:rbarker] from comment #28)
> > I tried to detect when Fennec was running
> > on a TV and revert to the old behavior however it appears most of these
> > "Android TV" boxes are not using the actual Android TV interface so
> > detection was not possible because they just look like a phone to Fennec.
> 
> Can we detect it some other way? Maybe the InputDevice on the MotionEvent
> exposes whether or not there is a wheel? Then we could do drag-scroll for
> devices that don't have wheels.

This might work. I created a version of Fennec that looks at the InputDevice and check is if has an AXIS_VSCROLL in it's MotionRange. I uploaded this apk here for testing:

https://people.mozilla.com/~rbarker/fennec-51.0a1.atv2.apk 

I will not surprise me if this does not work either but it was a simple enough change to try.

Comment 35

[fox4ever]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #33)
> You could try to find actual numbers or hard data instead of conjecturing.
> Ideally the percentage of Firefox for Android installs affected, but some
> approximation thereof would be good too.

This data is not readily/easily available. But as long as we agree this a regression then lets stick with it. 
Because calling it "rare" or "not that rare" are both conjecturing. Both ends should be treated as "advocacy". 

Facts according to Google: There is 1.4 Billion active Android devices across 18 000 types. Let say the "TV" type represent only 1%, that is 14 million devices affected. Most of the cable cutters are using such devices. Is 14 million devices affected enough to consider it a "bug"?

Comment 36

[fox4ever]

(In reply to Randall Barker [:rbarker] from comment #34)
Thanks Randall for the attempt.

Doesn't work... Still marking text.

> 
> This might work. I created a version of Fennec that looks at the InputDevice
> and check is if has an AXIS_VSCROLL in it's MotionRange. I uploaded this apk
> here for testing:
> 
> https://people.mozilla.com/~rbarker/fennec-51.0a1.atv2.apk 
> 
> I will not surprise me if this does not work either but it was a simple
> enough change to try.

Comment 37

[Kartikaya Gupta (email:[e-mail])]

We should revert the behaviour to not special-case TOOL_TYPE_MOUSE. Randall, do you want to write the patch or should I?

Comment 38

[Randall Barker [:rbarker]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #37)
> We should revert the behaviour to not special-case TOOL_TYPE_MOUSE. Randall,
> do you want to write the patch or should I?

I was told to wait for UX to decide what to do.

Comment 39

[James Willcox (:snorp) ([e-mail]) (he/him)]

I'm more concerned about our behavior on things like the Pixel C than a TV right now. Eugen you have a Pixel C, right? Can you try using a mouse and see how well things work?

Comment 40

[James Willcox (:snorp) ([e-mail]) (he/him)]

Barbara, ditto for chromebook (see comment #39)

Comment 41

[Eugen Sawin [:esawin]]

Tested on a Pixel C using Firefox 48:

* Scroll wheel scrolls page content on both, Chrome and Firefox
* Dragging (left mouse button pressed while moving) scrolls page content on Chrome, selects text on Firefox or no effect if content is not text
* Double-clicking enables text selection on Chrome, no effect on Firefox

Effectively, there is no way to scroll on Firefox without a scroll wheel (excluding scrolling via text selection).

Comment 42

[James Willcox (:snorp) ([e-mail]) (he/him)]

I guess we should basically emulate Chrome's behavior here, since there is no guarantee a mouse device will have a scroll wheel (like a trackpad maybe).

Comment 43

[fox4ever]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #42)
> I guess we should basically emulate Chrome's behavior here, since there is
> no guarantee a mouse device will have a scroll wheel (like a trackpad maybe).

Whatever works but it's not just "emulating" Chrome. Every single apps native or not (not just browsers) on devices operated by remote operates that way. This is how the GUI works to move around screens. You keep the click pressed and scroll up-down left-right as you please.

Comment 44

[Barbara Bermes [:barbara] - NI please!]

Click/drag for scrolling down with a mouse on my Asus Chromebook with Firefox 48 Android app installed, does not do anything.

Comment 45

[Randall Barker [:rbarker]]

Attachment: 0001-Bug-1294707-Revert-Fennec-so-that-it-treats-mouse-clicks-as-touch-events-16091611-f8bb754.patch

Comment 46

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 8792055 [details] [diff] [review]
0001-Bug-1294707-Revert-Fennec-so-that-it-treats-mouse-clicks-as-touch-events-16091611-f8bb754.patch

Review of attachment 8792055 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks! Please request uplift to 50 as well

Comment 47

[Randall Barker [:rbarker]]

Attachment: 0002-Bug-1294707-Part-2-Disable-mouse-event-mochi-tests-on-Android-now-that-Fennec-no-longer-supports-native-mouse-events-r-kats-16091613-612ad11.patch

Comment 48

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/70565fcf2727
Part 1, Revert Fennec so that it treats mouse clicks as touch events r=kats
https://hg.mozilla.org/integration/mozilla-inbound/rev/41d0da5ec5e8
Part 2, Disable mouse event mochi tests on Android now that Fennec no longer supports native mouse events r=kats

Comment 49

[Randall Barker [:rbarker]]

Comment on attachment 8792055 [details] [diff] [review]
0001-Bug-1294707-Revert-Fennec-so-that-it-treats-mouse-clicks-as-touch-events-16091611-f8bb754.patch

Approval Request Comment
[Feature/regressing bug #]: Remove mouse event support in Fennec so that click/dragging will scroll instead of select text so that mice without scroll wheels can scroll pages again.
[User impact if declined]: People using mice with out scroll wheels will not be able to scroll pages. Air mice used with TV android devices typically do not have scroll wheels.
[Describe test coverage new/current, TreeHerder]: Disable mouse event tests since Fennec no longer generates mouse events.
[Risks and why]: Very low, this just reverts Fennec to the scrolling behavior found in 47 (prior to enabling APZ). 
[String/UUID change made/needed]: none.

Comment 50

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/70565fcf2727
https://hg.mozilla.org/mozilla-central/rev/41d0da5ec5e8

Comment 51

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8792055 [details] [diff] [review]
0001-Bug-1294707-Revert-Fennec-so-that-it-treats-mouse-clicks-as-touch-events-16091611-f8bb754.patch

50 moved to Beta today.

Comment 52

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hello fox4ever, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!

Comment 53

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8792055 [details] [diff] [review]
0001-Bug-1294707-Revert-Fennec-so-that-it-treats-mouse-clicks-as-touch-events-16091611-f8bb754.patch

Fixes a recent regression, Beta50+

Comment 54

[fox4ever]

(In reply to Ritu Kothari (:ritu) from comment #52)
> Hello fox4ever, could you please verify this issue is fixed as expected on a
> latest Nightly build? Thanks!

I installed and tried 52.0a1
- Click/Scroll is back and working fine.
- Long Click is selecting text as expected.

Problem solved as far as I'm concerned.

Comment 55

[Ryan VanderMeulen [:RyanVM]]

This needs rebasing for Beta.

Comment 56

[Randall Barker [:rbarker]]

Attachment: Part 1 rebased for Beta.

First part rebased onto beta.

Comment 57

[Randall Barker [:rbarker]]

Attachment: Part 2 rebased for Beta.

Comment 58

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/4b547741edf0
https://hg.mozilla.org/releases/mozilla-beta/rev/0a2576dac20b

Comment 59

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to fox4ever from comment #54)
> (In reply to Ritu Kothari (:ritu) from comment #52)
> > Hello fox4ever, could you please verify this issue is fixed as expected on a
> > latest Nightly build? Thanks!
> 
> I installed and tried 52.0a1
> - Click/Scroll is back and working fine.
> - Long Click is selecting text as expected.
> 
> Problem solved as far as I'm concerned.

Awesome! Thank you for a quick reply. :)

Comment 60

[Zygmunt Dreszer]

I have checked nightly build 52.0.1 and mouse is working as in FF47.
Of course maybe i would like Your idea to make mouse working as in normal desktop system but You really have got some nerve to include this change when it wasn't complete at all (explanation below). I know it is Your product but still You have made me and many other users to waste time to fix what we weren't able to fix, to search for solution, older versions, writing reports and all other stuff.
From this thread i already know You have changed the code in aspect You don't have any idea - You don't use android devices which don't have the touch screen. It is similar for men to decide obligatory for women they should use painkiller medicaments when giving a birth or not.
The only advantages I found with new control code is smooth mouse scroll (not the jerky one from FF47) and a comfort when selecting text (no wonder, the mouse is not doing anything else, except choosing links and marking texts).

About not completed solution and Your measures to detect if mouse has wheel or not or if android device has desktop ui or maybe phone ui - it doesn't matter at all. Half or more of these devices has dedicated desktop/TV ui but because they are created in commercial matter (little to invest / big to gather) they are underdeveloped, simple, without any customization ability and almost uncomfortable to be used. So people usually download better launchers from google store and replaced the crippled ones.
The rest of devices on market has normal, phone UI because manufacturer wanted to save more money.
Still, this kind of androids don't have touch screen, whatever UI they use.

About wheel - my mouse has a scroll wheel, but still firefox is uncontrollable.
Beside wheel, You should have also add:
- scrollbars (horizontal and vertical) - we are talking about desktop system, aren't we?
- comfortable zoom function activated with CTRL (on keyboard) and scrollwheel (like in desktop),
- opening links in new tab with CTRL pressed (yes, there is addon to do it with SHIFT, but why there is an addon for something so important?),
- closing tabs with middle mouse button, or with some key and mouse combination.

So, how long will I be force to use nightly, not tested builds?

Comment 61

[Zygmunt Dreszer]

Ah, I forgot about CTRL+TAB and CTRL+SHIFT+TAB like in desktop.
Then You can remove old mouse control system.

Comment 62

[fox4ever]

(In reply to Zygmunt Dreszer from comment #60)
> I have checked nightly build 52.0.1 and mouse is working as in FF47.
> Of course maybe i would like Your idea to make mouse working as in normal
> desktop system but You really have got some nerve to include this change
> when it wasn't complete at all (explanation below).

Not sure I follow. FF47 and Nightly 52.0.1 with scroll regression bug fixed: Do they work for you or not?

Comment 63

[Kartikaya Gupta (email:[e-mail])]

(In reply to Zygmunt Dreszer from comment #60)
> So, how long will I be force to use nightly, not tested builds?

Another two weeks or so. Firefox 50 has the fix and should be released around November 15.

Comment 64

[fox4ever]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #63)
> (In reply to Zygmunt Dreszer from comment #60)
> > So, how long will I be force to use nightly, not tested builds?
> 
> Another two weeks or so. Firefox 50 has the fix and should be released
> around November 15.

Thanks for the update Kartikaya, some of us are really looking forward to it.

Comment 65

[Zygmunt Dreszer]

(...) Not sure I follow. FF47 and Nightly 52.0.1 with scroll regression bug fixed: Do they work for you or not? (...)

Yes, it works (I wrote that).
But I really like the idea to adjust android Firefox to work like on desktops, when mouse and keyboard is connected.
But to do this, mouse only scroll wheel is insufficient to control firefox. I really would be happy to have a possiblity to zoom with CTRL pressed, or switching tabs with CTRL+TAB combination.
This is not bad idea, but that way it was implemented in FF48 was a sad joke only. Some easter egg You could say.

Comment 66

[2016sti]

I Can Confirm this is only Partially Fixed... Please Change Status i will explain my findings.


Fennec Drag Scrolling         (FIXED after FF52.0.1beta+)

Fennec Double Tap Zoom In/Out (BROKEN after FF47 no fix yet) 


Please Restore/Revert Fennec ability to Double Tap Zoom as pre FF48 b4 you guys Release FF50 on 15th.




Ps. Thank you for Fixing/Reverting Fennec ability for Drag Scrolling 
    and Please fix the Fennec Double Tap Zoom as pre FF48

Comment 67

[Garrison Technology]

I'm helping to develop a platform that relies on Firefox for Android and, more specifically, relies on it to work well with mouse and keyboard input. The change made in 48 which resulted in click-and-drag to select text was a very welcome one for me and my team. I understand the decision that's been made given the perceived proportion of users that actually use Fennec/Android this way, but I would at least like to voice my opinion (on behalf of my team and non-mobile users) that this was an incredibly useful feature.

I believe the long-term solution involves implementing both the drag-to-select and drag-to-scroll behaviour. At this point I don't have a sensible solution for Fennec-proper, but we are implementing hybrid behaviour on our own branch for our unique platform.

Comment 68

[fox4ever]

I agree, many devices on various platforms have different use cases.
The default Firefox/mouse behavior should be aligned with the default UI/Mouse behavior for that platform/device.

eg: 
on PC, click-drag is used for selection.
on Phones, click-drag is used for scrolling.

Now if someone has a need to change this behavior. It would be really nice if it could be user configurable.

(In reply to Garrison Technology from comment #67)
>  
> I believe the long-term solution involves implementing both the
> drag-to-select and drag-to-scroll behaviour. At this point I don't have a
> sensible solution for Fennec-proper, but we are implementing hybrid
> behaviour on our own branch for our unique platform.

Comment 69

[Botond Ballo [:botond]]

Anthony, in comment 13 you were hesistant about adding a pref to control the behaviour here.

Do you still feel the same way given the recent user feedback (comment 67, comment 68)?

Comment 70

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I think for now, matching system/platform behaviour is still the way to go. 

While I agree, it would be really nice, I'm still having trouble seeing the User Problem we're trying to solve with this pref. and it's hard for me to assess priority of this currently