webpage in firefox for android slows down when zoomed in

NEW
Unassigned

Status

()

P3
normal
3 years ago
2 years ago

People

(Reporter: amtorr20, Unassigned)

Tracking

(Blocks: 1 bug)

45 Branch
ARM
Android
Points:
---

Firefox Tracking Flags

(firefox48 wontfix, firefox49 wontfix, fennec+, firefox50 wontfix, firefox51 wontfix, firefox52 wontfix, firefox53 affected)

Details

(URL)

(Reporter)

Description

3 years ago
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.

Comment 1

3 years ago
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: 1206874
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: 1206874
Also on Nightly.
status-firefox48: affected → wontfix
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox49: affected → fix-optional
Priority: -- → P2
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: 1154825
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
status-firefox50: fix-optional → wontfix
status-firefox51: affected → wontfix
status-firefox52: --- → wontfix
status-firefox53: --- → affected
Component: Graphics, Panning and Zooming → Layout: Web Painting
Product: Firefox for Android → Core
Whiteboard: [needsdiagnosis]
You need to log in before you can comment on or make changes to this bug.