Tabs module doesn't work in Firefox 51 (not e10s)

[ghost]

Issue type:

• Version compatibility

Version:

Vimperator 3.15, Nightly 51.0a2, e10s disabled.

Description:

Mappings and commandline don't work.
In browser console it's showing that ReferenceError: tabs is not defined
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Not_defined

[bpseudopod]

I think I found the problem. See #211. Developer Edition has e10s enabled by default, so that'd explain why it's broken. Looks like e10s support ought to get moved up the priority list.

[gkatsev]

Going to close as a duplicate of #211 then. e10s is at the top but there's not a lot of people who know a lot about e10s and also have time to work on it unfortunately :(

[ghost]

@tinkerttoy @gkatsev it's not e10s issue, it's not working with e10s disabled, i pointed that out in issue.

[gkatsev]

Oh, I see. Sorry, re-opening.

[deathbeam]

Same problem here, most of stuff is working, except everything related to tabs and preference pane.

[RomanHargrave]

Same, as above.

List of things that are working here, at least that I have noticed:

• Open in focused tab (:open)
• winclose, winopen, winonly, and window

Everything else probably is too.

List of things not working

• All commands named like tab* are not even present

Version: vimperator-3.15.0-11-gb9c1f0d

[teranex]

I updated to Firefox 51 beta yesterday and Vimperator (particularly :tabopen) is broken.

:version
Vimperator: 3.15.0 (created: 2016/10/05 01:11:26)
Firefox: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0

[xTpx]

Same problem on Fx 51 Beta ("Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0").
f/r & c-n/p, shift-h/l not work, e10s is disable.
The console show
liberator: Error loading script tabs.js: SyntaxError: non-generator method definitions may not contain yield load @chrome://liberator/content/liberator-overlay.js:17:17 @chrome://liberator/content/liberator-overlay.js:66:5 @chrome://liberator/content/liberator-overlay.js:6:2

[timss]

Protip: use the ESR instead of betas or bleeding edge releases, for better compatability..

[SammysHP]

@timss Which does not work when using own builds of Vimperator (e.g. development / custom modifications) if you don't want to send every build to Mozilla for signing (which works automatically with my makefile modification, but takes a 10-60 seconds longer).

[nornagest]

I have just noticed this problem too, after upgrading Firefox.
Release date for Firefox 51 is 2017-01-24 - only two days away.

Vimperator: 3.15.0 (created: 2016/10/05 01:11:26)
Firefox: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0

[Nefari0uss]

@timss I don't think telling people to switch to ESR is the best way of going about the E10s issue. All it does is kick it down the road.

[timss]

@Nefari0uss It most certainly is not, but it's one currently viable, working option. Although at this point not for long, as the next ESR release Firefox 52 is set to release March 2017:

• https://www.mozilla.org/en-US/firefox/organizations/faq/
• https://wiki.mozilla.org/RapidRelease/Calendar

As far as e10s or WebExtensions development goes, the status unfortunately hasn't changed too much since I wrote this back in September. I don't personally have the time to change much about that. Some PRs come in from time to time (thanks!), and a couple recently got merged by @maxauthority. But the e10s/WE issue still stands.

• Add support for e10s (electrolysis) #211 (comment)

[sandermarechal]

Firefox 51 was released today, breaking Vimperator as described. Any update on a fix?

[SammysHP]

Firefox 51 is not in the Arch repository yet, so I cannot test. This might fix it, but there are also a lot of other generator functions without function*. I tried to fix all but then vimperator didn't work at all.

