Closed Bug 1333965 Opened 7 years ago Closed 6 years ago

http://www.localstrike.net/foros/ places background-color on <html> and background-image on <body>, leading to inefficient handling of background by the browser

Categories

(Web Compatibility :: Site Reports, defect, P3)

Product:
Web Compatibility
Component:
Site Reports
Type:
defect

Tracking

(firefox52 wontfix, firefox53 wontfix, firefox54 affected)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox52 --- wontfix
firefox53 --- wontfix
firefox54 --- affected

People

(Reporter: botond, Assigned: adamopenweb)

References

(
URL
)

Details

(Whiteboard: [gfx-noted][sitewait]) 

STR:
   1. Run Firefox with apz.drag.enabled set to true.
      (This is currently the default on the Nightly branch.)
   2. Load http://www.localstrike.net/foros/
   3. Repeatedly drag the scrollbar up and down quickly

Expected results:
  If there's checkerboarding, it's restricted to areas that are scrollable.

Actual results:
  Checkerboarding occurs across the entire width of the page, including
  over the background image, which is fixed.

Does not happen with apz.drag.enabled set to false, nor in Chromium.
Notes from my experience:

Ubuntu 16.10, Dell XPS 13 9350, Wayland, Firefox Nightly

1) I see heavy tearing when I scroll both up and down of the whole screen.
2) turning apz.drag.enabled to false and restarting minimizes the effect to be much less visible, but still visible when scrolling up (not when scrolling down).
3) Can't reproduce it on Chromium, but scrolling there is much slower.
4) When I turn off background-position: fixed the tearing disappears.
Priority: -- → P3
Whiteboard: [gfx-noted]
Bug 1298218 will fix this. This happens because the display port applies as a scrolled clip to the fixed layer. Bug 1298218 will make fixed backgrounds on the canvas frame reset the display port clip.
This was probably caused by bug 1263192 which added the display port clip.
Depends on: 1298218
Awesome - thanks for the diagnosis!
I still see this on a m-c build with the patches from bug 1298218.
Yes, I was wrong. On this page, the fixed background is on the body, but the html element also has a background-color set on it. Without this background-color on the html element, the body's fixed background would propagate up to the html element, and bug 1298218 would have solved the problem. But with the background-color on the html element, the fixed background is on a regular element that moves with the page, and as such is clipped to that element's background-clip region. And the element itself is clipped by the display port clip. I'm not sure if there's much we can do about this.

There's another problem with the patches from bug 1298218 that I noticed last night, which happens if you remove the html element's background-color in this testcase: things that are inside the displayport but outside the current viewport at the time of the paint sometimes don't get painted. I'm going to file another bug about that.
For example, https://armenzg.blogspot.ca/ is a page where bug 1298218 fixed this problem.
(In reply to Markus Stange [:mstange] from comment #5)
> Yes, I was wrong. On this page, the fixed background is on the body, but the
> html element also has a background-color set on it. Without this
> background-color on the html element, the body's fixed background would
> propagate up to the html element, and bug 1298218 would have solved the
> problem. But with the background-color on the html element, the fixed
> background is on a regular element that moves with the page, and as such is
> clipped to that element's background-clip region. And the element itself is
> clipped by the display port clip. I'm not sure if there's much we can do
> about this.

I talked to Markus about this, and avoiding the checkerboarding extending to the background in this configuration is difficult.

I think we should treat this as an Evangelism issue instead, and suggest to the website authors that they either place both the background-color and the background-image on  the <html> element, or both on the <body> element, either of which would fix this issue.

Moving to Tech Evangelism.
Component: Panning and Zooming → Desktop
Product: Core → Tech Evangelism
Summary: Non-scrolling content checkerboards with async scrollbar dragging → http://www.localstrike.net/foros/ places background-color on <html> and background-image on <body>, leading to inefficient handling of background by the browser
Contacted by email (info@localstrike.net).
Assignee: nobody → astevenson
Status: NEW → ASSIGNED
Whiteboard: [gfx-noted] → [gfx-noted][sitewait]
Sorry, the email bounced back. Contacted using the site contact form: http://www.localstrike.com/contactate-con-localstrike-113
No longer blocks: async-scrollbar-drag
Update from today,

Still Dell XPS 13 9350 on Nightly I now see heavy tearing on https://metrics.mozilla.com/firefox-hardware-report/ when scrolling up and down.

It's a bit similar to the fixed issue with that URL except that I can't reproduce it there, just in the Firefox Hardware Report.

Not sure if I should file it as a separate bug or not, but would like to get it confirmed on some other config first.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #10)
> Still Dell XPS 13 9350 on Nightly I now see heavy tearing on
> https://metrics.mozilla.com/firefox-hardware-report/ when scrolling up and
> down.

Can you clarify what you mean by "tearing"? Usually tearing refers to different rows or columns of pixels being visually translated by different amounts, so as to produce the appearance of a "tear" on the screen.

Is what you're actually seeing checkerboarding (page background visible instead of page content for a short period after scrolling) instead?
Yeah, Sorry for my ignorance!

So, what I see is that parts of screen from the direction I'm scrolling in turn fully blue (I assume background color) and flicker. Once I stop scrolling the painting happens and the page looks fine.

I recorded a video that hopefully illustrates the experience: https://us-next.owncube.com/index.php/s/pfIDvNmQnhMWBne

Is it helpful?
Do you need more information?
Should I file a new bug or is it a dupe of this?
Flags: needinfo?(botond)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #12)
> So, what I see is that parts of screen from the direction I'm scrolling in
> turn fully blue (I assume background color) and flicker. Once I stop
> scrolling the painting happens and the page looks fine.
> 
> I recorded a video that hopefully illustrates the experience:
> https://us-next.owncube.com/index.php/s/pfIDvNmQnhMWBne
> 
> Is it helpful?

Thanks. I can confirm that I see the same behaviour.

> Should I file a new bug or is it a dupe of this?

On that page, the background image is scrolling as opposed to fixed, so it's unrelated to this bug. I believe it's just a case of bug 1251617.
Flags: needinfo?(botond)
I'm not able to reproduce the issue anymore, for me the scrolling is performed smoothly. This issue might be fixed.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.