Closed Bug 1133588 Opened 9 years ago Closed 9 years ago

Clipping bug with APZ when scrolling textareas on wikipedia.org

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Platform:
x86_64
Windows 8.1
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 990974

People

(Reporter: dqeswn, Unassigned)

References

Details

(Keywords: regression, Whiteboard: gfx-noted)

Attachments

(1 file, 1 obsolete file)

scroll-wikipedia.gif
(deleted), image/gif
Details
Attached image Wikipedia edit page with the bug. (obsolete) (deleted) — 
I noticed a few days ago on central but, it might be there for a week or two because I didn't use this version regularly.
If some pages are zoomed and I scroll with the mousewheel (but not with page up/down, arrow keys or autoscroll ) some elements disappear or get covered by their background. It also happens if I resize the window.
layers.async-pan-zoom.enabled is true of course and when it's disabled it doesn't happen. As is the case when OMTC is disabled.

It also seems to mostly effect pages with textboxes.

It's reproducible with a clean profile after layers.async-pan-zoom.enabled is set to true.

I attached a screenshot of the bug on a wikipedia edit page.
Blocks: 1086162
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
If this is the same issue as bug 1133518 then it might be fixed by the backout of bug 1075670. Would be worth retesting on the next nightly.
Are you still seeing this on the latest nightly?
Flags: needinfo?(dqeswn)
Yes.
Flags: needinfo?(dqeswn)
For a second I thought it might be fixed. But then I noticed it still happens when I scroll the texbox on the wikipedia edit page I use to test, but not when I scroll the whole page.
avada, can you provide clear steps on how to reproduce this?
Flags: needinfo?(dqeswn)
I don't see, how it can be clearer than what I described before:
Use central. Have layers.async-pan-zoom.enabled and omtc enabled. Have the page zoomed in. (Way more noticable if you have the pages zoomed by default)
Scroll.
And then elements will disappear on some webpages. Out of the top of my head only remember that if you scroll a wikipedia article source edit textbox it happens all the time, but not if you scroll the whole page.
Flags: needinfo?(dqeswn)
(In reply to avada from comment #6)
> I don't see, how it can be clearer than what I described before:
> Use central. Have layers.async-pan-zoom.enabled and omtc enabled. Have the
> page zoomed in. (Way more noticable if you have the pages zoomed by default)
> Scroll.
> And then elements will disappear on some webpages. Out of the top of my head
> only remember that if you scroll a wikipedia article source edit textbox it
> happens all the time, but not if you scroll the whole page.

A few things aren't clear here: what is the zoom level? Exactly what page are you scrolling? (Is it something that requires creating and logging into a Wikipedia account?)
(In reply to David Anderson [:dvander] from comment #7)
> A few things aren't clear here: what is the zoom level?
As I said zooming in so anything above 100%

>Exactly what page
> are you scrolling? (Is it something that requires creating and logging into
> a Wikipedia account?)

As I said a couple times a scrollbox on a wikipedia edit page. (Plus numerous others that I didn't memorize)
eg:
https://en.wikipedia.org/w/index.php?title=Firefox&action=edit
Whiteboard: gfx-noted
It's gotten better it seems. Now only the text that I scroll to disappears/doesn't appear on wikipedia. And it's only temporary. After the scrolling is finished it appears.
I can reproduce some kind of oddity here on the URL in comment #8. When you scroll fast in the textbox, new content being scrolled in is empty in a size proportional to the velocity of the scroll. I don't think we're checkerboarding though, this might be a clipping bug.
Attached image scroll-wikipedia.gif (deleted) — 
Video showing the bug.
Attachment #8565159 - Attachment is obsolete: true
Summary: Elements disappearing from webpages with layers.async-pan-zoom.enabled set to true → Clipping bug with APZ when scrolling textareas on wikipedia.org
(In reply to David Anderson [:dvander] from comment #10)
> I can reproduce some kind of oddity here on the URL in comment #8. When you
> scroll fast in the textbox, new content being scrolled in is empty in a size
> proportional to the velocity of the scroll. I don't think we're
> checkerboarding though, this might be a clipping bug.

It used to be a lot worse. First the whole textbox and other stuff disappeared permanently. Then the only the text disappeared until the scroll is finished. Now only a part of the text is empty while scrolling.

Anyway. I don't know if it just looks similar or is the same bug. On one website the horrible full background advertisement keeps jumping while I scroll. As if the scrolling keeps pulling it and than it bounces back.

url:
http://ipon.hu/
So whatever changed between the previous nightly and the current one (0b202671c9e2) seems to have fixed it. (Bot issues)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
This is still a problem for me.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to David Anderson [:dvander] from comment #14)
> This is still a problem for me.

The background image thing on ipon.hu too?
Ouch. Apparently I only thought that it was fixed because APZ got disable somehow and I didn't notice it. Maybe during an update.
In reality everything's the same.
Okay. So the bug reached the stable branch. In it's original (worst) form.
Until now I had APZ enabled on stable.
I can repro the issue from comment 10/comment 11 on Linux, and it looks like the texture that gets drawn is ignoring the displayport, and only drawing the currently visible area. It's also using buffer rotation which is probably not good. I don't know if things are different on Windows.
That might just be a red herring though since even if I enable tiling (which replaces the rotated buffers with tiled content) that doesn't fix the bug.
Don't we pretty much have to use buffer rotation if we're not tiling?

Yeah - I took another look at this in the context of bug 1148582 being half-fixed in patches, and it seems like this is actually a layout bug. It looked like layout was clipping in the direction the displayport was moving.
(In reply to David Anderson [:dvander] from comment #21)
> Don't we pretty much have to use buffer rotation if we're not tiling?

Yeah, it was just unexpected to me but it makes sense in retrospect. I agree this looks like a layout-side issue. I don't think the clip rect is actually wrong but the mVisibleRegion might be too small.
The problem here is that the textarea has overflow-clip-box: content-box (from forms.css here http://mxr.mozilla.org/mozilla-central/source/layout/style/forms.css?rev=6267c4d1de60#124 ) so the code here http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp?rev=4604104f73a8#2984 goes through the list of scrolled content and clips it all (after we carefully didn't clip it because we had a displayport). The clipping treats carets specially, we've come across this in another bug before.

The easiest fix off the top of my head: mark caret items that need this special clipping from ScrollFrameHelper::BuildDisplayList, hack FrameLayerBuilder to always put these marked caret items in their own painted layer, hack the ComputeFrameMetrics call for this special caret painted layer to do special clip handling. This still doesn't take into account that the exact clipping behaviour currently coded for carets in this situation will change during async scroll, but perhaps it's not too bad.
Ah, nice! I thought this bug seemed familiar - it's the same as bug 990974 which we never actually resolved.
In fact I'm going to dupe this over since that one has more discussion on the root problem.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: