1038012 - Run Search Activity's GeckoView in separate process and separate profile

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: Search Activity, defect)

Description

[Nick Alexander :nalexander [he/him]]

It needs to be done in order to continue using GeckoView for the Search Activity.

Comment 1

[Nick Alexander :nalexander [he/him]]

Attachment: Part 0: Don't let ProGuard discard Fragments. r=mfinkle

The presenting Fragments are those of the Search Activity; but in
general, Fragments are referred to by class at runtime, so they must be
preserved.

Comment 2

[Nick Alexander :nalexander [he/him]]

Attachment: Part 1: Make mProfile final in BaseGeckoInterface. r=mfinkle

You can't change the profile, or disconnect a GeckoInterface from a
running Gecko thread, so it can be final.  In addition, GeckoView itself
should extract the profile used to create any Gecko threads from the
specified GeckoInterface itself.

Comment 3

[Nick Alexander :nalexander [he/him]]

Attachment: Part 2: Run Search Activity in its own process. r=mfinkle

Comment 4

[Nick Alexander :nalexander [he/him]]

Attachment: Part 3: Set GeckoInterface and GeckoProfile during Search Activity creation. r=mfinkle

Comment 5

[Nick Alexander :nalexander [he/him]]

Attachment: Part 4: Interact with GeckoView only after Gecko is ready. r=mfinkle

Comment 6

[Nick Alexander :nalexander [he/him]]

Attachment: Part 5: The last created GeckoView should always be current. r=mfinkle

This works around the following event processing exception when
(re-)connecting to an already running Gecko:

E GeckoTouchEventHandler(20377)                           Unexpected empty event queue in processEventBlock!
E GeckoTouchEventHandler(20377)                           java.lang.Exception
E GeckoTouchEventHandler(20377)                           	at org.mozilla.gecko.gfx.TouchEventHandler.processEventBlock(TouchEventHandler.java:241)
E GeckoTouchEventHandler(20377)                           	at org.mozilla.gecko.gfx.TouchEventHandler.handleEventListenerAction(TouchEventHandler.java:199)
E GeckoTouchEventHandler(20377)                           	at org.mozilla.gecko.gfx.JavaPanZoomController.notifyDefaultActionPrevented(JavaPanZoomController.java:357)
E GeckoTouchEventHandler(20377)                           	at org.mozilla.gecko.GeckoAppShell$12.run(GeckoAppShell.java:1485)
E GeckoTouchEventHandler(20377)                           	at android.os.Handler.handleCallback(Handler.java:730)
E GeckoTouchEventHandler(20377)                           	at android.os.Handler.dispatchMessage(Handler.java:92)
E GeckoTouchEventHandler(20377)                           	at android.os.Looper.loop(Looper.java:137)
E GeckoTouchEventHandler(20377)                           	at android.app.ActivityThread.main(ActivityThread.java:5419)
E GeckoTouchEventHandler(20377)                           	at java.lang.reflect.Method.invokeNative(Native Method)
E GeckoTouchEventHandler(20377)                           	at java.lang.reflect.Method.invoke(Method.java:525)
E GeckoTouchEventHandler(20377)                           	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1187)
E GeckoTouchEventHandler(20377)                           	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
E GeckoTouchEventHandler(20377)                           	at dalvik.system.NativeStart.main(Native Method)

Comment 7

[Nick Alexander :nalexander [he/him]]

So, here's some WIP that does get the Search Activity to run in a separate process, with a separate profile, using GeckoView.

However, every step is a battle, and we can't build a product and fight these battles simultaneously.  The one that convinced me of this is that connecting a (new) GeckoView to an already running Gecko will require a great amount of effort, 'cuz we don't know how much work *disconnecting* an existing GeckoView from a running Gecko will take.  We have static event listeners and caches all over the place; we have to be careful with our GL contexts, in just the way that Android produces them; etc.

Comment 8

[Nick Alexander :nalexander [he/him]]

(In reply to Nick Alexander :nalexander from comment #7)
> So, here's some WIP that does get the Search Activity to run in a separate
> process, with a separate profile, using GeckoView.
> 
> However, every step is a battle, and we can't build a product and fight
> these battles simultaneously.  The one that convinced me of this is that
> connecting a (new) GeckoView to an already running Gecko will require a
> great amount of effort, 'cuz we don't know how much work *disconnecting* an
> existing GeckoView from a running Gecko will take.  We have static event
> listeners and caches all over the place; we have to be careful with our GL
> contexts, in just the way that Android produces them; etc.

Sorry, the punch-line is that all GeckoView chrome and content delegates pile up and every message gets delivered multiple times.