Allow reading and writing bookmark tags

NEW
Assigned to

Status

()

Toolkit
WebExtensions: General
P3
normal
a year ago
14 days ago

People

(Reporter: wbamberg, Assigned: ntim, Mentored)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bookmarks][design-decision-approved] triaged)

(Reporter)

Description

a year ago
The Chrome bookmarks API[1] doesn't let you query by tags. The Add-on SDK bookmarks API does[2]. It would be nice if the WebExtensions API did, too.

[1] https://developer.chrome.com/extensions/bookmarks#method-search
[2] https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/places_bookmarks#search%28queries_options%29
I'm tracking implementation of the search functionality in Bug 1225743. I can see if it's viable to get tag support implemented in that bug or leave this open as a separate bug. So I'd put this on blocked until 1225743 is landed. :)
Depends on: 1225743

Comment 2

a year ago
+1 about searching by tag! It's the one thing that makes Firefox bookmarks superior than Chrome's ones. Please please please don't drop this feature.
so the chrome.bookmarks.search that has just landed does not support searching by tag, but I'm pretty sure it can be amended to support this in the future
Mentor: kmaglione+bmo@mozilla.com
Whiteboard: [bookmarks][berlin]
Whiteboard: [bookmarks][berlin] → [bookmarks][berlin][good first bug]

Comment 4

a year ago
Hi,

If this bug is still open, I would like to work on this bug.
This would be my first bug for mozilla.

I can see that bug 1225743 is verified and fixed so I hope this bug is ready to get implemented.

Please help me to get started.
Flags: needinfo?(kmaglione+bmo)
Hi Vikram, thanks for contributing!

This bug is quite ambitious for a good first bug, I don't think it should be tagged as one, sorry. However, we can still try to get it solved. There are two ways I can come up how to do this:

Either we use the tagging service (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsITaggingService) to get a list of all urls for the tags in https://dxr.mozilla.org/mozilla-central/source/browser/components/extensions/ext-bookmarks.js#115 and do a search for all those URLS.

Or we change the query implementation in https://dxr.mozilla.org/mozilla-central/source/toolkit/components/places/Bookmarks.jsm#913 to also look in the tag folder and get the corresponding bookmarks as well. That sounds like some pretty complicated SQL query, though. (See https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Database).

Marco, maybe you have an opinion on what's the best thing to do here? :)
Mentor: jhofmann@mozilla.com
Flags: needinfo?(mak77)
Whiteboard: [bookmarks][berlin][good first bug] → [bookmarks]
Also, if this sounds intimidating then I suggest Bug 1265317 which should be much easier to solve :)

Comment 7

a year ago
Thanks Johann for pointers, I have started working on Bug 1265317.

Truly, this bug will be challenging for me but this will be a good learning. I would like to work on this and take it to completion. 

I want to visualize this issue. Could you help me to see functionally the meaning of 'Bookmark API should allow searching by tag', because I am able to search bookmark by tag in my firefox bookmark sidebar.

