1043700 - After logging into FMD site (https://find.firefox.com), the FMD site experiences a massive amount of flickering while the site loads

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Jason Smith [:jsmith]]

Build Information
Device: Flame
Gaia      29266e18c35f4e72e35f1bba0e34f2fb6b995cc3
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/178fe2efc41d
BuildID   20140724000201
Version   32.0

Description

Loading of the FMD site (find.firefox.com) after logging in experiences massive flickering until the site is fully loaded.

Steps to Reproduce

1. Go to find.firefox.com
2. Login with an existing FxAccount paired to a device with FMD enabled

Expected Results

Site should have a smooth loading sequence.

Actual Results

Site experiences a massive amount of flickering during loading.

Other Notes

Kate can't reproduce this on her device, but I've seen this consistently on my account.

Reproduction Frequency: 100% for my account only

Comment 1

[Jason Smith [:jsmith]]

Video here: https://drive.google.com/file/d/0ByOpueKMbyhuVmhhcnlpNjFreDA/edit?usp=sharing

Comment 2

[Jason Smith [:jsmith]]

Can anyone else reproduce this? QA Wanted to check across a couple of Flame devices.

Comment 3

[Jason Smith [:jsmith]]

Attachment: Logcat

Comment 4

[Jason Smith [:jsmith]]

Milan - The video here makes me think this looks like a gfx issue. What do you think?

Comment 5

[Marcia Knous [:marcia]]

I can reproduce this on my 512 Flame using:

Gaia   29266e18c35f4e72e35f1bba0e34f2fb6b995cc3
SourceStamp 178fe2efc41d
BuildID 20140724000201
Version 32.0

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

I'll take a look, but right now find.firefox.com seems to be offline.

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Milan Sreckovic [:milan] from comment #6)
> I'll take a look, but right now find.firefox.com seems to be offline.

Needs https.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: With paint flashing, on Nexus-4

Different phone, probably the same issue, and :benwa points to invalidation messing up.  Markus, any thoughts?  You seem to "like" invalidation type issues.

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

qawanted for seeing what this looks like when the phone gets to the non-mobile version of https://find.firefox.com - can somebody spoof the UA and try it?

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: Example when deleting a phone - the spin icon is showing through?

This looks like the element that is spinning is invaliding the "do you really want to delete" even though it's underneath it.

Comment 11

[Markus Stange [:mstange]]

(In reply to Milan Sreckovic [:milan] from comment #8)
> Markus, any thoughts?  You seem to "like" invalidation type
> issues.

I do! :)
The originally reported bug could be caused by missing invalidations, but the video in comment 8 looks more like there is too much invalidation going on. So maybe not the same issue. In any case, both are bugs worth fixing, so I'll take a look. Won't be before Monday though.

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

Thanks.
As another data point - this shows up with tiling off as well.

Comment 13

[Markus Stange [:mstange]]

With a very recent mozilla-central gecko on my Hamachi I couldn't reproduce any of the reported problems: Nothing was flickering, paint flashing only showed expected repaints, and all objects were present on the page. The only thing that was off was that the Firefox logo had a black background (instead of transparent one) - but this fixed itself after I logged out and back in.
I'm now compiling a gecko with rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/178fe2efc41d .

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

Markus, any data I can collect that would help? I see this on Nexus-4, let me see if I can get it on Hamachi.  We should also get you a Flame :)

Comment 15

[Markus Stange [:mstange]]

(In reply to Milan Sreckovic [:milan] from comment #14)
> Markus, any data I can collect that would help?

Full display list dumps would make the analysis really simple, but I think you can only get those if your build was compiled with MOZ_DUMP_PAINTING=1. That's what I used in my latest build, but unfortunately it doesn't boot. Not sure why yet.

I'll also try to reproduce this with Desktop builds of the right version.

> We should also get you a Flame :)

I'm getting one, I should have it in a few days.

Comment 16

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: With B2G_DUMP_PAINTING

Comment 17

[Markus Stange [:mstange]]

Hmm, not that simple after all, the display list looks normal.

My Flame has arrived and it reproduces the original flickering bug, so I hope I'll have more to say tonight.

Comment 18

[Milan Sreckovic [:milan] (needinfo for best results)]

Fallout from bug 1022612?

Comment 19

[Markus Stange [:mstange]]

The flickering is happening on the 32 channel, and bug 1022612 is only fixed on 34, so no.

Comment 20

[Markus Stange [:mstange]]

Attachment: reduced testcase

Loading this file in the browser on my Flame shows the flickering.

Comment 21

[Markus Stange [:mstange]]

The flickering happens due to low memory. For devices with a device pixel ratio of 1.3 or higher, the FMD page uses this background image: file:///Users/mstange/Dropbox/tests/Find%20My%20Device_files/[e-mail] .
It's 4000 × 1900 pixels big, which takes up 30.4MB in decoded form.
The spinner image and the background image compete for memory and only one of them can be displayed at the same time. The blank screens happen when both images have just been discarded and are redecoded.

Comment 22

[Markus Stange [:mstange]]

Attachment: SVG alternative

Using SVG for this image might be a good idea because SVG images don't really have a fixed decoded size. The GFX surfaces we allocate for them are at the size that we actually paint, so if there's a big part of the image offscreen, as in this case, we don't waste memory on that part.
However, their first paint takes longer.

On FMD, using this SVG image instead of the existing [e-mail] successfully fixes the flickering problem, but adds about one second to the initial rendering time. This feels like a lot, I should probably profile it.

Comment 23

[Markus Stange [:mstange]]

(In reply to Markus Stange [:mstange] from comment #21)
> The flickering happens due to low memory. For devices with a device pixel
> ratio of 1.3 or higher, the FMD page uses this background image:
> file:///Users/mstange/Dropbox/tests/Find%20My%20Device_files/948c891b.bg@2x.
> png .

Err, that's https://find.firefox.com/images/[e-mail] .

Comment 24

[Nick Chapman [:nchapman]]

Sorry to have not joined this conversation sooner. :mstange thanks for your suggestions. We are currently using the same assets on desktop as mobile which is not ideal. I'll work on smaller assets for mobile to see if we can fix the flickering problem.

Comment 25

[Markus Stange [:mstange]]

Good, that's probably a better solution than using SVG. If you can just use a cropped image for devices that aren't wider than a certain threshold, that should give us the best of both worlds.

Comment 26

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Markus Stange [:mstange] from comment #21)
> The flickering happens due to low memory. For devices with a device pixel
> ratio of 1.3 or higher, the FMD page uses this background image:
> file:///Users/mstange/Dropbox/tests/Find%20My%20Device_files/948c891b.bg@2x.
> png .
> It's 4000 × 1900 pixels big, which takes up 30.4MB in decoded form.
> The spinner image and the background image compete for memory and only one
> of them can be displayed at the same time. The blank screens happen when
> both images have just been discarded and are redecoded.

Just to clarify, the "low memory" that Markus talks about isn't the amount of memory available on the phone - we are just running against the preference for maximum size of the decoded images - which is currently set to 30MB on B2G (50MB on desktop.)  So, with such a large image, nothing else can fit, and what Markus describes happens.  But just adding more memory to the phone doesn't help.

I can reproduce this on Nexus 4 with the default configuration.  If I set the preference image.mem.max_decoded_image_kb to 80MB, the problem goes away.

Comment 27

[Peter deHaan [:pdehaan]]

Not sure why this isnt filed against FMD anymore since this is basically an FMD asset loading issue, but I filed this in our FMD GitHub repo at https://github.com/mozilla-services/FindMyDevice/issues/272 for tracking.

Comment 28

[Dietrich Ayala (:dietrich)]

Triage group reviewed this, found it doesn't meet blocking criteria (https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines) so not holding the release on it.

Vishy, please re-nominate if you think this should block the release.

Comment 29

[vkrishnamoorthy]

I agree. To Peter's point, should this be with the graphics team or the FMD web team to provide smaller assets?

Comment 30

[Milan Sreckovic [:milan] (needinfo for best results)]

Not sure why Jason changed it to graphics, it certainly looks like a asset issue.

Comment 31

[Peter deHaan [:pdehaan]]

Spoiler alert: This was an FMD website issue and was already fixed with https://github.com/mozilla-services/FindMyDevice/pull/273 (but I don't think that code has been deployed to prod yet).

Feel free to close this issue down (or keep it up until :jsmith or whoever can verify it live in prod).

Comment 32

[Jason Smith [:jsmith]]

(In reply to Milan Sreckovic [:milan] from comment #30)
> Not sure why Jason changed it to graphics, it certainly looks like a asset
> issue.

Ok - closing this then.