885195 - During GC pauses, touches/swipes can trigger panning and zooming

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Katelyn Gadd (:kael)]

If the user touches/swipes on the screen during a GC pause, the page is not given an opportunity to evt.preventDefault() the associated touch events and a pan/zoom will begin. This is pretty catastrophic for touch based games that depend on the viewport never scrolling.

Hard to reproduce manually, but I've seen it a couple times - if you really need a test case maybe I can figure out how to build one that triggers GC pauses at consistent intervals.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Hmm, I'm not sure if the GC is supposed to take that long. On Fennec we use a 200ms timeout for the preventDefault() to happen, but I have no idea how long GCs are supposed to take. Needinfo'ing billm who might know this.

Comment 2

[Katelyn Gadd (:kael)]

Most of the GCs are very fast, but the app I was testing creates tons of GC pressure so I assume the long pause must have been a GC+CC or perhaps a system-level hang.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Our target for GC pauses is never more than 40ms. However, we sometimes have trouble hitting the target, especially on slow systems (like a phone).

Honestly, if we're pausing a game for more than 200ms, it seems like we're already in a really bad situation, regardless of touch events. You might need to find a way to reduce the allocation rate.

Comment 4

[Katelyn Gadd (:kael)]

I don't consider the pause a FF bug; it's third party code that I have to do clever things to optimize. I just considered that preventDefault behavior to be strange. It's just annoying since it's effectively impossible to disable scrolling and zooming on mobile at present (though FF Android is far more cooperative than Chrome) - it makes me worry that even if I get the pauses below 40 on a higher end Android phone like mine, players on low end phones will suffer.

Is there some way to disable the default behavior that doesn't get broken by long pauses? I've tried meta viewport, overflow hidden, etc.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

It's certainly possible to disable panning and zooming by sizing your page appropriately and setting user-scalable=no in the meta viewport tag. See for instance http://people.mozilla.com/~kgupta/bug/885195.html

Comment 6

[Katelyn Gadd (:kael)]

My test case has user-scalable=no:

<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=no, target-densitydpi=device-dpi">

And the page size is set to the size of the window (as it happens without this rendering is busted because of some weird quirk in CSS3 transforms?):
        var body = document.getElementsByTagName("body")[0];
        body.style.width = window.innerWidth + "px";
        body.style.height = window.innerHeight + "px";

Plus I used CSS to set overflow hidden, I call preventDefault in all the touch events, and I ensured that there are no margins or padding anywhere, and the only actual element in the document (a canvas) is resized to precisely fit the screen. No scrollbars ever appear in a desktop browser; it's only mobile browsers that somehow decide the page should be scrollable. :(

If I can disable scrolling with some special combination of attributes, then I would consider this bug resolved because at that point it won't matter whether preventDefault works. :)

Comment 7

[Kartikaya Gupta (email:[e-mail])]

I updated my test page at http://people.mozilla.com/~kgupta/bug/885195.html to have a canvas that occupies all of the available screen area. There is still no panning/zooming. If it still doesn't work for you please attach a full test page that demonstrates the problem.

Comment 8

[Katelyn Gadd (:kael)]

I had to mess around some to come up with something resembling a reliable reproduction case for this.

http://jsil.org/tts/test demonstrates this (and other problems) in both Firefox Beta for Android and Chrome for Android.

Updates to my runtime eliminated the GC pauses, so I added 250ms spin-waits into touchstart/touchmove events that occur on random probability. If you swipe around repeatedly on the viewport eventually a pause will kick off and a scroll will occur.

Note that it is not intrinsically bad that the browser considers this page scrollable; there is apparently more content than fits onto a typical device screen at whatever DPI Firefox and Chrome choose, and it's not possible to actually get browsers to run at 1:1 DPI. The problem is that every available directive for preventing scrolling does not seem to actually work. 

Earlier I accidentally tweaked the layout, causing the page content to get smaller and fall under the size of the browser's virtual viewport, and scrolling wouldn't happen anymore. You can uncomment the JS in index.html to hide the 'log' element and reproduce this manually if you rehost the script.

I should also note that I tried using meta viewport to set the viewport to the size of the page and this did not suppress scrolling either. I'm not convinced meta viewport does anything at all.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kevin Gadd (:kael) from comment #8)
> Note that it is not intrinsically bad that the browser considers this page
> scrollable; there is apparently more content than fits onto a typical device
> screen at whatever DPI Firefox and Chrome choose, and it's not possible to
> actually get browsers to run at 1:1 DPI. The problem is that every available
> directive for preventing scrolling does not seem to actually work. 
> 
> Earlier I accidentally tweaked the layout, causing the page content to get
> smaller and fall under the size of the browser's virtual viewport, and
> scrolling wouldn't happen anymore. You can uncomment the JS in index.html to
> hide the 'log' element and reproduce this manually if you rehost the script.

