Closed Bug 1042772 Opened 5 years ago Closed 5 years ago

Homescreen edit mode not painting correctly when many icons

Categories

(Core :: Layout, defect)

All
Gonk (Firefox OS)
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla34
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.0M --- unaffected
b2g-v2.1 --- verified

People

(Reporter: magopian, Assigned: tnikkel, NeedInfo)

References

Details

(Keywords: regression, smoketest)

Attachments

(5 files)

This is on a Firefox Flame with the latest source built (which includes the fixes for bug 1041510).

When in the homescreen edit mode, if i scroll down enough, all the icons flash once, and then disappear. This seems to happen only if I scroll down enough.

Here's a video to demonstrate the issue: https://www.youtube.com/watch?v=gchdYXCvigY
Does not repro on today's 2.0. I used the eng build as shown on the video.

[Blocking Requested - why for this release]: Bad user experience.
blocking-b2g: --- → 2.1?
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-]
Component: Gaia::Homescreen → Panning and Zooming
Product: Firefox OS → Core
Whiteboard: [systemsfe]
Johan - I think this isn't a systemsfe issue, as systemsfe doesn't work in the scope of graphics issues. Milan's team deals with this. On that regard, I think we should remove the systemsfe whiteboard here. Does that make sense?
Flags: needinfo?(jlorenzo)
This is also likely a regression from bug 1022612. It might be fixed by some of the other work in progress to fix those regressions.
Blocks: 1022612
Component: Panning and Zooming → Layout
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → All
Clearing the window request under the assumption that bug 1022612 is the cause. If you think we should do manual confirmation of that window, then feel free to flag the window request again.
I did a quick investigation here and it seems to be the same problem described in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1041608#c20 - that is, the visible region of the scrollable container layer shrinks as I scroll down the homescreen, and then eventually it becomes not visible and things stop painting.
Here's a dump of the homescreen displaylist and other stuff as I scroll down. Layer 0xb25fd000 is the ContainerLayer that becomes [not visible] halfway down. The code I'm running includes the fix from bug 1042100, so there's some other problem here.
The origin of the vis rect for the scroll layer display item still looks like it is changing with the scroll position.
(In reply to Jason Smith [:jsmith] from comment #2)
> Johan - I think this isn't a systemsfe issue, as systemsfe doesn't work in
> the scope of graphics issues. Milan's team deals with this. On that regard,
> I think we should remove the systemsfe whiteboard here. Does that make sense?

Yes, it does. Sorry, my mistake.
Flags: needinfo?(jlorenzo)
Whiteboard: [systemsfe]
The problem is that the underlying frame for some scroll layer items (like the ones we create to wrap positioned items) is the positioned frame, and not the scroll frame. But when we create the scroll layer items the dirty rect on the builder is relative to and for the scroll frame. So when we init the vis rect in the display item constructor we use the wrong offset (from the positioned frame contained in the scroll frame, instead of from the scroll frame) to add to the dirty rect on the builder.
Duplicate of this bug: 1043610
Keywords: smoketest
Timothy, let us know if somebody else should look at this instead.
Assignee: nobody → tnikkel
(In reply to Timothy Nikkel (:tn) from comment #9)
> The problem is that the underlying frame for some scroll layer items (like
> the ones we create to wrap positioned items) is the positioned frame, and
> not the scroll frame. But when we create the scroll layer items the dirty
> rect on the builder is relative to and for the scroll frame. So when we init
> the vis rect in the display item constructor we use the wrong offset (from
> the positioned frame contained in the scroll frame, instead of from the
> scroll frame) to add to the dirty rect on the builder.

The current code for setting the visible rect is:
  mVisibleRect = aBuilder->GetDirtyRect() +
      aBuilder->GetCurrentFrameOffsetToReferenceFrame();
so it doesn't care what the underlying frame for the item is. So I don't understand the problem.
The nsDisplayWrap sets it differently, using mToReferenceFrame and not the current frame offset. I have a patch that fixes it, but I just have to understand the clump of code in the nsDisplayWrapList constructor first to make sure it's correct. I got sidetracked finishing up some reviews this week.
It doesn't cause any problems because offsetToReferenceFrame is always 0,0 for transformed frames because the reference frame we are using for the offset is |this|.
Attachment #8469106 - Flags: review?(roc)
It's always 0,0 because we are transformed so we our the reference frame we find.

It isn't clear if the offset passed to UntransformRect is important or not. Do we actually want the offset to the ancestor reference frame or is 0,0 what we want?
Attachment #8469108 - Flags: review?(matt.woodrow)
This is the actual fix.

We have a clear dividing line between inside and outside the transform here, set the reference frame and offset correctly when we move outside the transform so we can use it.
Attachment #8469110 - Flags: review?(roc)
Attachment #8469108 - Flags: review?(matt.woodrow) → review+
This caused a failure in layout/reftests/svg/blend-difference-stacking.html, backed out:
https://hg.mozilla.org/integration/mozilla-inbound/rev/abff854401bd
The problem was we were getting the wrong reference frame. The reference frame has already been updated for us by nsFrame::BuildDisplayListForChild, so we were just getting the same inner reference frame for our transform.

I'll fold this into part 3 before pushing. Separate for ease of review.
Attachment #8469608 - Flags: review?(roc)
Is it possible to write a test for this?
ni for comment 20
Flags: needinfo?(tnikkel)
Duplicate of this bug: 1045747
blocking-b2g: 2.1? → 2.1+
this issue is verified fixed on flame 2.1 

with many apps on the home screen going into edit mode and swiping up no longer causes blank screens to happen.


Flame 2.1 KK (319mb) (Full Flash)

Device: Flame 2.1 KK (319mb) (Full Flash)
BuildID: 20141012001201
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-] → [VH-FL-blocking-][VH-FC-blocking-] [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-] [QAnalyst-Triage?] → [VH-FL-blocking-][VH-FC-blocking-] [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Depends on: 1091000
Depends on: 1103165
Depends on: 1106081
You need to log in before you can comment on or make changes to this bug.