Vimium Labs (add "experimental" section to options page)

[smblott-github]

How do people feel about the following?

Add a Vimium Labs section to the options page (at the bottom of below-the-fold). This would allow us to try out features in the wild without having to commit to them long term.

Here are some current examples:

• Vomnibar in top/main window (Activate vomnibar in main/top-level window only (WIP) #1537). This feature is a great UX improvement, and I'm not seeing any flaky cases. However, the issues around Vimium enabled/disabled in different frames is concerning, and it's not ready for an all-or-nothing merge.
• Edit mode. Master contains an experimental edit mode, which is disabled currently. It's a cool feature. However, it's also not obvious that we necessarily want to go in this direction at all. It would be helpful to try it in the wild and get some feedback before making any decision.

How would Vimium Labs work?

• Each experiment would by checkbox on the options page, off by default.
• Each experiment would have a link (on the options page) to a github issue where users could provide feedback, raise problems.
• We could withdraw experimental features at any time. We're not promising to support them long term, or even that they work reliably at all.

[leoj3n]

Beats having to checkout PR branches. Seems to work well for gmail.

[mrmr1993]

Yes, this is an awesome idea. An 'experimental commands' checkbox (with commands like LinkHints.activateModeToHover, which you weren't happy was feature complete) would also be nice, and then we can keep adding useful commands while we're trying to work out the help dialog.

[smblott-github]

@leoj3n...

Seems to work well for gmail

Which feature?

[mrmr1993]

Which feature?

I think he meant more that Google's experimental features for GMail work well, not any feature in particular.

[leoj3n]

https://support.google.com/mail/answer/29418?hl=en

[philc]

If it means less branch usage for most users, I think it's a good idea. The drawback is potential technical debt incurred from having branching code paths to accommodate partially-baked features. When we decide "no" on a feature, we need to remember to rip out all code which was just there to support it, which can be hard to do as the code base evolves over time. E.g. imagine new feature A which required a complexity-increasing refactor of the key handler logic. When it comes time to rip out feature A, we may not remember to refactor the key handler logic to restore its simplicity.

In other words, I think this works well for relatively self-contained features. We can POC this approach with the next feature that comes along which fits the bill.

[dragon788]

Per #1307 and mrmr1993's comments about feature toggles, if this isn't already on the radar I would heartily suggest placing it there.

We could certainly do with some kind of 'experimental options' in the options page, to allow enabling more controversial fixes like #1167, #1211, etc. either per-URL or globally. I especially feel like #1167 should be available for those who want it — it fixes a lot of annoyances on a lot of sites — but is perhaps too risky to ship and run everywhere by default.

I don't like the idea of site-specific hacks very much. In some cases they might prove the only option (#1295 specifically springs to mind) though. I suggest a hacks folder, where each hack is a content script, enabled on new URLs by adding them to the matches in manifest.json. It nearly sounds too clean and easy.