diff --git a/common/content/tabs.js b/common/content/tabs.js
index 8410e325..89948885 100644
--- a/common/content/tabs.js
+++ b/common/content/tabs.js
@@ -52,7 +52,7 @@ const Tabs = Module("tabs", {
      * @property {Iterator(Object)} A genenerator that returns all browsers
      *     in the current window.
      */
-    get browsers() {
+    browsers: function* () {
         let browsers = config.tabbrowser.browsers;
         for (let i = 0; i < browsers.length; i++)
             yield [i, browsers[i]];

See also: https://developer.mozilla.org/docs/Web/JavaScript/New_in_JavaScript/Firefox_JavaScript_changelog#Firefox_51

[ma8ma]

@SammysHP Looks good to me. The patch makes to work the tab operations on Firefox Developer Edition 52.0a2 😄

[dcrozz]

It seems that though I replace the xpi for FirefoxDeveloperEdition by following the steps listed by @DarkPrinceFrost , the vimperator works for a minute but so many error messages pop-up such as TypeError: 'stopPropagation' called on an object that does not implement interface Event. or TypeError: m.getClientRects is not a function. from time to time, and the hotkey I set such as map H <C-p> doesn't work accidentally.
The system I use is osx 10.11.6, Firefox 51.0.1 (64-bit).
Maybe I should give up and wait for the next vimperator version?

[mwelt]

@chocolateboy Somehow your instructions yield

Any suggestions, what I might do wrong here?

[timss]

• Fix #568: loading the tabs module failed #675 (comment)
• tabopen not working, link numbers not showing up #674 (comment)

[chelmuth]

Great to see this issue fixed. Is there already a plan when it will be available from https://addons.mozilla.org/en-US/firefox/addon/vimperator/?

[boreq]

I think it is a bit weird that you decided to sit on the information that Vimperator is broken in the new stable release of Firefox and did nothing. As far as I can see that information was available for months and yet nothing was done about it untill today (okay, a commit was made but that doesn't mean much without the new Vimperator release). I find this a bit unprofessional for an addon with 30000 users. And as it is the major bug is still present after several days, which frankly I find quite annoying. I think some kind of a change to your relase process would be a good idea.

[SammysHP]

"30000 users vs 0 developers" should explain it. But thanks that you want help us in the future. I look forward to see some nice commits fixing some of the issues. :)

[chelmuth]

Isn't vimperator an admittedly successful, widely-adopted open-source project backed by diligent volunteers? I don't think it's fair to apply professional (whatever that means) standards in this case. It would be fair if anybody who's annoyed by a shortcoming would get started fixing the bug and contribute to the project. I myself did not pay anything for an addon that makes Firefox usable for years now and so I'm pretty glad it is still maintained while others just vanished. Thanks devs for your hard work!

[rwestlund]

+1. You don't get to complain about things you get for free. I think it's pretty awesome that vimperator works 99.99% of the time, and all I had to do was click install :)

[timss]

Much like @chelmuth said, "unprofessional" is exactly what Vimperator and most other Firefox addons are. The work done by previous and current contributors is done in our spare time, for free. It should go without saying, but such entitlement is not only misplaced, but also an annoyance in the open source community that contributors and maintainers should be spared.

[ghost]

I'm in the situation that I simply don't have the time to contribute to vimperator myself, I'd imagine others are in the same situation. I'm willing to do what I can: give money to help with development (in a way that vimperator stays open source, rather than become paid software). The epub-reader addon is in a similiar situation as vimperator: it needs a rewrite w.r.t. to the changes planned by Mozilla. The dev behind it started a kickstarter project[1] so he can work full time on doing said rewrite. Might this be an option for vimperator? Kickstart money to either hire a dev or enable an existing dev to spend time on a rewrite?

[1] https://www.kickstarter.com/projects/569473473/epubreader-for-future-firefox

[vlcinsky]

This shows, some things are not only technical, but also require some managerial effort.

Some people like coding, others are able to manage all the stuff around funding. I can understand, some great coders hate any organizational stuff.

It would be great to have vimperator functional in future - with Mozilla planned switch. Demand is very strong (vimperator is in muscles of many very productive people) and I am sure the chance for enough funds is very high.

My proposal is:

• is main developer willing to organize the funding?
• if not, is there anybody, who would be willing to help him with that? If so, can they agree on setting up the campaign together?

PS: Personally, I have no experience with such project, so I cannot serve myself. Just wanted to propose possible path of development (and yes, count with my 50 USD contribution if it ever starts - it was already worth 2x10 USD in past).

[wmorrell]

What main developer? There currently are none. It's a project that was open-sourced a long time ago, and a few enthusiasts here and there continue to volunteer time to maintain it. It's nobody's day-job. If you feel like donating, there are PayPal and Flattr buttons on the vimperator.org website. Please do not encourage setting up alternate funding, that will only draw donations away and potentially direct the funding to scammers or less scrupulous individuals.

The current maintainers have repeatedly said, funding is not the issue. Work submitting patches, or re-implementing as WebExtensions instead of XUL, is needed. Experience is not required; you get the experience by doing things you have not done before. If you have the time, great! Lots of people will appreciate your effort. But please, if you do not have the time, refrain from complaining about the efforts of the existing volunteers.

[vlcinsky]

@wmorrell Did I complain about the efforts of the existing volunteers? I did not intend to as I appreciate the effort really a lot.

"Money are not the problem", many users using vimperator, growing technical debt due to lack of programmers: this is not fault of existing volunteers at all. To me it is a sign of lack of structure in processes and organization as energy (money, demand) exist but do not flow well enough where required. Trying to think forward I feel, there is a need for a lead (or two), who could help the great solution to evolve.

I did not want to offend anyone. I just tried to contribute to a solution, I love so much (btw: is there some better place to discuss such things?).

My fingers are tapping the thanksgiving song many times a day: Vimperator is my daily tool with that my browsing can fly at speed of thought, thanks all the contributors and I wish all of us: Live long and prosper, dear Vimperator.

[wmorrell]

@vlcinsky The more egregious complaining is further up-thread. Your comments are not of the same degree or severity, and I appreciate and believe that you are not intending to complain. It is just not helpful to comment along the lines of, "why is there no-one doing X?" especially if it's immediately followed by, "I won't do it." That reads as entitlement to the time and effort of the existing volunteers working on what you want.

I intend to make a weekend afternoon project to learn more about WebExtensions APIs. It won't get Vimperator ready for the final deprecation of XUL in Firefox 57, but it is a step in the right direction.

[blueyed]

I think we should lock this issue, and rather create a new one for discussions.

From my point of view a lot of people (and especially developers) are using OSS, but do not contribute back: if you find an issue, please consider digging into the source! That's not easy for all projects (e.g. Vimperator), but you should be able to create a local build, find the place to hack and then investigate. And if you stumble while doing so, please at least create a PR for better docs while you find out something.

(I am maintaining some Vim plugins, and it is really discouraging if e.g. Python developers using jedi-vim are creating duplicate issues, instead of figuring out what is wrong, and then submit a small PR to fix it (although the problem is in the Python code))

Therefore it's not really money that's the issue, but rather to make development/hacking easy (docs!), and that users (especially developers) are willing to contribute back.

[timss]

Good idea, @blueyed. We don't want to end up in nikolas/github-drama! :p

There are some valid points that are brought up here, but should be done in a constructive manner in a seperate issue. I have some ideas how that could be done, so sit tight until I've made such an issue. In addition, lets all recognize that we want the same thing, and try to avoid fruitless discussion(s).

[gkatsev]

Vimperator 3.16.0 has been officially approved. They did note two things that need to be looked at for an upcoming release. I'll open a new issue for those.

[gkatsev]

Also, thanks to everyone who made this release possible!