Closed Bug 1238502 Opened 8 years ago Closed 8 years ago

[e10s] Easy to checkerboard while wheel-scrolling by page deltas

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1256677
Tracking Flags:
Tracking Status
e10s + ---
firefox46 - unaffected

People

(Reporter: arni2033, Unassigned)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [gfx-noted]) 

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160110030214

> screencast: https://dl.dropboxusercontent.com/s/xpbpq0psf2kn5lj/screencast%201%20-%20Parts%20of%20the%20page%20are%20rendered%20as%20gray%20areas%20if%20I%20scroll%20quickly.webm?dl=0

STR_1:
0. Set mouse option "When I rotate mouse wheel" to "scroll by 1 page"
1. Open http://www.rp-online.de/
2. Wait until it's fully loaded (blue spinner in tab should disappear)
3. Quickly scroll the page towards the bottom (by quickly rotating mouse wheel down several times)

Result:       Parts of the page are rendered as gray areas. Sometimes that happens after 1 scroll
Expectations: Page should be rendered normally

STR_2:
0. Set mouse option "When I rotate mouse wheel" to "scroll by 1 page"
1. Open devtools -> Debugger on this page (make sure you're using Dark devtools theme)
2. Select the longest .js-file, pretty-print it, perform the first scroll
3. Quickly scroll the .js-file towards the bottom (by quickly rotating mouse wheel down several times)

Result:       Parts of the code are rendered as black areas (code isn't visible)
Expectations: Page should be rendered normally

Note:
 I figured out that result is actually that rectangle areas at the top and bottom of content area
 become transparent and therefore background of <html> or <body> becomes visible
 In STR_1 <html> has gray background, and in STR_2 <body> has black/white background.

Caused by bug 1228028. This is blocker. Regression range:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0dbac1acaca7ae2a767604fdbcf5105853518c88&tochange=f7ee42669b87f05416eb785ab9db27b5c66de1a3
Summary: Parts of the page are rendered as gray areas if I scroll quickly → [e10s] Parts of the page are rendered as gray areas if I scroll quickly
This sounds like standard checkerboarding. Page scrolling is more likely to expose it than line scrolling because it's easier to scroll faster than we can paint.
Summary: [e10s] Parts of the page are rendered as gray areas if I scroll quickly → [e10s] Easy to checkerboard while wheel-scrolling by page deltas
[Tracking Requested - why for this release]: nominating to track since this is a regression in Firefox 46.
tracking-e10s: --- → ?
tracking-firefox46: --- → ?
Whiteboard: [gfx-noted]
This is more of a behavior change than a regression. Previously we'd jank when we couldn't keep up with painting.
tracking-e10s: ? → +
Depending on how common this issue is and how severe we think its effect is we could still track it so that we don't ship 46 with this.  
kats, what do you think? Is this just one of many similar APZ/e10s issues or is it something actionable we can assign to someone now?
Flags: needinfo?(bugmail.mozilla)
I suspect this issue is not very common - not many people will want wheel scrolling to scroll by a whole page.
Flags: needinfo?(bugmail.mozilla)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #5)
> this issue is not very common - not many people will want wheel scrolling to scroll by a whole page
1) Wait, THAT is your reason?! Maybe in your country it isn't a common option. But everyone I saw has that option set to "Scroll by 1 page". When you're reading an article, and finish reading the whole page, how many lines do you usually scroll down? Three? Well, reading articles by 3 lines is insane
2) Spacebar doesn't scroll by 3 lines. It scrolls by whole page (that's very annoying action btw)
3) PageDown doesn't scroll by 3 lines. It scrolls by whole page
Since you're going to implement APZ everywhere, it'll definitely will be a common issue.
4) If scrolling by 1 page wasn't so important - then why was it enabled so soon anyway,
   w/o proper checking? (bug 1228028)
5) I can reproduce it with useless "scroll by 3 lines" option during the page loading,
   scrolling at normal speed.
(In reply to arni2033 from comment #6)
> (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #5)
> > this issue is not very common - not many people will want wheel scrolling to scroll by a whole page
> 1) Wait, THAT is your reason?!

That's part of it. That's not the only reason. The other factor is that this is regular checkerboarding, and we know that with APZ we won't be able to eliminate checkerboarding entirely. That is a tradeoff we knew we were making going into it - trading away jank in favor of checkerboarding. If it were perma-checkerboarding or something else more severe I would definitely want it fixed before shipping.

> Maybe in your country it isn't a common
> option. But everyone I saw has that option set to "Scroll by 1 page". When
> you're reading an article, and finish reading the whole page, how many lines
> do you usually scroll down? Three? Well, reading articles by 3 lines is
> insane

Personally, I usually scroll down as I'm reading, rather than reading to the bottom of what's visible and then doing a page scroll. However we can get telemetry data on this as part of bug 1238137 to see how many people do page-scrolling with wheel input. I'm betting that since it's not the default setting in operating systems it's likely quite uncommon.

> 2) Spacebar doesn't scroll by 3 lines. It scrolls by whole page (that's very
> annoying action btw)
> 3) PageDown doesn't scroll by 3 lines. It scrolls by whole page
> Since you're going to implement APZ everywhere, it'll definitely will be a
> common issue.

Yes, and when we implement APZ for keyboard input we'll have to deal with it. However at this time I don't see it as urgent for 46, which doesn't have APZ for keyboard input. I should point out that since keyboard input will likely go through the main thread first anyway it will be much easier to avoid checkerboarding for those scenarios. This doesn't meant that we *won't* do it for wheel input - but it means that if we spent the effort to do it for wheel input, it wouldn't magically do it for keyboard input as well. The two input methods require their own independent cost/benefit analysis.

> 4) If scrolling by 1 page wasn't so important - then why was it enabled so
> soon anyway,
>    w/o proper checking? (bug 1228028)

As per bug 1228028 comment 0, it was desired for accessibility on B2GDroid. I think "proper checking" did happen - this checkerboarding is not really surprising to me, and I don't have a problem shipping APZ with this.

> 5) I can reproduce it with useless "scroll by 3 lines" option during the
> page loading,
>    scrolling at normal speed.

Yes, checkerboarding is a thing. It happens when you have asynchronous scrolling. We can reduce it, but we will never be able to eliminate it completely, by definition. If we could, we wouldn't need APZ in the first place.
If I'm not tracking this, and no one is assigned to it, I don't want it to get lost in the mix for future versions. 

Is there a scrolling related meta bug that it would be logical to add this to? Or will it show up in later stages of fixing e10s related issues?
tracking-firefox46: ? → -
Marking it blocking the apz-desktop metabug. I thought I already did that but I guess not, sorry.
Blocks: apz-desktop
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #5)
> I suspect this issue is not very common - not many people will want wheel
> scrolling to scroll by a whole page.

With bug 1238137 landed we are starting to get some data on this, and the number of wheel scrolls by page amounts we are getting is very small. In the histogram at [1], we have 22.69 million samples of line-scrolling and 4.79 thousand samples of page-scrolling.

[1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-02-18&keys=__none__!__none__!__none__&max_channel_version=nightly%252F47&measure=SCROLL_INPUT_METHODS&min_channel_version=nightly%252F46&processType=false&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-02-17&table=0&trim=1&use_submission_date=0
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Marking unaffected for 46 since e10s will not be enabled on 46 release.
status-firefox46: affected → unaffected
You need to log in before you can comment on or make changes to this bug.