scroll causes lines in webpage

RESOLVED FIXED in mozilla14

Status

()

Core
Graphics
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: xxbones21xx, Assigned: roc)

Tracking

Trunk
mozilla14
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 614181 [details]
lines in nightly.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120411 Firefox/14.0a1
Build ID: 20120411030716

Steps to reproduce:

I used the middle button to scroll through a webpage after Nightly's 4-11-12 update.


Actual results:

Its scrolled correctly but caused there to be lines appearing wear the page was scrolled.


Expected results:

Not this. Should have just scrolled and left the contents of the page untouched.
(Reporter)

Comment 1

5 years ago
When i removed multirow bookmarks toolbar plus, then lines didnt appear anymore.

Comment 2

5 years ago
Caused by http://hg.mozilla.org/integration/mozilla-inbound/rev/25a13d26509d

Link to the mentioned extension https://addons.mozilla.org/en-US/firefox/addon/multirow-bookmarks-toolbarplus

Roc, is this a regression or just an incompatible extension?
Blocks: 733607
Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics
Ever confirmed: true
Product: Firefox → Core
QA Contact: untriaged → thebes
Version: 14 Branch → Trunk
Probably not the extension.
Do we snap the clip rect everywhere properly in FrameLayerBuilder?

Comment 5

5 years ago
I also notice this in current nightly build when scrolling iframes.
Possible duplicate: bug #744666
Created attachment 614669 [details] [diff] [review]
fix

We need to make sure that stuff outside the snapped clip rect isn't included in the layer's visible region. This patch does that.

The change to nsDisplayClip::GetBounds doesn't really matter --- nothing uses this snap output --- but it's more correct; mClip's edges can be snapped, but the edges of the bounds of the wrapped list cannot be snapped.
Assignee: nobody → roc
Attachment #614669 - Flags: review?(tnikkel)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6)
> The change to nsDisplayClip::GetBounds doesn't really matter --- nothing
> uses this snap output --- but it's more correct; mClip's edges can be
> snapped, but the edges of the bounds of the wrapped list cannot be snapped.

So technically it should just leave aSnap alone and let nsDisplayWrapList::GetBounds set it?
Attachment #614669 - Flags: review?(tnikkel) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/e339ca6c2f11(In reply to Timothy Nikkel (:tn) from comment #7)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6)
> > The change to nsDisplayClip::GetBounds doesn't really matter --- nothing
> > uses this snap output --- but it's more correct; mClip's edges can be
> > snapped, but the edges of the bounds of the wrapped list cannot be snapped.
> 
> So technically it should just leave aSnap alone and let
> nsDisplayWrapList::GetBounds set it?

I suppose, but it doesn't matter.
https://hg.mozilla.org/integration/mozilla-inbound/rev/e339ca6c2f11

Updated

5 years ago
Duplicate of this bug: 745263

Updated

5 years ago
Duplicate of this bug: 744487
Blocks: 744666
fwiw, this seems to be happening on my galexy tab, as well.
OS: Windows 7 → All
Hardware: x86_64 → All
https://hg.mozilla.org/mozilla-central/rev/e339ca6c2f11
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
Duplicate of this bug: 745449

Updated

5 years ago
Depends on: 745934
No longer depends on: 745934
Depends on: 745934

Updated

5 years ago
No longer depends on: 745934
You need to log in before you can comment on or make changes to this bug.