Trying to fill gaps.
Flags: needinfo?(jhofmann)
(In reply to Johann Hofmann [:johannh] from comment #5)
> Or we change the query implementation in
> https://dxr.mozilla.org/mozilla-central/source/toolkit/components/places/
> Bookmarks.jsm#913 to also look in the tag folder and get the corresponding
> bookmarks as well. That sounds like some pretty complicated SQL query,
> though. (See
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Database).

AUTOCOMPLETE_MATCH can match on tags, if you pass the tags list as the 4th param (IIRC). And you-re already using that...

The problem is how you want this API to look like... There is a problem I see here.
Tags currently are bound to bookmarks, but that's not really mandatory, through the tagging API one could just tag an unbookmarked url. So tags could also be seen as an alternative to bookmarking...
We have never specified a "correct" behavior here, cause tags have always been an half-done feature that lost traction along the way, everyone excited at the beginning, then no one cared anymore.

So, if there would be some sort of specification around those, first of all it should define whether we tag urls or bookmarks. And based on that the API will look very different, and it will bound tags to a certain behavior "forever".

As things stand now, I'd not bound a specification around something we never settled down.
Flags: needinfo?(mak77)
> As things stand now, I'd not bound a specification around something we never
> settled down.

How formal a specification are you hoping for and who are the people to help figure that out?

Updated

a year ago
Whiteboard: [bookmarks] → [bookmarks][design-decision-needed]
Not extremely formal, just some consensus across people responsible for webextension API across browsers, maybe we could figure if any other browsers is interested in tagging support, and what are their ideas.
Otherwise, we could just take our own decisions, after some discussions around pros and cons.
But I can't exclude tags could end up on the "wrong" side of a great or dead decision.
(In reply to Marco Bonardo [::mak] from comment #10)
> Not extremely formal, just some consensus across people responsible for
> webextension API across browsers, maybe we could figure if any other
> browsers is interested in tagging support, and what are their ideas.
> Otherwise, we could just take our own decisions, after some discussions
> around pros and cons.
> But I can't exclude tags could end up on the "wrong" side of a great or dead
> decision.

It seems that the bookmarks API is not a part of the new working group for now. But I agree 100%, we should rather leave this stalled than shoehorn some solution that will not conform to future ideas but we would have to support in the future.

My idea was to include tags in the part that gets queried through the "query" parameter and add a new "tag" field to the search options, like "url" and "title".

I think removing these if tags gets killed would not badly break any extension except those that fundamentally rely on tags for some reason. One way to make sure that doesn't happen is to not offer the possibility to create tags via the WebExtension API.

> Truly, this bug will be challenging for me but this will be a good learning. I would like to work on this and take it to completion. 

If there is some consensus on what the API should look like you're welcome to try! But since we're just figuring it out for now I'd recommend not taking this bug.
Flags: needinfo?(jhofmann)

Comment 12

a year ago
Hi Marco,

(In reply to Marco Bonardo [::mak] from comment #8)
> Tags currently are bound to bookmarks, but that's not really mandatory,
> through the tagging API one could just tag an unbookmarked url. So tags
> could also be seen as an alternative to bookmarking...
> We have never specified a "correct" behavior here, cause tags have always
> been an half-done feature that lost traction along the way, everyone excited
> at the beginning, then no one cared anymore.

This is probably not the right place to talk about it, but I just wanted to say my opinion.

Organize bookmarks with folders has never worked for me, as the URL content can be related to two different concepts, say A and B.
If you place the link in the A folder, when you'll be searching for that link you might associate it with the concept B and not A, because if you're current focus is (related to) B you tend to remember the B association more easily than the A association.
The result is that you try to search by keywords in the Awesome Bar, hoping the ones you can remember are in the URL.
If they're not, you're forced to rely on a search engine to find a link you already have in your machine, which is not logical (read: absurd).

On the other hand, if you're able to create those two relationships A <- link -> B, you'll have a more flexible mechanism to find things again.
Tagging a URL is also way faster because, instead of searching for a folder nested inside many others, you just press the shortcut to bookmark and fill the tags fields in, takes a second or two.
After I switched to tags I almost never missed a bookmark, meaning I'm less dependent on a search engine to find things I need.

Also, using a search engine to find a link you already have is good for the search engine business model, not for yours, and quite importantly it's not "green" at all as your searches keep pumping heat out of their CPUs: we keep doing them over and over, and we're millions doing that. 
After all Chrome is a Google product, which has little interest in letting you find things by yourself :/

So, why leave this super important feature behind and unfinished?

Is there a public place where you guys discuss these APIs?

Thanks!
You're right, this is not the right place. Quickly, the main reason is that we don't have infinite resources, the few we have must be dedicated to things that can help most people and, without doubts, current tagging experience is not one of those. To make it viable for most users you should completely redesign the UI interaction, that is expensive compared to the benefit. I can't tell if and when it will happen, but now it's not a priority for sure.

Updated

a year ago
Whiteboard: [bookmarks][design-decision-needed] → [bookmarks][design-decision-needed] triaged
Clearing needinfo, since we're not sure if we want to implement this.
Flags: needinfo?(kmaglione+bmo)

Updated

11 months ago
Duplicate of this bug: 1276816

Updated

11 months ago
Summary: bookmarks API should allow searching by tag → Allow reading and writing bookmark tags

Comment 16

11 months ago
Kris, thank you for changing the title/summary of this bug.  Now I agree that my new tags Bug 1276816 duplicates it :)

From searching the source code, it appears that the starting points for this bug would be in these files:

http://mxr.mozilla.org/mozilla-central/source/browser/components/extensions/ext-bookmarks.js
http://mxr.mozilla.org/mozilla-central/source/browser/components/extensions/schemas/bookmarks.json
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/test/mochitest/test_ext_bookmarks.html

It also looks like chrome.bookmarks is mostly a wrapper around the Places API,

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Places_Developer_Guide

so, fixing this bug would involve JavaScript similar to what I currently have in my extension.

I cloned mozilla-central this morning and am now writing this on NightlyDebug.  I think the next step is to wait for the design decision on whether or not Tags and the other three Firefox-only attributes are going to be obsoleted.

Bug 1225916 Tags (this)
Bug 1276817 Keyword
Bug 1276819 Description
Bug 1276821 Live Bookmarks

Comment 17

11 months ago
Preliminary comment: I inherited an ancient plugin https://github.com/wagle/tagspace-archive that lets you do arbitrary SQL queries to the places database.  If webextensions does that, then I think I'm set in converting/rewriting it (modulo me wrapping my brain around its javascript).

It currently works, albeit with my own use cases.

So the upshot is that I really need to query tags with complex queries, quickly (ie, without 6 levels of indirection slowing it down).

I expect to say something more useful in a couple days.

Comment 18

11 months ago
PS.  I have it up on a unlisted plugin "OldTagSpace" whose URL seems to be https://addons.mozilla.org/en-US/developers/addon/oldtagspace/versions/1781154

Comment 19

11 months ago
Well, I can say with relative certainty that WebExtensions won't ever be able to perform arbitrary SQL queries against the Places database. One of the goals of the the WebExtension APIs is to abstract away implementation details enough that we can make major platform changes without worrying about breaking extensions. And given that we definitely want to make major breaking changes to the places DB, we can't give extensions direct query access to it.

Comment 20

11 months ago
Ok, I live in my bookmark tag querier, and have been for years.  I require this to keep track of what I'm trying to do (1800+ page wiki).  You want to take away my cobbled together "wheelchair".

What do you propose that I do instead of using bookmark tags?  The original queries from the user are not SQL, but they get translated to SQL.  We could have the API do that translation, but whose translation do you use?  I propose a competition or something.

I was imagining that I'd prove my concept with a plugin first, then work on moving some of that code into firefox proper.  I worry that you are killing firefox by not allowing for such testing before migration.  Is firefox becoming closed source?  (Actually tricky question.)

My queries are roughly of the forms "Q and Q", "Q or Q", "not Q", and "? search_string", and "tag_name_prefix".  The last is a prefix because it starts partial queries when you start typing and allows for completions.

Note that there's nothing keeping my tags from referring to other things.  I would actually like tags to also refer to other tags, etc.  I don't know exactly what I want to do yet, I need a playground in which to try things out and see what works before changing firefox proper.  That's what plugins used to provide,  (Kinda sorta: things didn't appear to migrate from plugins to firefox much.)

So I don't mind having to port my plugin (and actually play with my ideas), I do greatly object to having no API to convert to.

Comment 21

11 months ago
(In reply to Perry Wagle from comment #20)

I object to your comments which I don't think further the conversation and suggest an attitude that I don't Kris deserves. The original bug and the point Kris made is that there should not be direct access to the places database, but instead an API to do queries to ensure the data integrity of the database.

Comment 22

11 months ago
And I addressed the direct access question with my translation idea of boolean expressions to SQL queries.

The proposal was to take my plugin away from me.  I take that threat with utmost seriousness, and am looking for alternatives.  Not reading me carefully led you astray.  Sorry.

Comment 23

11 months ago
(In reply to Perry Wagle from comment #22)
"You want to take away my cobbled together "wheelchair".", "Is firefox becoming closed source?", "I worry that you are killing firefox by not allowing for such testing before migration". 

No-one wants to remove these things from you right now or kill your Firefox and we are not becoming closed source.  

For example, you could propose and suggest an API, maybe in a Wiki or github page or blog post or whatever that outlines how an API could look and then supply some patches for this bug making Firefox work the way you want it. It of course has to pass approval by the module owners and needs to be discussed by the community.

Comment 24

11 months ago
I have re-read your comment and after a long day with lots of other problems going on at work, I realise I did over react a little. I apologize. I saw you on IRC today, if I see you tomorrow I'd like to take the time to chat to you in person, understand your suggestions. Sorry once again.

Comment 25

11 months ago
I rewrote this after your apology:

Upshot: you guys are scaring the sh*t out of me.

Proposing an API is daunting.  It assumes that I can wrap my brain around the Firefox source, fathom this mysterious direction (webextensions, electrolysis, etc) you guys are taking it, which is not at all obvious to me.  Its not in the current source code, nor in the documentation I've managed to find (generally you just say what you've done, and vague hints as to where you are going).  And sussing this out is something you propose I do every few months for the rest of my life, instead of getting my "real work" done.

Ok, fine.  I'm all for rewriting this large plugin I've inherited (and didn't write!) from scratch to The New Way.  Its big, slow and clumsy, and so far, impossible to comprehend.  My way of designing/evolving it's replacement would be to do it all in a new plugin and see what I want it to do and what I can make it do.

Since I need to experiment before reaching a design decision on the API, how about we shrink that to a shim that translates boolean expressions to SQL queries to wherever tags are today.  What boolean expressions would we be scared of, if any?  No sql injections, no little bobby tables https://xkcd.com/327/ ), assuming the strings in the boolean expressions get properly quoted during translation.  Grokking boolean expressions would be easier for that than SQL expressions.

I look forward to talking with you.  I did get a bunch of URLs on IRC.  I might be healthy enough to fathom my legacy plugin now.

Comment 26

11 months ago
What programming language would a tags API be written in?  A few months ago, I was warned off using Rust for a year, hence my procrastination in pursuing this problem, and waking up now that something seems to be about to happen.

Updated

9 months ago
Duplicate of this bug: 1293460

Updated

7 months ago
Component: WebExtensions: Untriaged → WebExtensions: General
Priority: -- → P3

Updated

6 months ago
Whiteboard: [bookmarks][design-decision-needed] triaged → [bookmarks][design-decision-approved] triaged
(Assignee)

Updated

a month ago
Assignee: nobody → ntim.bugs

Comment 28

a month ago
Hello, Tim.  I've written a patch to fix Bug 1276817 which I am sitting on until Bug 1343473 lands, which I hope will be any day now.  Bug 1276817 is quite similar to this one; it is to add support for bookmark Keywords.  I'd wanted to work on these two bugs and two others in parallel, but I understand Mozilla's policy is to keep bugs as small as practical, so they have been split into four bugs.  

My patch adds several hooks into which these asynchronously-fetched "Firefox only" properties (Keywords, Tags, Descriptions, Live Bookmark stuff) can be wired into, and of course I've wired my support for Keywords into these new hooks.  If my patch is more or less approved, you could add support for Tags into these same hooks.  Even though it works for me, my patch has not even been reviewed yet, and it's possible that I don't know what I'm doing and my patch may be mostly rejected.  In that case, I'm anxious to see you do it :)

In any case, I think you should look at my patch soon.  Posting it here would certainly cause confusion, so I've uploaded it to Pastebin for you: http://pastebin.com/0jKuy55K.  It should be there for 1 month.
Note that both keywords and tags are theorically unrelated to bookmarks and will in future move as such. They are a property of a uri, as bookmarked is.
Also note that keywords are likely to be converted to custom search engines.
Any API that binds those properties to bookmarks is thus likely to break when things will change.
(Assignee)

Comment 31

a month ago
(In reply to Jerry Krinock from comment #28)
> Hello, Tim.  I've written a patch to fix Bug 1276817 which I am sitting on
> until Bug 1343473 lands, which I hope will be any day now.  Bug 1276817 is
> quite similar to this one; it is to add support for bookmark Keywords.  I'd
> wanted to work on these two bugs and two others in parallel, but I
> understand Mozilla's policy is to keep bugs as small as practical, so they
> have been split into four bugs.  
> 
> My patch adds several hooks into which these asynchronously-fetched "Firefox
> only" properties (Keywords, Tags, Descriptions, Live Bookmark stuff) can be
> wired into, and of course I've wired my support for Keywords into these new
> hooks.  If my patch is more or less approved, you could add support for Tags
> into these same hooks.  Even though it works for me, my patch has not even
> been reviewed yet, and it's possible that I don't know what I'm doing and my
> patch may be mostly rejected.  In that case, I'm anxious to see you do it :)
Thanks for the pointers! I mostly plan to re-use some existing add-on SDK code: https://dxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/places/host/host-tags.js for this bug.

(In reply to Marco Bonardo [::mak] from comment #30)
> Also note that keywords are likely to be converted to custom search engines.
> Any API that binds those properties to bookmarks is thus likely to break
> when things will change.

It should be part of the engines management API (bug 1268401) I guess.

(In reply to Marco Bonardo [::mak] from comment #29)
> Note that both keywords and tags are theorically unrelated to bookmarks and
> will in future move as such. They are a property of a uri, as bookmarked is.

What API do you suggest for tags ? I plan to add simple tags property that returns a Set of tags to BookmarkTreeNode
Flags: needinfo?(mak77)
> (In reply to Marco Bonardo [::mak] from comment #30)
> > Also note that keywords are likely to be converted to custom search engines.
> > Any API that binds those properties to bookmarks is thus likely to break
> > when things will change.
> 
> It should be part of the engines management API (bug 1268401) I guess.

Probably, unfortunately we are lacking resources to fix the basic firefox implementation, so I can't give you an ETA.
But if you still want to continue, the API should be generic enough to support that future solution, that means it should not be bound to bookmarks in any way.

> (In reply to Marco Bonardo [::mak] from comment #29)
> > Note that both keywords and tags are theorically unrelated to bookmarks and
> > will in future move as such. They are a property of a uri, as bookmarked is.
> 
> What API do you suggest for tags ? I plan to add simple tags property that
> returns a Set of tags to BookmarkTreeNode

Since tags are not a property of bookmarks, but they are bound to uris, it's likely they will grow as an alternative to bookmarks. It's likely for the foreseeable future the firefox ui will keep showing them in the same bookmarking ui we already have, so from a visual point of view not much will change.
But from an API point of view, they should probably not be bound to bookmarks. As I said in comment 8, there is strict specification at this time.
The API should probably be generic: tag and untag a uri, get uris for a tag, gets tags for a uri, get all the tags. It should probably also provide some batch method to help building a tag cloud without having to fetch all the uris for all the tags (maybe the method returning tags could also return use counts). and likely it should have some sort of notification for added/removed tags.
This probably requires its own chrome.tagging. branch.
But please, don't rush an API that will enforce us to keep tags as they are today, cause it's not going to work.
Flags: needinfo?(mak77)
(In reply to Marco Bonardo [::mak] from comment #32)
> But from an API point of view, they should probably not be bound to
> bookmarks. As I said in comment 8, there is strict specification at this
> time.

typo, I meant "there isn't a strict specification". There is no spec at all in practice, cause known use-cases are very generic and uninspiring.
(Assignee)

Comment 34

a month ago
// describes a tag:
class Tag {
  String name; // tag name 
  Set<URL> tagged; // Set of tagged URIs
}

// Query tags by name or/and by URL associated to tags
// No parameter corresponds to querying all tags
// Returns a promise that resolves to an array of `Tag`
browser.tags.query({name, tagged});

// Tags a new URL
browser.tags.tag(name, url);

// Untags an URL
browser.tags.untag(name, url);

// Listeners
browser.tags.onTag.{add/remove/has}Listener((name, url) => {})
browser.tags.onUntag.{add/remove/has}Listener((name, url) => {}))



What do you think ?
Flags: needinfo?(mak77)

Comment 35

a month ago
Tim,

With tags unbound from bookmarks, it looks like you are "just" writing a WebExtensions wrapper around nsITaggingService :))  Anyhow, as soon as you post a working patch here, I'm anxious to apply it and give it an "alpha" test.  

(In the world of my WebExtension, tags are bound to bookmarks, so I'll need to put "adapter" code into my WebExtension.  Not too big a deal, though – I just need to port from my old extension, which used nsITaggingService in the same way.)
(In reply to Tim Nguyen :ntim from comment #34)
> // Query tags by name or/and by URL associated to tags
> // No parameter corresponds to querying all tags
> // Returns a promise that resolves to an array of `Tag`
> browser.tags.query({name, tagged});

If I want get the tags for a page, will I get a list of Tag objects where every Set contains all the urls included the one I care about, or only the uri I queried? I'm asking mostly because it could be more expensive to return all the uris when I only care about the one I queried.

> // Tags a new URL
> browser.tags.tag(name, url);
> // Untags an URL
> browser.tags.untag(name, url);

The thing to evaluate is whether makes sense to do this one by one, or as a list. So basically, what's more common, adding one tag or adding multiple tags? I assume the latter could be done more efficiently in code.
Also, it seems strange that these don't take Tag object you defined, as well as the listeners. Wouldn't it be more coherent to have common input objects?

(In reply to Jerry Krinock from comment #35)
> With tags unbound from bookmarks, it looks like you are "just" writing a
> WebExtensions wrapper around nsITaggingService 

With an important difference, nsITaggingService is currently synchronous, but will become asynchronous in the future. This wrapper should start asynchronous so it will be ready for future changes.
Flags: needinfo?(mak77)

Comment 37

a month ago
I think that the first and third issues raised by Marco arise from from declaring the "Tag" object.

Another issue with this declaration is that people already think of a "tag" as a string in a box in a tag cloud.  Let's call the latter a Physical Tag.  The proposed Tag object represents a relationship between a URL and a Physical Tag.  So we're going to create an incestuous homonym :(

I also think the "Tag" object is a layer of unnecessary complexity.  If we did not declare the Tag object, then the proposed browser.tags.query() function could be replaced by two more self-explanatory functions, something like getURLsForTags() and getTagsForURLs().

If in addition we modify the tag() and untag() functions to handle multiple tag names (Physical tags), as suggested in the second issue raised by Marco, then (surprise!) - browser.tags would declare four functions which exactly mimic the four functions of nsITaggingService.  Well, maybe mimicking something which has worked for more many years is not a bad idea :)

If we do really want the "Tag" object, consider renaming it, maybe as "Tagging", to at least eliminate the homonym issue.

Comment 38

a month ago
TL;DR: I expect to describe my vision of "tags" in various stages over the next several months.  I would prefer people not further restrict their meaning and power until I get a chance to blow everyone's minds with a whole new set of ideas.  The long version below tries to convey what's going on in my head so that you can reason about this in my shoes instead of your own.  I'm panicking because I don't want to be accused of waiting too long, like with the cancel button, but I don't think I'll be convincing anyone of anything for a few months. 


I've been ill for a few months.  Somewhat better now, hence my suddenly reappearing at this late hour.


For years I've been using tags to manage my huge numbers of wiki pages and general bookmarks.  I got used to doing only what I could do with Firefox tags, which is a surprising lot, but at the same time limited and slow.  I can verbalize what I did do much better than what I plan to do soon.

A partial list of what I used to do with very large numbers of tags-as-complex-strings is to: (1) determine the sort order via prefixes, (2) modify sort orders by changing prefixes/infixes/suffixes on the fly, (3) list all the bookmarks with a Boolean query expressions (and, or, not, search), (4) mark bookmarks (mostly my wiki/journal/organizer now) with multiple tags from sub-lists of tags (radio button or otherwise), where, with the complex-strings naming of tags, each sub-list might have different purposes (dates, groups, categories, importance, priority, etc).  Since the tag naming is currently somewhat flexible, I can keep changing and tuning my "system", which I've arduously done several times in the past several years.

What I can't do is stuff like tag a list of tags, and other types of indirection (my memory is log-jammed at the moment,  but its in there).  Over the years, I've had a whole gob of things I wanted to be able to do, but couldn't without spending a year or two re-programming the tag system.  So each time I wanted/needed something new, I'd have to ignore it, and go back to what I *could* do.  This "solution" however, has me turned into a (log-jammed) pretzel, a micromanagement hell of tedious little manipulations <emph> THAT COULD AND SHOULD BE AUTOMATED AND ALSO MADE FASTER </emph>.  As of the past week, I am now mildly funded to spend a year implementing my vision, and the jammed logs unrolled as I can actually implement the stuff in my head.

Its very hard, without producing prototypes (which I hope to have in various stages during the next year) to show people to describe what I have in mind.  I have two sources of incoherency: one I think and program "spatially" and not "linguistically" (I have to translate in my head to English which is hard to impossible), and two my working memory for spatial is (for the past decade) now very confused, and cannot linearize things to be done unless I use my computer (ESR45 + tag querying + wiki) to keep track of things.

What I've done so far this past week is to make the bookmark editor resizable, which did a lot to first ground me in extension writing, and second to learn something about how to translate old-style extensions to "modern" Firefox.  Now maybe claims that the tiny old thing is too cluttered might go away.  If you use my vision of tags, you *will* want a cancel button and/or much better undo'ing, so I'm trying to find my old notes on that.  Finally, I am currently dovetailing between fixing the old bugs in my old overlaid XUL tagspace extension and a new-from-the-ground up pure webextension version.

Comment 39

a month ago
Hmm..  In comment 38 above, I was mostly responding to comment 37.
Mentor: jhofmann@mozilla.com
You need to log in before you can comment on or make changes to this bug.