Closed Bug 1265137 Opened 9 years ago Closed 4 months ago

webpage in firefox for android slows down when zoomed in

Categories

(Core :: Web Painting, defect, P3)

Product:
Core
Component:
Web Painting
Version:
45 Branch
Platform:
ARM
Android
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
firefox48 --- wontfix
firefox49 --- wontfix
fennec + ---
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox53 --- affected

People

(Reporter: amtorr20, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160415030231 Steps to reproduce: 1. Go to home.mywebsearch.com in firefox for android. 2. Go to home.mywebsearch.com in another android browser (I used google chrome) 3. Zoom into the page and attempt to scroll in different directions. Do this for both browsers Actual results: When I zoomed into google chrome everything worked just fine and I was able to scroll through the web page without any issue. When I zoomed into the webpage through firefox, the page slowed down and would freeze for a very quick second and jump to the intended spot. Expected results: The firefox for android browser should have smoothly scrolled through the website without jumping/freezing.
Switching to needsdiagnosis. Not related but funky. The HTTP response contains. ```html <META name="description" content=MyWebSearch brings together the most comprehensive collection of search tools available to provide you with the information you need when you need it/> ``` which is interpreted by Gecko as ```html <meta name="description" content="MyWebSearch" brings="" together="" the="" most="" comprehensive="" collection="" of="" search="" tools="" available="" to="" provide="" you="" with="" information="" need="" when="" it=""> ``` The page has also two <title>. These comments that the Quality Check on the site might not be as good as expected. To take into account if it needs to be contacted. Though I have the feeling it's more on the side of Gecko than Outreach.
Flags: needinfo?(miket)
Whiteboard: [needsdiagnosis]
I get the feeling this is less about webcompat and more about how we're dealing with the gradient bg on the <body> element: body { -moz-font-feature-settings: inherit; -moz-font-language-override: inherit; background-image: url("http://ak.imgfarm.com/images/search/dtest/drytest_backrep.jpg"); background: linear-gradient(to bottom, #fefefe, #e6eff4 33%, #d7e3ef 43%, #eff3f6 80%, #f7f7f7); background-repeat: no-repeat; background-attachment: fixed; border: 0 none; font-family: Arial; font-size: 12px; font-size-adjust: inherit; font-stretch: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; height: 100%; line-height: inherit; margin: 0; padding: 0; vertical-align: baseline; } Testing with websearch2, which has the gradient removed, scrolling is much less janky: https://miketaylr.com/bzla/websearch.html (same thing as the linked URL) https://miketaylr.com/bzla/websearch2.html
Component: Mobile → Graphics, Panning and Zooming
Flags: needinfo?(miket)
Product: Tech Evangelism → Firefox for Android
Version: Firefox 45 → 45 Branch
tracking-fennec: --- → ?
This is a ton smoother with APZ on nightly. I recall some bugs on gradients do we have something already on file?
Flags: needinfo?(bugmail.mozilla)
For some reason the gradient is causing us to repaint on every movement, this is visible with paint flashing turned on. The massive number of repaints is causing the jank. On Nightly with APZ we have paint-skipping, which avoid this. If I turn apz.paint-skipping.enabled to false on Nightly I see the same problem. The websearch2.html in comment 2, with the gradient removed, doesn't do all the repainting, so it's faster. I'm not sure why the gradient background would cause so many repaints. I'm not convinced that speeding up gradients will help here, since it seems to be the number of repaints, not the slowness of each repaint, that is causing the issues. (At least from what I can see - we would need to profile the paint to check).
Status: UNCONFIRMED → NEW
Depends on: fennec-aboard-apz
Ever confirmed: true
Flags: needinfo?(bugmail.mozilla)
Seems like `background-attachment: fixed` is contributing to the jank here. https://miketaylr.com/bzla/websearch3.html has just that prop removed and it's much more responsive when zoomed and panning (comparing w/ https://miketaylr.com/bzla/websearch.html)
tracking-fennec: ? → +
This is still kinda janky on 48. Certainly more than I would expect. We should investigate.
status-firefox48: --- → affected
No longer depends on: fennec-aboard-apz
I looked at this some more, scrolling/invalidation appears to be working correctly. As we scroll the background-attachment:fixed is causing the background CanvasBackgroundColor display item to shift position, and that causes DLBI to invalidate it and repaint. I guess it's just expensive to paint the gradient and ship it over to the compositor every frame.
Blocks: paint-fast
status-firefox49: fix-optional → wontfix
status-firefox50: affected → fix-optional
status-firefox51: affected → fix-optional
OS: Unspecified → Android
Priority: P2 → P3
Hardware: Unspecified → ARM
Actually Markus pointed out that on Android we shouldn't be moving that background around, just moving the clip on it. So something is still off here. And my inspection of the display list dumps was wrong, it's the CanvasBackgroundImage display item (not the CanvasBackgroundColor item) that's changing geometry - the width was changing in the instance I reproduced.
status-firefox51: fix-optional → affected
Component: Graphics, Panning and Zooming → Layout: Web Painting
Product: Firefox for Android → Core
Whiteboard: [needsdiagnosis]
Severity: normal → S3

Site doesnt exist anymore. Closing for now.

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.