Support Electrolysis (Firefox) #25

Closed
1ec5 opened this Issue Jan 26, 2014 · 11 comments

Comments

Projects
None yet
1 participant
@1ec5
Owner

1ec5 commented Jan 26, 2014

Update: This bug has been repurposed for Firefox Electrolysis support. Fennec Electrolysis support is now covered by #86.

AVIM supported the very first versions of Fennec (now Firefox Mobile), but then Fennec 4.0 adopted an IPC architecture called Electrolysis that severely restricts access to page content from chrome. Mozilla also tried to move desktop Firefox in that direction at one point.

Although such architectures are generally seen as optimal for extensions like AVIM that primarily interface with page DOM, AVIM relies on anonymous DOM nodes, internal command handlers, and various other features that would never be available to the page context. So simply shoving AVIM into a page script would break most of AVIM’s unique feature set and expose it to conflicts with in-page IMEs like avim.js.

I’m not sure what the solution is, but we’ve continually gotten requests to bring back Firefox Mobile support, because unfortunately people found out about it at about the time Electrolysis landed.

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Aug 17, 2014

Owner

Firefox 34 has support for Electrolysis via the browser.tabs.remote.autostart preference, currently off by default. AVIM seems to work well with Electrolysis on in Firefox. See #58.

Owner

1ec5 commented Aug 17, 2014

Firefox 34 has support for Electrolysis via the browser.tabs.remote.autostart preference, currently off by default. AVIM seems to work well with Electrolysis on in Firefox. See #58.

@1ec5 1ec5 added bug and removed enhancement labels Aug 19, 2014

@1ec5 1ec5 changed the title from Support Electrolysis (Fennec, Firefox Mobile) to Support Electrolysis (Firefox, Fennec) Aug 19, 2014

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Aug 19, 2014

Owner

As of Firefox 34.0a1 (2014-08-17), AVIM doesn’t work in webpages in e10s windows (File | New e10s Window). For some reason, it does work with the browser.tabs.remote.autostart preference set. The plan is apparently to make e10s the default in the near future.

Owner

1ec5 commented Aug 19, 2014

As of Firefox 34.0a1 (2014-08-17), AVIM doesn’t work in webpages in e10s windows (File | New e10s Window). For some reason, it does work with the browser.tabs.remote.autostart preference set. The plan is apparently to make e10s the default in the near future.

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Aug 19, 2014

Owner

We’re capturing an event whose originalTarget is the <browser>.

Owner

1ec5 commented Aug 19, 2014

We’re capturing an event whose originalTarget is the <browser>.

@1ec5 1ec5 self-assigned this Aug 19, 2014

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Aug 19, 2014

Owner

With browser.tabs.remote.autostart set, AVIM actually gets two keypress events per keystroke: one whose target is the <browser> and one with the expected target. It’s possible that “New e10s Window” is a temporary debugging tool and that the preference better reflects the eventual Electrolysis environment.

Owner

1ec5 commented Aug 19, 2014

With browser.tabs.remote.autostart set, AVIM actually gets two keypress events per keystroke: one whose target is the <browser> and one with the expected target. It’s possible that “New e10s Window” is a temporary debugging tool and that the preference better reflects the eventual Electrolysis environment.

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Sep 1, 2014

Owner

AVIM is completely broken in webpages when browser.tabs.remote.autostart is set and <em:multiprocessCompatible> is true in AVIM’s install.rdf. multiprocessCompatible disables the temporary shims that Firefox installs for extensions. It’s likely that the “New e10s Window” command is failing to install these shims. We’ll definitely have to address this situation at some point.

Owner

1ec5 commented Sep 1, 2014

AVIM is completely broken in webpages when browser.tabs.remote.autostart is set and <em:multiprocessCompatible> is true in AVIM’s install.rdf. multiprocessCompatible disables the temporary shims that Firefox installs for extensions. It’s likely that the “New e10s Window” command is failing to install these shims. We’ll definitely have to address this situation at some point.

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Sep 9, 2014

Owner

On the e10s branch, I investigated loading content/avim.js as a frame script from within the window onload event handler in components/avim.js. That kind of works, but the transformer service can’t be found for some reason.

On another track, nsIEventListenerService.addSystemEventListener() sounds like a more elegant way of having AVIM hook into all keypresses across the application, and there will be a shim like the one for addEventListener().

Owner

1ec5 commented Sep 9, 2014

On the e10s branch, I investigated loading content/avim.js as a frame script from within the window onload event handler in components/avim.js. That kind of works, but the transformer service can’t be found for some reason.

On another track, nsIEventListenerService.addSystemEventListener() sounds like a more elegant way of having AVIM hook into all keypresses across the application, and there will be a shim like the one for addEventListener().

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Sep 13, 2014

Owner

Well great: the new e10s preference puts Firefox into the same mode as the “New e10s Window” option rather than just browser.tabs.remote.autostart, so the shims don’t seem to apply.

Also, frame scripts apparently can’t see the transformer service because components are only loaded in the main process.

Owner

1ec5 commented Sep 13, 2014

Well great: the new e10s preference puts Firefox into the same mode as the “New e10s Window” option rather than just browser.tabs.remote.autostart, so the shims don’t seem to apply.

Also, frame scripts apparently can’t see the transformer service because components are only loaded in the main process.

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Sep 13, 2014

Owner

According to bug 596880, we need to “manually register the component (nsIComponentRegistrar) using message-manager scripts”.

Owner

1ec5 commented Sep 13, 2014

According to bug 596880, we need to “manually register the component (nsIComponentRegistrar) using message-manager scripts”.

1ec5 added a commit that referenced this issue Sep 14, 2014

1ec5 added a commit that referenced this issue Sep 14, 2014

Rudiments of e10s support
Slapped together some code to handle key presses in <input> fields in Electrolysis windows. No support for rich text, custom editors, ignored IDs, or the script monitor.

Ref #25.
@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Sep 14, 2014

Owner
  • Move all input editing code (except applyKey()) from avim.js to frame.js
  • In frame.js, applyKey() either calls sendSyncMessage() when available or a method on window.avim directly.
  • Notify frame.js of preference changes
  • Embed frame.js into avim.xul and load it into child processes from avim.js
  • Fix up editor subscripts
  • Check compatibility with older Firefoxes.
Owner

1ec5 commented Sep 14, 2014

  • Move all input editing code (except applyKey()) from avim.js to frame.js
  • In frame.js, applyKey() either calls sendSyncMessage() when available or a method on window.avim directly.
  • Notify frame.js of preference changes
  • Embed frame.js into avim.xul and load it into child processes from avim.js
  • Fix up editor subscripts
  • Check compatibility with older Firefoxes.

1ec5 added a commit that referenced this issue Sep 17, 2014

Lazily load Kix support
Unlike the editor subscripts, this subscript is privileged since it doesn’t interact with untrusted content directly.

Ref #25, ref #78.

1ec5 added a commit that referenced this issue Sep 17, 2014

1ec5 added a commit that referenced this issue Sep 20, 2014

1ec5 added a commit that referenced this issue Sep 20, 2014

Rudiments of e10s support
Slapped together some code to handle key presses in <input> fields in Electrolysis windows. No support for rich text, custom editors, ignored IDs, or the script monitor.

Ref #25.

1ec5 added a commit that referenced this issue Sep 20, 2014

Moved input editing code to frame script
Also include frame script in overlay so you can still type in chrome controls. Preferences observed only by overlay script, which then notifies frame scripts of any changes.

Ref #25.

@1ec5 1ec5 changed the title from Support Electrolysis (Firefox, Fennec) to Support Electrolysis (Firefox) Sep 20, 2014

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Sep 20, 2014

Owner

I’m getting pretty far on Firefox e10s support, but Fennec’s e10s is sufficiently different that I’m going to split it out into another bug.

Owner

1ec5 commented Sep 20, 2014

I’m getting pretty far on Firefox e10s support, but Fennec’s e10s is sufficiently different that I’m going to split it out into another bug.

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Sep 21, 2014

Owner

Fixed in 738fafb.

Owner

1ec5 commented Sep 21, 2014

Fixed in 738fafb.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment