Closed Bug 1537696 Opened 5 years ago Closed 5 years ago

Mouse scroll wheel don't work in Proxmox long listing

Categories

(Core :: Panning and Zooming, defect, P3)

Product:
Core
Component:
Panning and Zooming
Version:
65 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox66 --- affected

People

(Reporter: jo, Unassigned)

References

Details

Attachments

(4 files)

Proxmox Virtual Environment.zip
938.85 KB, application/zip
Details
Proxmox Virtual Environment v2.zip
978.93 KB, application/zip
Details
Screenshot
139.16 KB, image/png
Details
Proxmox Virtual Environment v3.zip
973.73 KB, application/zip
Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

First, use a computer with a touch screen
Connect to a Proxmox WebUI
Move the mouse over a large listing that requires a scroll bar

Actual results:

Move the mouse wheel and see how nothing move
Move two finger one the trackpad and see again how nothing move
Try the keyboard arrow ... nothing
Only click and drag work (or finger on the touch screen)

Expected results:

Touch interactions should not prevent mice and other touchpad from functioning properly.

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Same problem.

I tried to test this report but Im unable to do so since it requires a paid subscription for Proxmox. Im assigning it to Core: Panning and zooming. Please change if this is not the right component.

status-firefox66: --- → affected
Component: Untriaged → Panning and Zooming
Product: Firefox → Core

Jokx, could you share with us the page on which you're experiencing the problem, by doing "File -> Save Page As", selecting "Web Page, complete", and uploading a zip of the saved files as an attachment to this bug?

If page scrolling problems are the responsibility of Core: Panning and zooming, ok.
Yes, I'll go to make a zip.

Concerning Proxmox, sorry but it is not necessary to pay a subscription, it is freely installable and usable with this ISO:

https://www.proxmox.com/en/downloads/item/proxmox-ve-5-3-iso-installer

The subscription is only for professional support.

Thanks. Unfortunately, the zip file is missing some files required to render the page correctly. For example, theme-crisp-all.css contains @import 'theme-crisp-all_1.css';, but theme-crisp-all_1.css is not included in the zip file. (I wonder if that's a deficiency in Firefox's "Save Page As" functionality.)

Are you able to check if the issue occurs with another browser, like Chromium? If so, the issue is likely on the site's side, and you should report it to them.

Indeed, that's a deficiency in Firefox's "Save Page As..." functionality.
And indeed, I use Chromium has a workaround.

Again, you can perform your own tests freely (both way) by installing Proxmox in a virtual machine.

v2

I have included the missing file in the "v2" zip file. But I believe a live Proxmox is lesser buggy...

Attached image Screenshot —

Thanks, we seem to be getting somewhere with the v2 zip.

Attached is how that page renders for me. Could you point out what it is that you're trying to scroll?

