Open cxw42 opened 6 years ago
Requested by Ismo Räävi via support request 2018/04/15
Hey @cxw42 what's the status on FF support?
Looks like the steps in "Hacking on TabFern" for the switchover branch might now be right... not sure... Shouldn't a dev change to switchover branch? And branch off of switchover? https://github.com/cxw42/TabFern/wiki/Hacking-on-TabFern
Last but not least, I'm not sure how to use the built extension in firefox!
@devinrhode2 Unfortunately, I haven't had a chance to work on it. It does load as a temporary add-on without crashing, but I wouldn't consider it particularly usable :) . I would be delighted to have some help! Yes, if you do have any time, I would ask that you please work off switchover
if you are able. I am currently focused on #35 and would be delighted to include FF support in the next release as well!
Using the built extension: See Loading temporary add-ons in Firefox. Pick public/manifest.json
as the thing to load. See the top comment (https://github.com/cxw42/TabFern/issues/100#issue-282712399) for open concerns I am aware of. Thank you!
I tried loading this, I have the extension icon in the top right in FF, but clicking it doesn't do anything :(
(So I guess that's what the status on FF is :)
Yep, those are normal (broadly defined :D). Did you see the extension window pop up on its own? Try double-clicking the icon and see if you get the window (double-click = summon to current browser window).
When I load the temporary extension, I get the same manifest errors, but the TF window opens anyway.
Double clicking the icon still does not do anything for me, also tried disabling all extensions except for stylus, restarting, and still nothing for single/double click.
I am using FF 64.0 64-bit, on macOS High Sierra.
When I first load the extension in about:debugging, I see this:
[image: Screen Shot 2018-12-26 at 1.16.38 PM.png]
When I reload I see this:
[image: Screen Shot 2018-12-26 at 12.54.22 PM.png] The last commit in my working directory (from you) - on the switchover branch, is: commit 2deb0684eb30d4f1d230d8fa79df04f073d3d5ed (HEAD -> firefox-work, origin/switchover, origin/firefox-work, switchover) Author: Chris White cxwembedded@gmail.com Date: Tue Dec 18 22:01:13 2018 -0500
Remove S.COLLAPSE_ON_PARTIAL_WIN_CLOSE
Don't use the option I started adding in
25752b33290885b25a83bf84ef0b097fee176aea. It would require winOnRemoved
to receive state information about why the window was closed, and I
don't think this feature is sufficiently valuable to take the memory and complexity hit. Let me know if you disagree!
Also, improve the ergonomics of "collapse on window close". If you hit
Close on an already-closed window, collapse it.
Mentioned in #35.
-Devin http://devinrhode2.github.io http://devinrhode2.github.io/
On Wed, Dec 26, 2018 at 12:05 PM Chris White notifications@github.com wrote:
Yep, those are normal (broadly defined :D). Did you see the extension window pop up on its own? Try double-clicking the icon and see if you get the window (double-click = summon to current browser window).
When I load the temporary extension, I get the same manifest errors, but the TF window opens anyway.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cxw42/TabFern/issues/100#issuecomment-450002438, or mute the thread https://github.com/notifications/unsubscribe-auth/AAg8qHXDaOOEdTVMMpWRy1aFkTdGB4F4ks5u87pXgaJpZM4REvjJ .
@devinrhode2 Unfortunately, the screenshots did not come through. However, I added a fix for the manifest issues, in case that helps. Instead of npx brunch ...
, say npm run ff
. That will build a public-ff
tree. Load public-ff/manifest.json
in Firefox and see if that helps any. Thanks!
Original should come through now:
When I first load the extension in about:debugging, I see this:
When I reload I see this:
After pulling that from switchover I see: First load:
Reload:
Thanks! The screenshots did come through. I am on Windows, which is why I think I might be having trouble replicating. I did try a fresh npm install
with all my global modules uninstalled, still without successfully replicating. I can think of three next steps to try:
If you have brunch
installed globally, remove it --- I am using a tweaked version.
(See https://developer.mozilla.org/en-US/docs/Tools/Working_with_iframes if you're not familiar with this.) In the developer console, select the middle iframe (win/main.html
). Then say log.setLevel(log.levels.INFO)
. That may provide more debug information.
Would you please send me a copy of your generated public-ff/bg/background.js
? I'd like to see if there are any differences.
Thank you for working with me on this!
log.setLevel
throws a ReferenceError on log
Some screenshots coming up..
Showed inspecting the location.href of the extension background page, and contrasted with mashable.com - in top right there's a strange little windowing type of button that's for selecting the frame. Not available for the background page. I am surprised that the background page uses iframes though... why is that? I figure the thing to do will be to set the sub-frames to have hijacked console methods that use YourWIndow.sendMessage
to log console messages from top frame (only in FF) - or, maybe, we could eliminate usage of iframes.
Oh - my fault. The background doesn't have any iframes. That's the main window, so remember the iframe + log
for once we get the window to open :D . Sorry for the confusion!
process
OK - you are indeed getting some code I am not!
$ diff -U3 public-ff/bg/background.js background-devin.js
--- public-ff/bg/background.js 2018-12-26 20:01:04.363629700 -0500
+++ background-devin.js 2018-12-26 21:16:51.100429200 -0500
@@ -355,6 +355,7 @@
;
(function() {
var global = typeof window === 'undefined' ? this : window;
+var process;
var __makeRelativeRequire = function(require, mappings, pref) {
var none = {};
var tryReq = function(name, pref) {
@@ -893,7 +894,8 @@
});
-;require.alias("path-browserify", "path");require.register("___globals___", function(exports, require, module) {
+;require.alias("path-browserify", "path");
+require.alias("process/browser.js", "process");process = require('process');require.register("___globals___", function(exports, require, module) {
});})();require('___globals___');
Seems to be the same symptoms as brunch/brunch#1503.
I added the suggested fix from https://github.com/brunch/brunch/issues/1503#issuecomment-320902509 - would you please try the latest commit when you get a chance and let me know if it works?
wow removing those added bits got the extension to just popup when I reloaded the background page!
Great news! Now is the time for log.setLevel
.
Would you please start a new topic branch from this point for Firefox? I'm going to do the same for issue 35. That way we won't step on each other's toes, and the eventual PRs will be cleaner.
If you find anything I haven't listed above, feel free to ping me here or open a separate issue as you see fit.
I am going to update the wiki with some more development info in the next few days. Re. the event-order issue, for example, every tab has to be represented in both the multidex and the jstree. The jstree had a holding-pen node where we can hang the tree node for a new tab before its window arrives.
@devinrhode2 Is this a success report or a failure report? :D
h0-main.js
is, or what those errors are. Would it be possible to export tabs from TabFern Chrome and import in TabFern Firefox?
The h0-main.js errors were from other extensions
It's a success report
Re. save data - yes - should be no problem. The save-data file is just JSON.
Ideally, there should be no difference in functionality between Chrome and FF when we're done. I certainly have not intentionally added any differences.
Ok so I haven't switched over yet, figured out I can port active tabs by just bookmarking all tabs, but when I restarted firefox, I had some sort of "browser crashed, do you want to restore session?" from firefox, and saw this:
TabFern is not actually installed, since I'm just loading it from the directory, so probably there's some issue with Tab Center Redux
Indeed, it may well be an interaction bug. Not sure why the crash would have happened, though. I just found this which looks like it has useful info (most notably, switch to Developer Edition and set xpinstall.signatures.required to false) - I'll try it myself when I get the chance.
Edited
OK - I tried web-ext
without success. However, what did work for me (with commit https://github.com/cxw42/TabFern/commit/72ffa2f83f237deee4fae8c22f0f3b84cc85f6a8 on switchover
) is:
about:debugging
At one point, something messed up the permissions on public-ff
. However, exiting Dev Edition, removing the dir, and recreating seems to have worked fine.
Make sure you have c764b39a5d7b76aa50fbdbb03a13e6be7098b67d or later
Say npx brunch w --env firefox
instead of npm run ff
(although the latter will still work).
bash
alternative: BRUNCH_ENV=firefox npx brunch w
cmd
alternative:
set BRUNCH_ENV=firefox npx brunch w
Start up FF Dev Edition, hit "Load temporary," and pick the manifest from public-ff
.
When you make changes, brunch w
will automatically rebuild the public-ff
tree :tada: .
Hit Ctrl+F5 in the TabFern window and the rebuilt public-ff/win
will be loaded from disk. (Ditto for the Settings window.)
If you change the manifest or background, you will need to go to about:debugging
and click "Reload" to see the changes.
Hi, I'm reporting success with v0.2.0.1340 release and FF 66.0.3 The css is kinda weird, but as far as I've tested, it's working...
Thanks god you did it !
I'd love to tip you, but didn't find anything for that on TabFern webpage...
@samir-s Thank you! I'll get right on that :D .
Please back up frequently! I don't know what differences between Chrome and Firefox may be lying in wait to cause issues. I look forward to any feedback you may have.
@devinrhode2 re. "cannot find module process from /" --- I now have an Ubuntu 18.04 setup and am seeing the same. For now I am going to do the manual hack you suggested (removing the lines) :) . If I think of anything better I'll let you know.
Specifically (for the benefit of future readers), after running npx brunch b
, I edited public/bg/background.js
as follows:
require.alias("process/browser.js", "process");process = require('process');require.register("___globals___", function(exports, require, module) {
was changed to:
//require.alias("process/browser.js", "process");process = require('process');
require.register("___globals___", function(exports, require, module) {
(added //
and line break).
My Brunch is somewhat customized, which may be causing an issue. I'll look into it in due course.
@devinrhode2 Would you please join me at #179? Thanks!
I assume you already know https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/Porting_a_Google_Chrome_extension
@rugk Yes, indeed, but thanks for checking! Do you happen to have any bandwidth to help out? :D
The differences TF runs into are largely undocumented assumptions. E.g., in Chrome, a window always has at least one tab, but that's not the case in Vivaldi. In Firefox, the extension can't manipulate any about:debugging
tab, unlike in Chrome.
I may have a look. Though seeing that it has already worked and I don't exactly know what is still TODO here. I see these tick boxes in the OP, but do all of them need to be solved?
@rugk Thanks for considering! Yes, all of the check boxes at the top are things that need to be fixed before the general public can use TF on FF. There may be others that will show up once those are done.
Sometime in the next few days I am going to make what is now the issue35
branch the mainline, so that's the branch to look at if you're investigating. The license will be clarified to CC-BY-SA 3.0+ in the near future, unless any of the existing contributors object.
CC licenses should not really be used for software. (they are intended for everything else) Rather use something like GPL instead then. Also this trademark claim in the license file is a little strange. Did you really register a trademark?
@rugk That discussion is at #145
Just a note for anyone wondering how functional this extension currently is: I tested it for 5 minutes and frankly if Tree Style Tab interop was implemented I would use it as-is. The only bugs I've seen are two from the OP. Specifically:
about:debugging
etc bug: you can save a window that contains an about
page tab, but trying to re-open such windows throws an error. You can just remove that tab from the saved window though.I installed the extension as @cxw42 recommended earlier (downloading the "webstore" zip from TabFern's releases):
Using the built extension: See Loading temporary add-ons in Firefox. Pick
public/manifest.json
as the thing to load.
@cxw42 I skimmed this issue and https://github.com/cxw42/TabFern/issues/179. Given that the extension seemed to work for me (I'm on macOS), should Cannot find "process" from "/"
be checked off in the OP of this issue? Or does that bug only show up if you try to build from source, or something?
(Not sure what the "openWindowForURL" checkbox/issue in the OP refers to.)
@7vq Thanks very much for trying it out, and for the update! Glad to hear the good news --- I haven't run it on FF in a while.
What version of Firefox did you use, and what version+CPU of macOS?
Re. #179, building from source produces exactly what goes in the ZIP file. Therefore, I think that box can be checked! :tada:
@7vq
Tree Style Tab interop
Would you please open a new issue for that? I'm curious to hear more about what you're looking for.
Thanks very much for trying it out, and for the update!
Of course. Thanks for making it!
What version of Firefox did you use, and what version+CPU of macOS?
Firefox 96.0.1, Big Sur, Intel
Tree Style Tab interop
Would you please open a new issue for that?
Definitely! Here: https://github.com/cxw42/TabFern/issues/286
Mentioned in #82 and #99.
Firefox does support the
chrome.*
API (at least at present), so we don't need to switch tobrowser.*
.Known issues
[ ] When creating a new window in FF 64, the tab-created and tab-activated messages arrive before the window-created message (!). Therefore, we need to cache new tabs in the multidex without windows somehow, and flush them out if the window never arrives. I think we can probably stick them in the holding pen. Log:
Object { "Tab created": 14, ctab: {…} } main_tl.js:2549 Unknown window ID 72 - ignoring main_tl.js:2554 Object { "Tab activated": 14, activeinfo: {…} } main_tl.js:2762 Object { "Window created": 72, "Restore?": "no", cwin: {…} } main_tl.js:2134 Object { "Tab updated": 14, Index: 0, changeinfo: {…}, ctab: {…} } main_tl.js:2633
[ ] Figure out how to handle
about:debugging
,about:config
, and any other URLs that extensions aren't allowed to create (see 5e521435f7cddc4bf3365334783fcd5e5779499e). (Are there any other such URLs? May need to grep the FF source.)[x] (Hack added in fdecec30662356c7926b6c363ef63b2815c42172) Update the build pipeline to produce separate Chrome and FF versions. At present, all I know of is that we need to use a different manifest for each browser (see https://github.com/cxw42/TabFern/issues/100#issuecomment-449998383).
[x]
Cannot find "process" from "/"
error on load on macOS (edit currently the workaround has to be applied by hand. At least automate that, if nothing else. But first update the customized Brunch based on upstream.)[ ] app/win/const.js:openWindowForURL(): On FF:
window.create
call makes a new tab instead of a new windowtabs.get
call, the URL for the settings window is stillabout:blank
. Looks like we need to wait until the tab-load state gets tocomplete
before testing theurl
.