Closed
Bug 1047069
Opened 10 years ago
Closed 10 years ago
Homescreen edit-mode falls back to sync scrolling
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: kats, Unassigned)
References
Details
Attachments
(2 files)
+++ 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.
Comment 1•10 years ago
|
||
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.
Reporter | ||
Comment 2•10 years ago
|
||
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
Comment 3•10 years ago
|
||
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.
Comment 4•10 years ago
|
||
Making this print out even more stuff may not be desirable either, it already outputs a fair bit.
Reporter | ||
Comment 5•10 years ago
|
||
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.
Reporter | ||
Updated•10 years ago
|
Depends on: multi-layer-apz
Updated•10 years ago
|
Attachment #8466193 -
Attachment mime type: text/x-vhdl → text/plain
Comment 6•10 years ago
|
||
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.
Comment 7•10 years ago
|
||
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.
Comment 8•10 years ago
|
||
(That's assuming that we can use APZ scrolling again when the user releases the icon.)
Reporter | ||
Comment 9•10 years ago
|
||
(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.
Reporter | ||
Comment 10•10 years ago
|
||
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
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•