(In reply to Botond Ballo [:botond] from comment #6)

For example, theme-crisp-all.css contains @import 'theme-crisp-all_1.css';, but theme-crisp-all_1.css is not included in the zip file. (I wonder if that's a deficiency in Firefox's "Save Page As" functionality.)

(Looks like that's bug 126309.)

Strange, when I open "v2", I have a password popup and a semi-transparent white background. However, I saved the page after I logged in.

In a real Proxmox, when the password is requested, it is impossible to scroll through the listings. Whether with Firefox or Chromium....

I added "display:none;" to these elements but the page remains "frozen". None of the listings scrolls: neither the large one on the right with the nodes, nor the logs at the bottom of the page. Once again, whether with Firefox or Chromium....

So I think you need a Proxmox Live to test these behaviors. (It is very easy to install!)

Translated with www.DeepL.com/Translator

To try to simplify things, I have prepared for you a virtual machine with a pre-installed Proxmox. You will find it here:

https://filesender.renater.fr/?s=download&token=9b642973-ecb5-2132-3065-f156a77d69d7

Once imported (in VirtualBox for example, check that port 8006 of this VM is accessible or redirected and access it with https like :
https://localhost:8006 (for VirtualBox with NAT and redirection)

Login as: root
passwd: -+
Click "Ok"

  • Here you can test the scrolling in the bottom listing if there are enough lines.

Otherwise :

  • develop the line "pve"
  • Choose "Local (pve)"
  • Show "Content"
  • Click "Templates" button
  • Select a templates like "debian-9.0-standard"
  • Click "Download" button
  • A popup window will appear with long scrollable text showing dowload process...

As far as I understand the problem, the listings are placed in a structure of type :

<div style="overflow:hidden;">
<div style="width: 100%; height: 100%; transform: translate3d(0px, 0px, 0px, 0px);">
line,
line,
line,
...
</div>
</div>

When you try to scroll through the content, the "translate3d" is modified to move lines (javascript?).

v3, saved from Chromium. CSS properties are very different :-/

Well, in the current state of my investigations, I understand that Proxmox treats Firefox and Chromium differently.

On the Chromium side, Proxmox provides "overflow:auto" and Chromium allows to handle them with the keyboard, mouse, touchpad or touch screen indifferently.

On the Firefox side, when a touch screen is detected, "overflow:hidden" with "transform:translate3d" are set up to allow touch screen manipulations.

When you load the Chromium page in Firefox, you will notice that the mouse, keyboard and touchpad work again... but at the expense of the touch screen, which becomes inoperative.

So, I conclude that Proxmox's WebUI makes the choice to allow the use of a touch screen with Firefox, to the detriment of other control devices.

It is a pity that Firefox is not able to properly handle each type of control device by itself, as Chromium does :-/

Can you test with the latest Firefox Nightly to see if the issue occurs there? I suspect the webpage is doing touchevent detection which Chromium has intentionally broken to avoid exactly this kind of problem. We followed suit in bug 1412485.

Indeed, I find a normal functioning of the keyboard, mouse and touchpad with Firefox Nightly.

The problem here is reversed: the touch screen no longer works. Sliding your finger on the touch screen causes a text selection instead of scrolling through the "overflow" divisions.

Could we imitate Chromium's behaviour on this point?

If you're on Linux, you need to run Firefox with the MOZ_USE_XINPUT2=1 environment variable to have touch input work properly. Try with that on the Nightly build and hopefully it will solve all the problems! :)

You're right! Everything works perfectly with this configuration. Will it ever be the default configuration?

All I have to do now is wait until July 9 to enjoy these benefits in production.

Thank you very much.

(In reply to Jokx from comment #20)

You're right! Everything works perfectly with this configuration.

Great!

Will it ever be the default configuration?

Bug 1207700 is tracking using XInput2 by default. Once that is fixed this should become the default configuration. Unfortunately nobody is working on that at the moment; there were issues with it that were tricky to resolve and our Linux user population is still small enough that there are other higher-priority things to work on. However if you or somebody you know is knowledgeable in the area we'd welcome patches and help!

For now I'm going to close this bug as fixed by 1412485 since it resolves the wheel scrolling issue you were originally having.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Depends on: 1412485
Priority: -- → P3
Resolution: --- → FIXED

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #21)

our Linux user population is still small enough that there are other higher-priority things to work on.

It's hard to read that today. We are a strong core that defends openness and freedom at your side.

This policy of focusing on the majority herd rather than on the actors on the right track only increases the price of freedom to the detriment of those who would like to embrace it.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #21)

Bug 1207700 is tracking using XInput2 by default. Once that is fixed this should become the default configuration. Unfortunately nobody is working on that at the moment; there were issues with it that were tricky to resolve and our Linux user population is still small enough that there are other higher-priority things to work on.

Reviewing the status of bug 1207700, the latest updates are:

Before the switch we need to address Bug 1182700.

and:

For Bug 1182700 looks like gnome folks gave up (https://bugzilla.gnome.org/show_bug.cgi?id=750994#c8) and recommend to use Wayland.

So, it sounds like it's not an issue of our resources, but issues with higher layers in the stack that we don't have control over.

And, for what it's worth, Wayland support is being actively worked on.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: