Open Bug 1253190 Opened 8 years ago Updated 2 years ago

[APZ] page with the "Scroll of Lorem Ipsum" testcase shows graphic glitches when scroll position changes

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Version:
46 Branch
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox47 --- wontfix
firefox48 --- wontfix
firefox49 --- wontfix
firefox50 --- fix-optional
firefox51 --- fix-optional
firefox52 --- fix-optional

People

(Reporter: arni2033, Unassigned)

References

Details

(Keywords: regression)

User Story

STR_3:
1. Open attached "testcase 2"

AR:  Scrollable area doesn't redraw well  (Nightly 49 (2016-05-26) - "scrollbar doesn't redraw well")
ER:  No graphic glitches


Index:  STR_1 - comment 0, STR_2 - comment 8, STR_3 - comment 10.

Attachments

(2 files, 1 obsolete file)

testcase 1
(deleted), text/html
Details
testcase 2 - (auto) scrollbar doesn't redraw good.html
(deleted), text/html
Details 
>>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160229030448
STR:
1. Open attachment 8710335 [details] (from bug 1241394)
2. Scroll the text block to the middle
3. Open Style editor, add stylesheet with single rule "body{ height:10000px!important; }"
4. Autoscroll the page (gray area) to the bottom, so that only the lower part of the text was visible
5. Slowly autoscroll the page (gray area) to the top

AR:
 There're glitches during Step 5: when a new portion of text appears on the screen,
 it's displayed on dark background. Then background blinks to normal (yellow)

ER:  
 No glitches

Screencast:
> https://dl.dropboxusercontent.com/s/n1kpzw9wbgg4nj6/screencast%201%20-%20Autoscrolling%20%27Lorem%20Ipsum%27%20testcase%20causes%20graphic%20glitches.webm?dl=0

This is regression from bug 1216832. Regression range:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4b1c595da956d29ce0777839ce5fa0b8461d1643&tochange=642a97a7cf346baf2ad55cf300bafbdda95c5df5
Component: Panning and Zooming → Layout
arni2033, would you mind posting a screen shot?
Flags: needinfo?(arni2033)
(In reply to Jim Mathies [:jimm] from comment #1)
> arni2033, would you mind posting a screen shot?
Actually, I posted a link with screencast in comment 0. Is that enough? I'd like to leave this bug as is, unless you want a screenshot for history or you currently can't watch .webm videos for some reason
Flags: needinfo?(arni2033)
Version: Trunk → 46 Branch
(In reply to arni2033 from comment #0)
> >>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160229030448
> STR:
> 1. Open attachment 8710335 [details] (from bug 1241394)
> 2. Scroll the text block to the middle
> 3. Open Style editor, add stylesheet with single rule "body{
> height:10000px!important; }"

Marking 'wontfix' for 48 and setting to P3 based on this STR.
status-firefox48: affected → wontfix
Flags: needinfo?(bugs)
Priority: -- → P3
status-firefox50: --- → affected
(In reply to Jet Villegas (:jet) from comment #3)
> (In reply to arni2033 from comment #0)
> > >>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160229030448
> > STR:
> > 1. Open attachment 8710335 [details] (from bug 1241394)
> > 2. Scroll the text block to the middle
> > 3. Open Style editor, add stylesheet with single rule "body{
> > height:10000px!important; }"
> 
> Marking 'wontfix' for 48 and setting to P3 based on this STR.

Why have you cited steps that aren't necessary, and presented it as a reason for something?
Is is yet another case when people simply count number of steps to set priority?
If you based your decision on step like "open style editor, add some style", then you're obviously wrong. (The page can do it by itself. It can also scroll into view some elements).
Otherwise please don't cite those steps pretending that normal user won't encounter this bug simply because I used style editor. I provide the most reliable way to reproduce, not the shortest one.
Summary: [APZ] Autoscrolling page with the "Scroll of Lorem Ipsum" testcase causes graphic glitches → [APZ] page with the "Scroll of Lorem Ipsum" testcase shows graphic glitches when scroll position changes
Attached file testcase 1 (maybe) (obsolete) (deleted) — 
Here's the testcase with Arni's "height" tweak simply made up-front in the HTML (and with "overflow:hidden" removed as well, because otherwise I can't scroll the body).

Arni, just to double-check -- can you reproduce with this version?  (I can't reproduce locally, using Linux nightly.)
Ah, sorry! I can indeed reproduce (and overflow:hidden does seem to be necessary), but I first need to enable (and use) autoscroll in about:config.  (I didn't realize that made overflow:hidden stuff scrollable.)
Attachment #8792606 - Attachment is obsolete: true
Attached file testcase 1 (deleted) — 
My most reliable STR with this testcase:
 (1) Toggle about:config pref general.autoScroll = true.
 (2) Load testcase.
 (3) Middle-click (over the <body>, outside the scrollable area) and move cursor down a bit so that most of the text is offscreen.
 (4) Now EITHER
    (a) just autoscroll the page back to the top
    (b) reload & then autoscroll the page back up

The (b) version is more reliable for me (reloading before scrolling back up).  I only see rendering glitches on the scrollbar itself, not on the actual text.

I'm using Linux Nightly 52.0a1 (2016-09-19) (64-bit)
Actually, auto-scrolling of overflow:hidden shouldn't be allowed (bug 1272084), as well as scrolling with arrows (I can reproduce this bug by scrolling w/ arrows). I noticed that if scrolling happens in content process(?), it causes this bug. So if page itself scrolls its content (w/ overflow:hidden), this bug will manifest. So APZ and bug 1272084 can improve this bug, but not fix it completely.

[I was going to say:] You can ignore this for a while; I'll do testcase later if it's necessary.
STR_3:
1. Open attached "testcase 2"

AR:  Scrollable area doesn't redraw well  (Nightly 49 (2016-05-26) - "scrollbar doesn't redraw well")
ER:  No graphic glitches
User Story: (updated)
Thanks, that testcase is handy.

I can reproduce the graphical glitches with that testcase, using latest Linux nightly (version 52 with today's datestamp) -- the scrollbar doesn't paint immediately when it's scrolled into view -- it's painted in chunks, with those chunks not painting until a few seconds after they're onscreen.  (I can make them paint sooner/immediately if I wiggle my mouse over the scrollbar area at the bottom of the page, though.)
Chrome has some issues with testcase 2 as well. This is ugly, but feels really edge-casey.
status-firefox49: fix-optional → wontfix
status-firefox50: affected → fix-optional
status-firefox51: affected → fix-optional
status-firefox52: --- → fix-optional
Flags: needinfo?(bugs)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: