Homescreen edit-mode falls back to sync scrolling

RESOLVED WORKSFORME

Status

()

Core
Layout
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: kats, Unassigned)

Tracking

Trunk
All
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Created attachment 8465783 [details]
Logcat snippet

+++ This bug was initially created as a clone of Bug #1035917 +++

On a Flame running recent master, long-press an icon on the homescreen to enter the homescreen edit mode. In logcat I see the attached. (The output is truncated probably because we're not doing the "dump every line individually" thing).

This indicates that the homescreen edit-mode (or some part of it) isn't panning asynchronously.
The output isn't all that helpful: it doesn't show the interleaved display items, only one scroll layer item. The full display list dump would be useful here.
The printf at [1] needs to look like the goop at [2] for the output to not be truncated. We really need a helper function to print these long lines.

[1] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList.cpp?rev=4d0dce40c8eb#4069
[2] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp?rev=05eb059f70bf#3084
I don't think the truncation is the problem, we just aren't printing the right things to get the proper context here because they aren't super easily accessible.
Making this print out even more stuff may not be desirable either, it already outputs a fair bit.
Created attachment 8466193 [details]
Full log with displaylist dumping

Ok, I grabbed a full logcat with display list dumping turned on. Presumably this should provide enough info. The "Async scrollable layer creation failed" message happens on line 723.
See Also: → bug 1047403
Depends on: 967844
Attachment #8466193 - Attachment mime type: text/x-vhdl → text/plain
This looks like it only fails when we are dragging an icon, it is made transparent and gets moved above everything on the page including the "Edit | Done" bar at the top. If we aren't dragging an icon it looks like we will get normal async scrolling. When we are dragging an icon the dragged icon is at the top, then the "Edit | Done" bar, then the rest of the icons, and the "Edit | Done" bar doesn't scroll. So this is actually a cause of scrolling and non-scrolling content visually interleaving (I think this is the first time we've had such a case). If we wanted a short term gaia side fix before bug 967844 gets fixed we could put the currently dragged icon below the "Edit | Done" bar, but above the other icons.
Does this cause anything bad to happen? In 2.0 the user can not smooth scroll while dragging an icon around anyway. If we are doing bug 967844 in 2.1, then I think it just makes sense to wait for that.
(That's assuming that we can use APZ scrolling again when the user releases the icon.)
(In reply to Kevin Grandon :kgrandon from comment #7)
> Does this cause anything bad to happen?

Not particularly. I just saw the warning in logcat and so filed a bug for it.

> In 2.0 the user can not smooth
> scroll while dragging an icon around anyway. If we are doing bug 967844 in
> 2.1, then I think it just makes sense to wait for that.

Sounds good. And yes based on what tn said it sounds like we should drop back to APZ scrolling when the user releases the icon.
See Also: → bug 1064918
This doesn't happen any more. Makes sense since bug 967844 is fixed now, but I didn't confirm that's what fixed it.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.