Isn't this exactly the solution to your problem though? The reason you're getting scrolling is precisely because your page content exceeds the viewport size. Making it fit will eliminate the scrolling. If you want your page content to exceed the viewport size *and* not have scrolling (which should be possible with a container element with appropriate overflow), then the stuff outside the viewport will never be visible, by definition, and so there's no sense in having it there at all.

> I should also note that I tried using meta viewport to set the viewport to
> the size of the page and this did not suppress scrolling either. I'm not
> convinced meta viewport does anything at all.

Meta viewport isn't some magic incantation that will override everything else the page is trying to do. It's just one tool available to web authors to accomplish a specific thing. If you set a meta viewport that conflicts with what the rest of your page is doing (i.e. stuffing too much content into the viewport area) then things may not work as you want them to.

I'm not convinced there is a browser bug here at all. It's perfectly possible to have a non-scrollable page with a canvas that occupies all of the visible area, as I've shown in comment 7. As such I'm going to close this as invalid. If you have a specific page that doesn't work the way it's supposed to according to documented specifications then feel free to reopen.

Comment 10

[Katelyn Gadd (:kael)]

https://developer.mozilla.org/en-US/docs/Web/CSS/overflow

"hidden
    The content is clipped and no scrollbars are provided."


https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag

"For pages that set an initial or maximum scale, this means the width property actually translates into a minimum viewport width. For example, if your layout needs at least 500 pixels of width then you can use the following markup. When the screen is more than 500 pixels wide, the browser will expand the viewport (rather than zoom in) to fit the screen:"


Neither of these statements from the documentation actually describe mobile Gecko's behavior. I won't claim that Gecko's actual behavior deviates from the spec, but I don't know how you can argue that nothing is wrong here when the browser's behavior actively contradicts documentation *and* contradicts user expectations based on how features work on desktop and how they are described to work in user-readable documentation and specifications. CSS 2.1, for example, does not describe any reasons why overflow: hidden would ever be ignored. I do not see this new behavior documented in the CSS 3 overflow module either.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kevin Gadd (:kael) from comment #10)
> https://developer.mozilla.org/en-US/docs/Web/CSS/overflow
> 
> "hidden
>     The content is clipped and no scrollbars are provided."
> 

Ok, fair point. I missed this in your original test case. I have filed bug 886969 to track this.

> https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
> 
> "For pages that set an initial or maximum scale, this means the width
> property actually translates into a minimum viewport width. For example, if
> your layout needs at least 500 pixels of width then you can use the
> following markup. When the screen is more than 500 pixels wide, the browser
> will expand the viewport (rather than zoom in) to fit the screen:"
> 
> 
> Neither of these statements from the documentation actually describe mobile
> Gecko's behavior.

You'll have to explain a bit better what you think Fennec is doing wrong here. Setting the initial and maximum scale doesn't set an upper bound on the size of the viewport.

Comment 12

[Katelyn Gadd (:kael)]

"I should also note that I tried using meta viewport to set the viewport to the size of the page and this did not suppress scrolling either."

I set the viewport to be bigger than the page content and it still scrolled. As far as I could tell it was not adjusting the virtual coordinates or view settings used by the browser at all. Maybe the problem is DPI awareness?

Comment 13

[Kartikaya Gupta (email:[e-mail])]

Setting the viewport to be greater than or equal to the page content will not necessarily suppress scrolling. The viewport size specified in the meta-viewport tag sets the CSS viewport of the page, which determines the default width at which the page is laid out. If that width is larger than the screen size then the page will still scroll.

The meta-viewport tag on your game is this:

<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=no, target-densitydpi=device-dpi">

This means the page will get laid out at a 1.0 scale, not be scalable, and the content will be laid out to the device width where possible. However, if the content on the page exceeds the device width (e.g. if you had a <div style="width: 100000px">) then the page would still be 100000 pixels wide and scroll horizontally. If your page is narrower than screen width but taller, it will still scroll vertically.

Note also that we do not intend to support target-densitydpi (bug 737090) but I don't believe that is a factor here.

Comment 14

[Katelyn Gadd (:kael)]

OK, your description of how the viewport actually works (setting the CSS viewport size, not the virtual screen size) explains why it didn't work when I tried setting it to the size of the content.

So in practice viewport only lets you *reduce* the size of the CSS viewport below the screen size; raising it above will scroll? That sounds correct even if I've never seen it documented anywhere, so I don't think that needs to be a bug. It's not necessary to use viewport to suppress scrolling if overflow works anyway.

Comment 15

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kevin Gadd (:kael) from comment #14)
> So in practice viewport only lets you *reduce* the size of the CSS viewport
> below the screen size; raising it above will scroll?

Yes. I'll leave this bug open for now but the work to fix overflow:hidden will be done in bug 886969.

Comment 16

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.