Closed Bug 1658749 Opened 4 years ago Closed 2 years ago

Middle Click scroll is not working correctly in new Print Preview

Categories

(Toolkit :: Printing, defect, P2)

Firefox 81
Desktop
All
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox81 --- wontfix
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- wontfix
firefox99 --- fixed

People

(Reporter: vlucaci, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [print2020] )

Attachments

(1 file)

Attached image Middle Click scroll.gif

Affected versions

  • 81.0a1 (2020-08-12)

Affected platforms

  • Windows 10x64
  • macOS 10.15.6
  • Ubuntu 18.04

Steps to reproduce

  1. Launch FF.
  2. Go to a long content website: https://en.wikipedia.org/wiki/Facebook.
  3. Open new Print Preview.
  4. Middle click inside the print preview.

Expected result

  • The Middle click scroll cursor should open right where the user clicked, and page should not automatically scroll.

Actual result

  • The middle click scroll cursor appears outside of print preview (or not at all where the user has clicked) and it automatically scrolls in the direction it has appeared.

Suggested Severity

  • I would consider this issue an S2 as it affects a vital component of scrolling long content pages in print preview.

Regression range

  • Not a regression.

Additional notes

  • For Ubuntu, the middle click scroll cursor does not appear at all.

I think it's closer to an S3, because there's an easy workaround (use the regular scroll, or the keyboard)…

Severity: -- → S3
Priority: -- → P3
Has STR: --- → yes

WFM on current nightly. Can you doublecheck whether this is fixed on your end?

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Flags: needinfo?(vlad.lucaci)
Assignee: gijskruitbosch+bugs → nobody
Status: ASSIGNED → NEW

Hello,

Yes I can still reproduce this issue with the same repro steps on Windows 10x64 with 82.0a1 (2020-09-03) and 81.0b6.

Flags: needinfo?(vlad.lucaci)

(In reply to Vlad Lucaci, QA (:vlucaci) from comment #3)

Hello,

Yes I can still reproduce this issue with the same repro steps on Windows 10x64 with 82.0a1 (2020-09-03) and 81.0b6.

Are you maybe doing this on machines with multiple screens? What DPI settings are you using? Does autoscroll work correctly in the main page?

Flags: needinfo?(vlad.lucaci)

Hello,

Yes, I am using a dual screen set-up (a 28' Samsung 4k monitor, and the laptop 17' screen).
Auto-scroll works as expected on the main page.
The DPI is set by default on 100%(recommended)

Flags: needinfo?(vlad.lucaci)
Severity: S3 → --
Component: Printing → XUL Widgets
Priority: P3 → --
See Also: → 1474783
Summary: Middle Click scroll is not working correctly in new Print Preview → Middle Click scroll is not working correctly in new Print Preview when using multiple screens
Whiteboard: [print2020_v81] → [print2020_v82]
Severity: -- → S3
Priority: -- → P2

Moving to 83.

Whiteboard: [print2020_v82] → [print2020_v83]
Whiteboard: [print2020_v83] → [print2020_v84]
Whiteboard: [print2020_v84] → [print2020_v85]

I managed to reproduce this issue on Ubuntu 18.04 x64 on a laptop with a single monitor.

(Moving bugs to 86, part 2.)

Whiteboard: [print2020_v85] → [print2020_v86]
Whiteboard: [print2020_v86] → [print2020_v88]

I can also reproduce the issue on Windows10 with a single monitor.

Summary: Middle Click scroll is not working correctly in new Print Preview when using multiple screens → Middle Click scroll is not working correctly in new Print Preview
Flags: needinfo?(tnikkel)

(In reply to Alice0775 White from comment #9)

I can also reproduce the issue on Windows10 with a single monitor.

Interesting, because I cannot. Does this happen with any document? By how much is the opening location of the autoscroll icon off-set? Do you see this with every DPI setting, or only some?

Flags: needinfo?(alice0775)

(In reply to :Gijs (he/him) from comment #10)

(In reply to Alice0775 White from comment #9)

I can also reproduce the issue on Windows10 with a single monitor.

Does this happen with any document?

YES

By how much is the opening location of the autoscroll icon off-set?

The off-set depends on DPI(%) of "Ease Of Access" settings of Windows 10.

When 100% text and 100% everything.
autoscroll icon will appear at approx.(2/3screenX, 2/3screenY) when middle mouse click at (screenX, screenY) from top-left of monitor.

When 100% text and 125% everything.
autoscroll icon will appear at approx.(5/6screenX, 5/6screenY) when middle mouse click at (screenX, screenY) from top-left of monitor.

When 100% text and 150% everything, I cannot reproduce this issue.
The autoscroll icon will appear as expected.

Do you see this with every DPI setting, or only some?

Yes, Off-set depends on DPI(%).

Flags: needinfo?(alice0775)
Whiteboard: [print2020_v88] → [print2020]

This is still reproducible after bug 1741830 landed.

(In reply to Alice0775 White from comment #11)

(In reply to :Gijs (he/him) from comment #10)

(In reply to Alice0775 White from comment #9)

I can also reproduce the issue on Windows10 with a single monitor.

Does this happen with any document?

YES

By how much is the opening location of the autoscroll icon off-set?

The off-set depends on DPI(%) of "Ease Of Access" settings of Windows 10.

When 100% text and 100% everything.
autoscroll icon will appear at approx.(2/3screenX, 2/3screenY) when middle mouse click at (screenX, screenY) from top-left of monitor.

When 100% text and 125% everything.
autoscroll icon will appear at approx.(5/6screenX, 5/6screenY) when middle mouse click at (screenX, screenY) from top-left of monitor.

When 100% text and 150% everything, I cannot reproduce this issue.
The autoscroll icon will appear as expected.

Do you see this with every DPI setting, or only some?

Yes, Off-set depends on DPI(%).

fyi Emilio... I'm guessing this is to do with the page zoom side of things for the coordinate calculation?

Flags: needinfo?(emilio)

I'm almost sure this will be fixed by bug 1753836 by virtue of moving the CSS -> Device pixel conversion to the child in the autoscroll and context-menu code.

Depends on: 1753836
Flags: needinfo?(emilio)

Indeed this works now.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(tnikkel)
Resolution: --- → DUPLICATE

Unduping in case QA wants to verify this case.

Resolution: DUPLICATE → FIXED
Component: XUL Widgets → Printing
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: