a.k.a. "Implement missing WebExtension functionality for the VimFx extension". VimFx is also known as the extension to which Vimperator and Pentadactyl users flee when those extensions break. https://addons.mozilla.org/en-US/firefox/addon/vimfx/ This proposal comes from bug 1215061 - Better keyboard shortcut support ("We'd like to support Vimperator-type functionality."). Start out with this comment if you don't feel like reading that much: https://bugzilla.mozilla.org/show_bug.cgi?id=1215061#c23 WebExtensions basically live and breathe inside the content area of the browser, but there's currently no sane way of getting back to that "world" using the keyboard. Right now, that either requires clicking inside the web page with the mouse, or pressing Tab or F6 a couple of times an hoping for the best. That's why I propose this: > "commands": { > "_focus_content_area": { > "suggested_key": { > "default": "Ctrl+Shift+E" > } > } > } - If the content area is already focused the `_focus_content_area` command is a no-op. - Otherwise, the currently focused UI control is blurred and focus is moved to the content area. This means that you can use the arrow keys to scroll it, press `/` to quick find, and that content scripts can receive 'keydown' events etc. In terms of code, I imagine an implemention would look something like this: > if (chromeWindow.document.activeElement !== gBrowser.selectedBrowser) { > chromeWindow.document.activeElement.blur() > gBrowser.selectedBrowser.focus() > // Might need to close some open panel or so too. > } (`_focus_content_area` is inspired by the two current special commands `_execute_browser_action` and `_execute_page_action`.) (It is not possible to create a keyboard shortcut for returning the foucs to the content area today. See https://bugzilla.mozilla.org/show_bug.cgi?id=1215061#c26 and https://bugzilla.mozilla.org/show_bug.cgi?id=1215061#c28.) --- For reference, these are other critical bugs for VimFx: - Bug 1324255 - Opening a browser action popup does not focus it - Bug 1303384 - UI for re-assigning command shortcuts And a non-critical but really nice to have one: - Bug 1295400 - Need an API to focus on the awesomebar

The comment at https://bugzilla.mozilla.org/show_bug.cgi?id=1215061#c26 makes sense, I guess it's not possible to use document.body.focus() to override a focus on browser UI elements (like the location bar). However, I'm not sure that implementing this new feature as a key command would be the best because it would limit the functionality of focusing content area only to commands. What if there was a new method you could call from a background script like tab.focusContentArea() ? I don't think there is one (unless I'm missing it): https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/Tab

Personally, I wouldn't mind a programmatic way of focusing the content area. But VimFx does not need it. And there is a potential problem: A programmatic way makes it possible for a malicious add-on to make all Firefox UI basically unusable: > window.setInterval(() => { > browser.tabs.update({ > contentAreaFocused: true > }) > }, 100) It might be hard to uninstall such an add-on. The `_foucs_content_area` command does not have this potential problem. Finally, I can't think of any case where you'd want to focus the content area other than as a keyboard shortcut. (Note how I used `browser.tabs.update()` in my above example, rather than `tab.focusContentArea()`. A Tab object currently has no methods. Does any "WebExtension Type" have methods?) --- Just to clarify why VimFx wants to focus the content area: That's the primary place where WebExtensions have the possibility to listen for 'keydown' events, and trigger actions based on them. Having a way to return to the content area allows users not to get "stuck" in for example the location bar or the devtools. Having to use the mouse in these cases is like seeing the boom microphone in a movie, or having a step at the end of a wheel chair ramp. It's the death of a thousand paper cuts. "Escaping" from UI elements is VimFx's use case. If somebody comes up with a better idea than the `_focus_content_area` command, I'm totally up for that as well.

You worry `a malicious add-on to make all Firefox UI basically unusable` is nothing important: If such an extension / add-on is installed, then it has too many methods to break down the browser: ``` javascript window.setInterval(() => { browser.tabs.update({ url: "about:blank" }) // or: // browser.tabs.remove(curId) }, 100) ``` So in fact we have to believe what we decide to install.

Great, nothing to worry about then! Then, to me it doesn’t matter at all if we end up with `_focus_content_area` or some other way to focus the content area. Who needs to decide this?

This has been added to the March 7 WebExtensions triage meeting agenda. Agenda: https://docs.google.com/document/d/1zzfedbTKAHUmm4UctxSOIJV3iKayXQ8TuXPodXW8wC0/edit#

I find my Chrome extension `Vimium++` needs not only `_focus_content_area`, but also `browser.tabs.update({ contentAreaFocused: true })` The extension above is a helper for using keyboard to control the browser, but up to now there's a problem. Here's one use case: * (In the extension, the keydown event of `t` is mapped to `createTab`) * A user press `t` on a normal page * so the extension calls `browser.tabs.create({})` to open a new tab page, like `chrome://newtab` in Chrome, * the only focused area is the addressBar of the new tab, and no suitable WebExtension API to move the focus I think the global command `_focus_content_area` is not enough - users won't want to press two keys just to open a new tab, and a better solution is: ``` browser.tabs.create({}, function() { browser.tabs.update({ contentAreaFocused: true }); }); ``` Anyway, thanks for your previous works.

Is there any update from the meeting? It says that Kris is to comment and that an alternative proposal is requested, but there's evidently no comment. Specifically, what proposals were rejected? Just the original _focus_content_area command one, or the latter contentAreaFocused parameter to browser.tabs.update and tabs.focusContentArea? If the latter two are still on the table, could those be reviewed (after being fleshed out?), and, in the case of a positive result, would a patch be accepted? Sorry if I've need-info-ed the wrong person here, but I'd like to get the process unstuck...

Thanks for following up, bucklereed -- I'm sorry for the delay in circling back. I'm needinfo'ing Kris here to comment.