775614 - Investigate painting failure in tcheck, tcheck2, tcheck3

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

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

https://bugzilla.mozilla.org/show_bug.cgi?id=775071#c6

Running tcheckerboard3 results in the following assertion failure in the log:

NOISE: __FAILchecking that painted surface loaded: painted surface loaded__FAIL

This should be investigated and fixed. Note that bug 775610 will make this test start failing if this issue is not fixed first.

Comment 1

[Geoff Brown [:gbrown]]

I see this happening in tcheck and tcheck2 also. 

I cannot reproduce it locally, but a try run at https://tbpl.mozilla.org/?tree=Try&rev=29d64fda2509 suggests that FennecNativeDriver.getSurfaceView is returning null.

Comment 2

[Geoff Brown [:gbrown]]

Another try run at https://tbpl.mozilla.org/php/getParsedLog.php?id=13758009&tree=Try&full=1 shows that getSurfaceView sees current views:

NOISE: view: android.widget.RelativeLayout@4844fe20
NOISE: view: android.widget.ScrollView@48450398
NOISE: view: android.widget.LinearLayout@484a2778
NOISE: view: org.mozilla.gecko.DoorHanger@4845a2a0
NOISE: view: android.widget.TextView@48449170
NOISE: view: android.widget.CheckBox@4840b3b0
NOISE: view: android.widget.LinearLayout@48447c50
NOISE: view: android.widget.Button@48448190
NOISE: view: android.widget.Button@484a3058
NOISE: view: android.widget.ImageView@484a29e0
NOISE: view: android.widget.PopupWindow$PopupViewContainer@4841ab38

Since none of these is a LayerView, getSurfaceView fails.

Waiting for a few seconds and retrying produces the same views and failure.

Comment 3

[Geoff Brown [:gbrown]]

In contrast, when getSurfaceView succeeds on a local device, I see more current views:

NOISE: view: android.widget.FrameLayout@48160dd0
NOISE: view: android.widget.RelativeLayout@48162368
NOISE: view: org.mozilla.gecko.TabsPanel@48162cc0
NOISE: view: org.mozilla.gecko.TabsPanel$TabsPanelToolbar@48163b98
NOISE: view: android.widget.LinearLayout@48164420
NOISE: view: android.widget.TextView@48164a58
NOISE: view: android.widget.ImageButton@48165f30
NOISE: view: android.widget.ImageButton@48167648
NOISE: view: android.widget.RelativeLayout@48167e88
NOISE: view: org.mozilla.gecko.TabsPanel$TabsListContainer@48168760
NOISE: view: android.view.View@4816a6c8
NOISE: view: android.widget.LinearLayout@4816b628
NOISE: view: android.widget.LinearLayout@48171e40
NOISE: view: android.widget.RelativeLayout@48172088
NOISE: view: android.widget.ImageButton@48172480
NOISE: view: android.widget.ImageButton@48172728
NOISE: view: android.widget.LinearLayout@481729d8
NOISE: view: android.view.View@48172ca8
NOISE: view: android.view.View@481730b0
NOISE: view: android.widget.ImageButton@48173798
NOISE: view: android.widget.ImageButton@48173a00
NOISE: view: android.widget.TextSwitcher@48175668
NOISE: view: android.widget.TextView@4817b060
NOISE: view: android.widget.TextView@4817b510
NOISE: view: android.widget.Button@48175be8
NOISE: view: android.widget.ImageButton@48177320
NOISE: view: android.widget.LinearLayout@481777e8
NOISE: view: android.widget.ImageButton@48177a78
NOISE: view: android.widget.ImageButton@48177f28
NOISE: view: android.widget.ImageButton@48178e60
NOISE: view: android.widget.ImageView@48179568
NOISE: view: android.widget.RelativeLayout@4816b918
NOISE: view: org.mozilla.gecko.gfx.LayerView@48127960
...

Comment 4

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

Looks like it's hitting a doorhanger. Any idea which one? Perhaps you need to clear your profile locally to repro it?

Comment 5

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

Moving over to you since you seem to be doing all the work anyway :)

Comment 6

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

If I clear my profile and load a page in Nightly, then the doorhanger I get is the telemetry "Send info to Mozilla so that we can improve Nightly? Learn more". I'm guessing this popup is more aggressive now, I don't remember it showing up on a page load before, just on startup.

Comment 7

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

Update: this appears to be a race condition in the doorhanger code. What is happening on startup is:

1) telemetry code gets initialized and sends the telemetry "show doorhanger" message to java
2) java processes that message and enters GeckoApp.handleDoorHanger, which defers the actual creation of the doorhanger to a runnable on the UI thread
3) the about:home page gets loaded and sends a location change event to java. the doorhanger is not yet created and so this location change doesn't decrement the doorhanger's persistence counter as expected
4) the doorhanger is created with mPersistence=1, and so lasts until after another page has loaded.

This could occur during normal browsing as well, if a new page is navigated to in between steps 2 and 4, and could result in a doorhanger from the previous page showing up on the current page.

Comment 8

[Geoff Brown [:gbrown]]

I think we normally avoid Telemetry doorhanger complications in mochitest-robocop by setting toolkit.telemetry.prompted=2. It looks like that pref is not set for Talos tests.

Comment 9

[Joel Maher ( :jmaher ) (UTC -8)]

Good call.  I really wish we could keep these preferences the same.  Want me to file and land a bug for that?

Comment 10

[Geoff Brown [:gbrown]]

Sure - thanks!

Comment 11

[Geoff Brown [:gbrown]]

For good measure, I verified that the telemetry doorhanger does not display and the __FAIL message is not reported if the Talos yml file contains:

preferences:
 ...
  toolkit.telemetry.prompted: 2

Comment 12

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: add telemetry prompt supression to talos (1.0)

Comment 13

[Jeff Hammel]

Comment on attachment 645440 [details] [diff] [review]
add telemetry prompt supression to talos (1.0)

wfm

Comment 14

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

Hm. I guess we should break out comment 7 into a new bug then. Will file and cc margaret who's working on that.

Comment 15

[Joel Maher ( :jmaher ) (UTC -8)]

can we deploy a new talos with this pref set, or should we wait for comment 7 to be fixed?

Comment 16

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

With the pref set you should be able to deploy a new talos.

I filed bug 777045 for comment 7.

Comment 17

[Joel Maher ( :jmaher ) (UTC -8)]

talos bits landed:
http://hg.mozilla.org/build/talos/rev/07322bbe0f7d

since new bug is opened, I will close this one.