1150693 - samsung tab loads blank pages, null ptr exception thrown

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Allison Naaktgeboren :ally]

My nightly appears to not be loading any content, google.com, facebook.com, slate.com, etc. It is however correctly capturing thumbnails for the content I am not seeing.

I see the following in the error console 

04-02 13:54:07.107  30309-30309/org.mozilla.fennec_mozilla E/GeckoEvent﹕ Error creating motion point 0
    java.lang.NullPointerException
            at org.mozilla.gecko.GeckoEvent.addMotionPoint(GeckoEvent.java:439)
            at org.mozilla.gecko.GeckoEvent.initMotionEvent(GeckoEvent.java:415)
            at org.mozilla.gecko.GeckoEvent.createLongPressEvent(GeckoEvent.java:387)
            at org.mozilla.gecko.gfx.JavaPanZoomController.onLongPress(JavaPanZoomController.java:1364)
            at android.view.GestureDetector.dispatchLongPress(GestureDetector.java:1564)
            at android.view.GestureDetector.access$200(GestureDetector.java:47)
            at android.view.GestureDetector$GestureHandler.handleMessage(GestureDetector.java:334)
            at android.os.Handler.dispatchMessage(Handler.java:102)
            at android.os.Looper.loop(Looper.java:136)
            at android.app.ActivityThread.main(ActivityThread.java:5579)
            at java.lang.reflect.Method.invokeNative(Native Method)
            at java.lang.reflect.Method.invoke(Method.java:515)
            at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1268)
            at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1084)
            at dalvik.system.NativeStart.main(Native Method)

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

Ally are you actually performing a long press to get this?

Comment 2

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

Can you attach a full logcat from starting fennec onwards? The exception in comment 0 is caught, logged, and gracefully handled in the code. The root cause is likely earlier.

Comment 3

[Allison Naaktgeboren :ally]

Snorp, no no long press.

Comment 4

[Allison Naaktgeboren :ally]

Attachment: logcat_tablet_nexus_10_white_screen.txt

it surfaced again on my tablet. attached is to logcat. I hope you find something useful :)

Comment 5

[Allison Naaktgeboren :ally]

Attachment: logcat_whitescreen_nexus10_2

this logcat is from a shorter run

Comment 6

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

So as far as I can tell the addMotionPoint exception would only happen if GeckoLayerClient::mGeckoIsReady is false, because that's the only condition under which convertViewPointToLayerPoint returns null. However from the log I see various messages arriving in Java (such as Tab:ViewportMetadata) which are sent from gecko, so clearly gecko *is* ready. Somehow the notification was not sent or got dropped or something, and so the java-side gfx code is still under the impression that gecko is not up yet.

The java-side code that manages startup seems to have changed quite a bit since I last looked around (in particular there appears to be a listener for Gecko:Ready in GeckoView.java, and I'm not familiar with that at all) so somebody else who is more current on the code would probably be able to track this down quicker. It may be something simple, like the Gecko:Ready message listener isn't registered until after the message arrives from Gecko.

Comment 7

[James Willcox (:snorp) ([e-mail]) (he/him)]

Interesting. I wonder if this is the cause of all our remaining "blank content view" issues. Jim please look at this.

Comment 8

[(inactive) Jim Chen [:jchen] [:darchons]]

Attachment: Avoid possible race condition when sending pending Gecko events (v1)

This patch fixes a race condition in how we handle pending events to Gecko before Gecko is loaded. I think that race condition could lead to events arriving out of order or not being sent at all once Gecko is loaded. This is from Java to Gecko though, not from Gecko to Java, so I'm not sure if it'll help with this bug, but it's worth a try I guess.

Comment 9

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8592307 [details] [diff] [review]
Avoid possible race condition when sending pending Gecko events (v1)

Review of attachment 8592307 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, I like it

Comment 10

[(inactive) Jim Chen [:jchen] [:darchons]]

Attachment: Register Gecko:Ready earlier in GeckoApp (v1)

Move event registration from GeckoApp.initialize to GeckoApp.onCreate. This fixes a potential race condition because GeckoApp.initialize is only called when our main window is shown, which technically can happen after Gecko is loaded. This also fixes bugs like bug 1055689.

Comment 11

[(inactive) Jim Chen [:jchen] [:darchons]]

Attachment: Initialize GeckoThread, before registering GeckoApp events, before launching Gecko (v1)

For several reasons, we have to let GeckoThread register for Gecko:Ready before GeckoApp does. On the other hand, to avoid racing, we want GeckoApp to register for Gecko:Ready before GeckoThread actually runs.

This patch separates GeckoThread creation into two steps - initialization and launch. With this patch, GeckoApp first initializes GeckoThread, then registers for Gecko:Ready, and finally launches GeckoThread. This way both conditions above are satisfied.

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/e5c80ba79bee
https://hg.mozilla.org/integration/fx-team/rev/3333c1e20789
https://hg.mozilla.org/integration/fx-team/rev/f1a9e793e6e4

Comment 13

[Gregory Szorc [:gps]]

https://hg.mozilla.org/integration/fx-team/rev/1e4ac5801104
https://hg.mozilla.org/integration/fx-team/rev/ab69b7bd949a
https://hg.mozilla.org/integration/fx-team/rev/487d4236c73f

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/1e4ac5801104
https://hg.mozilla.org/mozilla-central/rev/ab69b7bd949a
https://hg.mozilla.org/mozilla-central/rev/487d4236c73f

Comment 16

[(inactive) Jim Chen [:jchen] [:darchons]]

Comment on attachment 8592307 [details] [diff] [review]
Avoid possible race condition when sending pending Gecko events (v1)

Approval Request Comment

[Feature/regressing bug #]: N/A

[User impact if declined]: Blank page after starting Fennec on rare occasions

[Describe test coverage new/current, TreeHerder]: m-c; locally

[Risks and why]: Somewhat risky because it's a pretty big change (and we've had a regression from this already, bug 1158309)

[String/UUID change made/needed]: None

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8592307 [details] [diff] [review]
Avoid possible race condition when sending pending Gecko events (v1)

This landed on m-c when it was still Gecko 40, so it doesn't need to land on Aurora.

Comment 18

[Liz Henry (:lizzard)]

jchen: since this sounds risky, I'd like to let this ride with 40 -- unless you think it's a problem that many users are running into and we really, really need it in beta 39. 

Snorp do you have an opinion here? You mentioned possible other issues with blank pages. Is this a common problem?

Comment 19

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Liz Henry (:lizzard) from comment #18)
> jchen: since this sounds risky, I'd like to let this ride with 40 -- unless
> you think it's a problem that many users are running into and we really,
> really need it in beta 39. 
> 
> Snorp do you have an opinion here? You mentioned possible other issues with
> blank pages. Is this a common problem?

I'm fine with letting this ride. There were some other fixes that went into 40 for this issue too, I think, and they're all kind of related.

Comment 20

[(inactive) Jim Chen [:jchen] [:darchons]]

Comment on attachment 8592307 [details] [diff] [review]
Avoid possible race condition when sending pending Gecko events (v1)

I think that's reasonable.

Comment 21

[Liz Henry (:lizzard)]

OK, thanks!