Closed
Bug 1038012
Opened 10 years ago
Closed 10 years ago
Run Search Activity's GeckoView in separate process and separate profile
Categories
(Firefox for Android Graveyard :: Search Activity, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: nalexander, Unassigned)
References
Details
Attachments
(6 files)
1.23 KB,
patch
|
Details | Diff | Splinter Review | |
2.31 KB,
patch
|
Details | Diff | Splinter Review | |
1.21 KB,
patch
|
Details | Diff | Splinter Review | |
14.31 KB,
patch
|
Details | Diff | Splinter Review | |
4.90 KB,
patch
|
Details | Diff | Splinter Review | |
3.38 KB,
patch
|
Details | Diff | Splinter Review |
It needs to be done in order to continue using GeckoView for the Search Activity.
Reporter | ||
Comment 1•10 years ago
|
||
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.
Reporter | ||
Comment 2•10 years ago
|
||
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.
Reporter | ||
Comment 3•10 years ago
|
||
Reporter | ||
Comment 4•10 years ago
|
||
Reporter | ||
Comment 5•10 years ago
|
||
Reporter | ||
Comment 6•10 years ago
|
||
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)
Reporter | ||
Comment 7•10 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 8•10 years ago
|
||
(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.
Updated•6 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•