Note: There are a few cases of duplicates in user autocompletion which are being worked on.

full page zoom of an image to off-screen, scroll, the image breaks apart

VERIFIED FIXED

Status

()

Core
Layout: View Rendering
P2
normal
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: Aleksej, Assigned: roc)

Tracking

Trunk
x86
All
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a9pre) Gecko/2007110604 Minefield/3.0a9pre

Steps to reproduce:
1. Load the URL, or any other page with an image sufficiently large for step 3. In this case, the image fits in the browser at first.
2. Scroll down a bit, so the image is near the top of the browser.
3. Zoom in (“Ctrl-+” or menu) until a part of the image is out of sight.
4. Scroll right (“→” or scrollbar)

The image breaks into pieces — some go down (e.g., the part that was out of screen), and some go up.

Can probably be reproduced on any image — including the tab bar (Products | Support | Store …) at http://www.mozilla.org/projects/minefield/

Also seen by mw22 on a Windows* build.
Flags: blocking1.9?
(Reporter)

Updated

10 years ago
Whiteboard: DUPEME?
(Reporter)

Comment 1

10 years ago
Created attachment 287674 [details]
A screenshot of the problem at Minefield’s home page. {the page text is cc by-sa 2.0}
(Reporter)

Updated

10 years ago
Attachment #287674 - Attachment description: A screenshot of the problem at Minefield’s home page. {the page is cc by-sa 2.0} → A screenshot of the problem at Minefield’s home page. {the page text is cc by-sa 2.0}

Updated

10 years ago
Blocks: 4821
No longer blocks: 389628
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
What seems to be happening here is that when we zoom, the nominal scroll position stays constant in device pixels, but everything draws as if it had stayed constant in CSS pixels. Then when you scroll we suddenly realize that the scrolled offset is in device pixels and things get screwy.

So basically it looks like scroll positions get out of sync, probably the frame position stays constant in CSS-pixels/appunits and the view position (or the scrollbar position>) stays constant in device pixels.
Created attachment 288630 [details] [diff] [review]
fix

This is quite simple actually. nsScrollPortView has fields mOffsetXpx and mOffsetYpy, which are basically mOffsetX and mOffsetY in device pixels. Problem is, when we change the appunits-to-dev-pixels ratio, mOffsetXpx and mOffsetYpy get out of sync... The solution is simple, don't store them persistently in the first place.
Attachment #288630 - Flags: superreview?(bzbarsky)
Attachment #288630 - Flags: review?(bzbarsky)
Whiteboard: DUPEME? → [needs review]

Comment 4

10 years ago
Comment on attachment 288630 [details] [diff] [review]
fix

Makes sense
Attachment #288630 - Flags: superreview?(bzbarsky)
Attachment #288630 - Flags: superreview+
Attachment #288630 - Flags: review?(bzbarsky)
Attachment #288630 - Flags: review+
checked in
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 6

10 years ago
Verified fixed on GNU/Linux with
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre) Gecko/2007111704 Minefield/3.0b2pre
Whiteboard: [needs review]
Blocks: 401222
(Reporter)

Updated

9 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.