Closed Bug 1294707 Opened 3 years ago Closed 3 years ago

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

Categories

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

48 Branch
ARM
Android
defect

Tracking

()

VERIFIED FIXED
Firefox 51
Tracking Status
firefox48 --- wontfix
firefox49 + wontfix
fennec + ---
firefox50 + fixed
firefox51 + fixed
firefox52 --- verified

People

(Reporter: fox4ever, Assigned: rbarker)

References

Details

(Keywords: regression)

Attachments

(4 files, 3 obsolete files)

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.
OS: Unspecified → Android
Hardware: Unspecified → ARM
[Tracking Requested - why for this release]: regression from apz
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Component: Keyboards and IME → Graphics, Panning and Zooming
Ever confirmed: true
Keywords: regression
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.
Flags: needinfo?(alam)
"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.
(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.
Blocks: 1251346
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
Randall if you get a chance could you look at this and see what Chrome and other apps do?
tracking-fennec: ? → +
Flags: needinfo?(rbarker)
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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.
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
Assignee: nobody → rbarker
Flags: needinfo?(rbarker)
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 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
Attachment #8782686 - Attachment is obsolete: true
(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.
(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.
Flags: needinfo?(alam) → needinfo?(bbermes)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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?
Flags: needinfo?(bugmail)
(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.
Flags: needinfo?(bugmail)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
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.
Attachment #8782688 - Attachment is obsolete: true
Attachment #8782688 - Flags: review?(snorp)
(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.
(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.
(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.
(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"?
(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.
(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 :-)
(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.
Track 49+/50+/51+ as this is a regression from APZ and changes click/drag for scrolling behavior.
Flags: needinfo?(bbermes)
I think we're still waiting for UX/product clarification here.
Flags: needinfo?(bbermes)
Flags: needinfo?(alam)
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?
Flags: needinfo?(alam) → needinfo?(bugmail)
(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.
Flags: needinfo?(bugmail)
(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.
And I guess if we can't find some way to detect it, then we should probably just revert to the old behaviour.
Flags: needinfo?(bbermes)
(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"?
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.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
Flags: needinfo?(fox4ever)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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"?
(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.
We should revert the behaviour to not special-case TOOL_TYPE_MOUSE. Randall, do you want to write the patch or should I?
Flags: needinfo?(fox4ever) → needinfo?(rbarker)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
Flags: needinfo?(rbarker)
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?
Flags: needinfo?(esawin)
Barbara, ditto for chromebook (see comment #39)
Flags: needinfo?(bbermes)
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).
Flags: needinfo?(esawin)
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).
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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.
Click/drag for scrolling down with a mouse on my Asus Chromebook with Firefox 48 Android app installed, does not do anything.
Flags: needinfo?(bbermes)
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
Attachment #8792055 - Flags: review?(bugmail) → review+
Pushed by rbarker@mozilla.com:
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 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.
Attachment #8792055 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/70565fcf2727
https://hg.mozilla.org/mozilla-central/rev/41d0da5ec5e8
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
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.
Attachment #8792055 - Flags: approval-mozilla-aurora? → approval-mozilla-beta?
Hello fox4ever, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(fox4ever)
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+
Attachment #8792055 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(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.
This needs rebasing for Beta.
Flags: needinfo?(fox4ever) → needinfo?(rbarker)
First part rebased onto beta.
Flags: needinfo?(rbarker)
(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. :)
Status: RESOLVED → VERIFIED
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?
Ah, I forgot about CTRL+TAB and CTRL+SHIFT+TAB like in desktop.
Then You can remove old mouse control system.
(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?
(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.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
(...) 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.
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.
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.
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)?
Flags: needinfo?(alam)
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
Flags: needinfo?(alam)
You need to log in before you can comment on or make changes to this bug.