Re-enable mouse retargeting (ui.mouse.radius.enabled) for Fenix
Categories
(Core :: Panning and Zooming, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox75 | --- | fixed |
People
(Reporter: kats, Assigned: kats)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
This will undo bug 1247095 because there's a lot of cases where mouse retargeting helps the user experience, in ways that nothing else can do. I expect that re-enabling mouse retargeting will hurt some cases (which is why it was turned off in the first place, see bugs duped to bug 1247095) but that we can selectively detect and disable retargeting in those cases to alleviate the regression.
|
||
Comment 1•5 years ago
|
||
Do you mean changing ui.mouse.radius.enabled back to true by default? As long as the user can set it to false again, this would not be much a problem.
FYI, the problem in my case was text selection with a long press: instead of text selection, an adjacent link was followed (even after zooming). I had reported bug 826601 in the past. But then the implementation changed, and as a consequence, the bug was closed to "invalid". I was asked to open a new bug, which was bug 1244498 (actually similar to bug 1233272, which became a duplicate of bug 1247095). And the solution was to set ui.mouse.radius.enabled to false, so that my bug was closed.
|
Assignee | |
Comment 2•5 years ago
|
||
|
|
Assignee | |
Comment 3•5 years ago
|
||
(In reply to Vincent Lefevre from comment #1)
Do you mean changing ui.mouse.radius.enabled back to true by default?
Yes
As long as the user can set it to false again, this would not be much a problem.
Yes, the user can still set it back to false via about:config
FYI, the problem in my case was text selection with a long press: instead of text selection, an adjacent link was followed (even after zooming). I had reported bug 826601 in the past. But then the implementation changed, and as a consequence, the bug was closed to "invalid". I was asked to open a new bug, which was bug 1244498 (actually similar to bug 1233272, which became a duplicate of bug 1247095). And the solution was to set ui.mouse.radius.enabled to false, so that my bug was closed.
I plan to address this by not retargeting long-press events. I'll probably reopen one of the bugs you listed and put the patch there.
|
|
Assignee | |
Comment 4•5 years ago
|
||
Try push for geckoview tests is green with the change in the pref: https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=800d1bc2d3422481792f2699f49c489d18f9a7d3
|
||
Comment 6•5 years ago
|
||
| bugherder | ||
|
||
Comment 8•5 years ago
|
||
This should not have just been turned on with out making it a GeckoView Runtime option. Firefox Reality definitely does not want this option turned on as it has a very precise pointer.
|
|
Assignee | |
Comment 9•5 years ago
|
||
We discussed this on #GeckoView:mozilla.org - right now the GV layer doesn't have a good way to communicate different app requirements to Gecko. So if Fenix wants X and FxR wants not X then the only official way to do it is to add a GeckoRuntimeSetting thing for it, but :snorp doesn't want to do that in this case. There's an unofficial way that Randall will use for now to flip the pref back to false.
But also, we realized that in general this shouldn't actually affect FxR much. If the user has a super precise pointer, then they should (mostly) be already targeting the right element (link/button/whatever) correctly, and the event retargeting will be a no-op. The cases where it will make a difference is if the user is activating their pointer on an element that's not actually targetable, but is next to a targetable element. In that case they might expect nothing to happen when in fact the targetable element gets triggered. But if they're not expecting anything to happen they shouldn't even be activating their pointer, so in practice this should be rare.
|
|
Assignee | |
Comment 10•5 years ago
|
||
Another solution suggested by :agi was to distinguish based on what pointer is being used, which seems like a good solution. FxR currently generates touch events but it really shouldn't because users are using some sort of virtual laser device and not touch. So if FxR generated a generic motion or pointer event then we wouldn't retarget the synthetic mouse events that get generated from that, because of this pref. Generating different kinds of events might break other things but those should be fixable too.
Description
•