Places:Plan: Difference between revisions

Jump to navigation Jump to search

Places:Plan (view source)

Revision as of 19:19, 14 March 2011

13,222 bytes removed ,  14 March 2011
no edit summary
No edit summary
Line 1: Line 1:
Roadmap for future work on Places, the SQLite-driven Bookmarks and History system.
Evolution of future work on Places, the SQLite-driven Bookmarks and History system.


= Faaborg's Places UI Redesign requirements =
Items that are most likely needed to allow Faaborg's proposed Places UI Redesign. Each one has motivation in braces.


== Firefox 3.7 ==
= Schema Changes =
* Places bookmarks&history thumbnails service (bookmarks in content)
* '''GOAL:''' Database filesize reduction, performances, healthier management
* Storage migration component (downgradable schema changes)
* '''ETA:''' Firefox 7
* Livemarks children out of bookmarks (simpler queries, perf)
* '''LEADER:''' TBD
* drag & drop cleanup (preparation for new d&d between treeview and content)
* '''PRECONDITIONS:''' History backup
* treeview paging (perf)


== Firefox 4.0 ==
=== Create history backups ===
* Tags out of bookmarks (perf, tag queries)
This is a precondition to stop caring about corruptions, downgrades, compatibility.
* Nested preordered tree bookmarks (perf, breadcrumb view with ancestors)
* '''PROPOSAL:''' per-host backups and expiration, csv-append-like.
* New querying API and SQL query builder (perf, query for folders andtags, better filters)
* '''PRECONDITIONS''' out-of-mainthread file access? (append and remove)
* async containers populating (perf, history in content)
* '''BUG:''' TBD
* Places queries in content
* fulltext indexing (searches)


= Current planning =
=== Coalesce titles across history and bookmarks ===
Strings are the largest database offender, we never use both titles and all the queries have to coalesce titles.  Users want us to update titles automatically when they change if they didn't manually set a different bookmark title.
* '''PROPOSAL:''' keep only one title in moz_places, track whether it's expirable.
* '''BUG:''' TBD


== Firefox 3.6 ==
=== Tags out of moz_bookmarks ===
Tags are actually folders, this is unefficient and takes a lot of filesize for nothing, searches are slow as well since subqueries suffer from missing indices.
* '''PROPOSAL:''' tags in a separate relational table.
* '''BUG:''' TBD


=== VACUUM Places database (complete) ===
=== Livemarks out of moz_bookmarks ===
Some user reports slow database performances, due to fragmentation, we should start investigate and implement Vacuum in Places, and in future make that app-wide.
Livemarks are actually folders of temporary bookmarks, this is unefficient and causes unneeded database fragmentation.
* '''PROPOSAL:''' redesign from scratch.
* '''BUG:''' TBD


* '''PROS:''' smaller and faster db.
=== Remove dynamic containers support ===
* '''CONS:''' vacuuming too much can cause slower INSERTs, vacuum takes long time.
They never worked, nuke them.
* '''EST:''' 1 week.
* '''PROPOSAL:''' Remove all related code, redesign from scratch.
*'''BUG:''' {{bug|512854}}
* '''BUG:''' TBD
* '''DEPENDS:'''
* '''STATUS:''' complete
* '''TEAM:''' mak


=== Tests re-enable/cleanup (active) ===
=== Kill moz_bookmarks table ===
We have a bunch of tests (also folders of tests) that have been disabled and never touched again, and bugs filed about queries tests containing tests that were never pushed due to minor issues that now could be fixed (or is worth fixing them).
Once titles are flattened to moz_places and dynamic containers killed, most of bookmarks data consists of hierarchical information, then just make them so.
* '''PROPOSAL:''' Flatten isBookmark tracking in moz_places, have tags and folders just be hierarchical descriptions of these entries.
* '''PRECONDITIONS:''' flattened bookmarks in moz_places, tags out of bookmarks.
* '''BUG:''' TBD


* '''PROS:''' larger test base at a relatively low cost.
=== Re-evaluate history tracking information ===
* '''CONS:'''
We track each single step in the history visit chain, but these data are not really useful as of today, the UI mostly cares about the destination page, not about the full redirects chain, and walking it up is slow and unefficient.
* '''EST:''' 1 week.
Sessions tracking has been removed, and adds useless data. Sync also missed some of these data.
*'''BUG:''' {{bug|509868}}
* '''PROPOSAL:''' Simplify, remove redundant information, track only what matters.
* '''DEPENDS:'''
* '''BUG:''' TBD
* '''STATUS:''' active
* '''TEAM:''' mak


== Firefox 3.7 ==
=== Keywords are unefficient ===
Currently these are a mostly-null column in moz_bookmarks, we should allow a 1_keyword->n_uris but not the opposite.
* '''PROPOSAL:''' Convert keywords to annotations? they are already being lazily cached by bookmarks service for performance and IO.
* '''BUG:''' TBD
* '''PRECONDITIONS:''' Better annotations management


=== Find async query wins [p2] ===
=== Annotations are unefficient ===
Need to find points that require async love.
Most of the annotations are simple boolean stuff, so they could be categorized as: dataless, with-data. Dataless annotations shouldn't take all the space they are today.
With-data annotations on the other side allow for binary data, but that data should NOT be stored in the database, let's allow the filesystem to handle them.
Side notes: Having separate page and item annotations is confusing for both API and code, unfortunately we allow to annotate folders and this could be problematic to flatten. Could favicons become binary annotations?
* '''PROPOSAL:''' Split dataless annotations to save space and get better performances.
* '''BUG:''' TBD


=== Move tags out of bookmarks table ===
=== Evaluate Microsummaries removal ===
Tags are actually bookmarks folders, so we have to duplicate bookmarks inside them, pay attention to not add containers/separators inside them, move bookmarks when merging/splitting two tags, filter out them from all bookmarks queries. Having tags in a separated table would make all of this much easier and faster. Apart performance, we also have bugs that are coming from our "fancy" tags implementation and should be workaround if we don't fix the implementation.
They are our largest js component, but only a few users use them, and never take off completely as a standard.
* '''PROPOSAL:''' Move microsummaries to an add-on.
* '''BUG:''' TBD


* '''PROS:''' faster bookmarks queries, simpler bookmarks code. faster autocomplete queries. no data duplication. easier merge/update tags.
=== Evaluate bookmarks roots removal ===
* '''CONS:''' Will require a separate table to hold tags. Need to revise all tagging related code and tagging service.
Roots caused more bugs than benefits, UI can better use annotated folders in a simple 1-root hierarchy.
* '''EST:''' 2 weeks.
* '''PROPOSAL:''' Annotate special folders, 1-root hierarchy
* '''BUG:''' {{bug|424160}}
* '''BUG:''' TBD
* '''DEPENDS:'''
* '''STATUS:''' inactive


=== Denormalize info into moz_places and revise PlacesSQLQueryBuilder ===
Actually the query builder code is in history.cpp, but there is much related code out of it. Ideally it should just receive queries and options, and return an OPTIMIZED sql query. As it is code is confusing and returned queries are not always optimized.
We should flatten most informations in moz_places and rewrite the builder so that it will return better queries. For example it should not JOIN history table if we are not interested in querying history values (like querying by timeframe).


Actually we could just convert nsNavHistoryQuery.cpp to JS, and make the SQL query be a property of a query, we could provide an inclusion mode that will use: UNION, INTERSECT, EXCEPT...
= Async APIs =
the query system should be able to get a query string in places format, or json, or anything other, having a parser to convert it to an internal representation, and use that to build SQL queries in a de-normalized and performant way.
* '''GOAL:''' No UI-blocking tasks
* '''ETA:''' Firefox 7
* '''LEADER:''' TBD


*'''PROS:''' more manageable and separated code between history and SQL. Easily to build more optimized queries (better performances for uri based queries).
=== Simpler and async querying API in js ===
*'''CONS:''' this is a rewrite with some risk.
The classical querying API is complicated by xpcom, we need a deCOM version of it, this was partially done for Jetpack, must be finished.
*'''EST:''' 1.5 weeks.
* ''' PROPOSAL:''' Finish the work started for Jetpack, with a js module.
*'''BUG:''' {{bug|500290}}
* ''' BUG:''' TBD
*'''DEPENDS:''' 
*'''STATUS:''' inactive


=== make GUIDs not annotations ===
=== Finish async favicons service ===
This is a Weave need, we need to talk to them and understand what are the problems andhow we can fix them.
Favicons service is already partially async, but the work has to be completed on all APIs.
* ''' PROPOSAL:''' Make all interface methods async.
* ''' BUG:''' TBD


=== Fix dynamic containers and convert livemark children to them ===
=== Finish async containerOpen ===
All queries involving bookmarks have to filter out livemarks children that are not real bookmarks, also checking if an uri is bookmarked requires a similar filtering. Moreover the new async locationbar is not correctly filtering these out. Plus livemarks service is slow in updating livemarks because bookmarks are sync written to disk.
Folders work, but it was never used live.
Dynamic containers stuff can be useful for extensions.
* ''' PROPOSAL:''' Evaluate if this is still the wanted approach.
* ''' BUG:''' TBD


* '''PROS:''' faster bookmarks queries, simpler bookmarks code. no more UI-blocking while updating livemarks (make livemark service as async as possible).
=== Async bookmarks API ===
* '''CONS:''' Will require a separate db to hold livermarks children. Will need some API change to livemarks service to allow extension developers to access livemarks children, and add their own "annotations" on them.
Largely wanted for Sync and mobile.
* '''EST:''' 3 weeks.
* ''' PROPOSAL:''' split a new interface, gather from what we did for history.
*'''BUG:''' {{bug|453530}}
* ''' BUG:''' TBD
* '''DEPENDS:''' {{bug|457708}}
* '''STATUS:''' active
* '''TEAM:''' mano, mak


=== Make Expiration async and performant (active) ===
= Better Notifications =
Expiration currently runs on shutdown and on idle, if possible it should instead run in background and be async.  We should try to unify it with queries that run in nsPlacesDBFlush, so that we will write to disk the less often as possible. Expiration should be removed from history, and moved to a separate JS component for sake of simplifying history code and separating not completely related code. Expiration algorithm could even be reviewed a bit to make it simpler.
* '''GOAL:''' More performant observers
https://wiki.mozilla.org/Firefox/Projects/Places_async_expiration
* '''ETA:''' Firefox 5
* '''LEADER:''' TBD


* '''PROS:''' no UI-blocking or standby blocking expiration. Less disk writes.  easier to manage code.
=== Give more informations to the observers ===
* '''CONS:''' It's a rewrite, with some possible privacy risk.
Our actual notifications don't tell anything to the observer, it will have to query again to know informations that the notifier already has.
* '''EST:''' 2 weeks.
* ''' PROPOSAL:''' Add URI, GUID and whatever we can, poll Sync as a privileged user of our notifications.
* '''BUG:''' {{bug|520165}}
* ''' BUG:''' TBD
* '''DEPENDS:'''
* '''STATUS:''' active
* '''TEAM:''' mak, mano


=== Asynchronous isVisited (active) ===
=== Avoid useless notifications traffic  ===
This is needed for Electrolysis and Tsnappiness, isvisited sould get data async.
Just changing position could sometimes fire a removed and a added notifications.
* '''PROS:''' no UI-blocking and Tp wins.
* ''' PROPOSAL:''' Reduce observers traffic.
* '''CONS:'''
* ''' BUG:''' TBD
* '''EST:'''
* '''BUG:''' {{bug|511960}}
* '''DEPENDS:'''
* '''STATUS:''' active
* '''TEAM:''' sdwilsh


=== Open containers asynchronously (active) ===
Opening containers is slowing down and blocking UI, it should be done async.


*'''PROS:''' UI responsiveness.
= In-content UI =
*'''CONS:''' Can cause views bugs, needs to move back some code to the backend.
* '''GOAL:''' Better user experience
*'''EST:''' 
* '''ETA:''' Firefox 7
*'''BUG:''' {{bug|490714}}
* '''LEADER:''' TBD
*'''DEPENDS:'''  
*'''STATUS:''' active
*'''TEAM:''' adw


=== Frontend related ===
=== Thumbnails service ===
*      cut and paste is slow (partly broken)
Any in content UI will probably want pages screenshots, this issue can be coalesced with Sync needs, also look at other vendors suggestions for speed dial thumbs.
*      dnd is slow (partly broken)
* ''' PROPOSAL:''' Allow web authors to specify their own thumbs or make a new one with a tentative algo.
*     delayed bookmarks init (delayed toolbar init, like chrome)
* ''' BUG:''' TBD
*     history menu (cache w/ json? live update?)


== Firefox 4.0 ==
=== Breadcrumb navigation ===
As in most today-ish OS, simplify navigation in the Places hierarchies.
* ''' PROPOSAL:''' History or Bookmarks breadcrumbs.
* ''' BUG:''' TBD


=== Convert bookmarks table to a preordered nested tree ===
=== Drag&Drop chrome-content ===
Nested Trees are a good way to manage a hierachy in sql, you can most likely select anything with one query, and no recursion is needed at all. So you can with one query know if a node is descendant or ancestor of another one. This will allow to print out bookmarks paths in the UI, search for folders, check ancestors/descendant with better performances and so on.
D&D code needs to be simplified and allow interaction with in-content UI.
* ''' PROPOSAL:''' TBD
* ''' BUG:''' TBD


*'''PROS:''' allows to completely avoid recursion when querying descendant/ancestors of a bookmark. fast children count. Self protection from creating cycles of bookmarks.
=== Kill the Library ===
*'''CONS:''' Needs schema changes (2 or 3 columns in moz_bookmarks). INSERTS/UPDATES/DELETES could be a bit slower and harder (triggers could help for complexity).  
Should be moved in-content, long treeviews should be paged.
*'''EST:''' 2 weeks.
* ''' PROPOSAL:''' TBD
*'''BUG:''' {{bug|408991}}
* ''' BUG:''' TBD
*'''DEPENDS:''' {{bug|424160}}, {{bug|453530}}
*'''STATUS:''' inactive


=== Denormalize referrer in moz_places table ===
=== Donwloads in Places ===
Actually from_visit reports the page we have come from, so in case of a double redirect we would have to recurse twice to go to the original site. It would be nice having a new column reporting a sort of referer, or a new table schema allowing to query without recursion.
Move downloads manager to a toolbar widget, and allow to track and manage all downloads in the in-content UI.
We could ideally reuse session column (that is actually minused) to track redirects, querying first visit with the same session would give back a somehow correct referrer.
* ''' PROPOSAL:''' TBD
* ''' BUG:''' TBD


*'''PROS:''' Easily query for referer and visit-chain, avoiding recursive queries. Useful for extsnsions and security checks (how did i come here?)
=== Better search-ability ===
*'''CONS:''' Needs schema changes.
We should allow the user to filter results from history and bookmarks better, also to allow more granular privacy removals.
*'''EST:''' 1,5 weeks.
* ''' PROPOSAL:''' Revised in-content search UI
*'''BUG:''' {{bug|468710}}
* ''' BUG:''' TBD
*'''DEPENDS:'''
*'''STATUS:''' inactive


=== Remove temp tables ===
They are ugly.


=== Change keywords schema to drop multiple keywords support ===
= Fulltext indexing =
Keywords live in a separated table, but they are linked through a keyword_id column in moz_bookmarks, this is often null, and that's not good since it will take a lot of useless space in the db We should instead have a (keyword, item_id) table, and no column in moz_bookmarks.
* '''GOAL:''' No tables scan on search
* '''ETA:''' TBD
* '''LEADER:''' TBD


*'''PROS:''' less wasted space in the db.
=== Find a good tokenizer ===
*'''CONS:''' Needs hard schema change.  
The pages case is special, since the same profile can have visits in different locales, the tokenizer should be per URI. LibICU is nice but huge.
*'''EST:'''  
* ''' PROPOSAL:''' TBD
*'''BUG:'''
* ''' BUG:''' TBD
*'''DEPENDS:'''
*'''STATUS:''' inactive


=== figure out why annotations are slow (weave) ===
=== Measure perf win/loss ===
 
FTS can give nice boosts, but also perf loss in some case, have to figure out the right compromise.
=== Notifications should give more informations to the observers ===
* ''' PROPOSAL:''' TBD
Our actual notifications don't tell anything to the observer, it will have to query again to know informations that the notifier already has. For example if i get onItemAdded, i have to query bookmarks service to know which kind of item, and at what time it was added.
* ''' BUG:''' TBD
Having better notifications would reduce queries load and make observers more performant.
 
*'''PROS:''' less queries. faster observers.
*'''CONS:''' Compatibility with extensions.
*'''EST:'''
*'''BUG:''' {{bug|494380}}
*'''DEPENDS:''' {{bug|498130}}
*'''STATUS:''' active
*'''TEAM:''' mano, mak
 
*      non crappy notifications (avoid removed/added on index changes)
*      reduce observer traffic
*      async addBookmark
*      async addVisit
=== Remove LAZY_ADD, use async storage instead ===
LAZY_ADD is the old workaround to implement an async addition of visits and favicons, we should get rid of it and use async storage instead.
 
* '''PROS:''' less code bloat and UI-blocking.
* '''CONS:''' Views will be updated faster, will that be an issue? We are just moving work earlier.
* '''EST:''' 1 week.
* '''BUG:''' {{bug|499828}}, {{bug|429989}}
* '''DEPENDS:'''
* '''STATUS:''' inactive
 
=== investigate use of templates ===
 
= Not-yet targeted stuff =
 
=== Places downgrades or upgrades should allow any schema change ===
When we change schema we have to ensure tables are compatible with previous version, this is blocking us from doing big/important changes to how we store our dataset.
We should create a new downgrade path able to manage any kind of schema change and backport it to any supported version (3.6, 3.5, 3.0, ...)
Initial idea was to backup and restore history reuilding the db, but this has disadvantages across app versions.
 
Better and newer idea is to use a migration component similar to the migration components in Rails and Django. The component will be ported to all supported versions and will stay frozen on schema changes.
Instead the changes will be described in diff structures, that we can store in a schema_diffs table. the diff would be a JSON string with properties to describe the change, or pre-built SQL queries.
On init the service will read the schema version, if it differs it will pass the connection to the migration component. This should in some case export data, rebuild schema, and reimport data. other additive cases could be simpler.
Since all schema steps are self contained in the database, the migrator can walk through them regardless application version.
 
NOTE: This should be a Storage Component, so that anyone can use it to migrate his SQLite database. Or maybe transparent, so that if i open a database connection setting a magic optional param, the schema will be automatically upgraded/downgrade.
 
*'''PROS:''' no downgrade restrictions for schema
*'''CONS:''' have to design and implement the migration component in an abstract enough fashion to handle many cases.
*'''EST:'''
*'''BUG:'''
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Review Places views drag & drop code ===
Places drag & drop code needs some further cleaning: menus code should be cleaned up to just use new d&d API, trees code should be fixed since trees are now partially using new d&d API, we should support more natural dragging through menus (diagonal dragging).
 
*'''PROS:''' more natural D&D experience for users. cleaner code.
*'''CONS:''' no deep tests are possible, regressions risk.
*'''EST:''' 1,5 weeks.
*'''BUG:''' {{bug|419911}}
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Detect real database corruption (integrity_check) ===
Actually we don't detect real database file corruptions because it's slow, we should still, because there is no easy path to bring users out of it. Better if done at a browser/app wide level.
 
*'''PROS:''' allow users to recover data
*'''CONS:''' slow
*'''EST:'''
*'''BUG:''' {{bug|506905}}
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Places performance tests ===
Tests and graphs for UI performance: microbenchmarking, dirty profile testing, etc. Needs to hook into Talos for continuous integration, and Perfomatic for reporting.
 
*'''PROS:'''
*'''CONS:'''
*'''EST:'''
*'''BUG:'''
*'''DEPENDS:'''
*'''STATUS:''' partly active
*'''TEAM:''' ddahl, alice, dietrich
 
=== Create a Places Page-Thumbnails service ===
This would be useful in various parts of the UI and good for extensions. Some extensions are reimplementing this, and if not done correctly this will hurt us badly (See old Google Toolbar for example, putting all thumbnails in annotations, and causing places.sqlite to bloat hundred of MBs)
 
*'''PROS:''' Usable in library, and many other points of access to bookmarks/history, maybe in tooltips too. Built to be async. Extensions that need thumbnails won't hurt us.
*'''CONS:''' will use some disk space, privacy concerns.
*'''EST:''' 2 weeks.
*'''BUG:''' {{bug|497543}}
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Queries improvements ===
Support querying for the exact data set that the location bar can, support querying on transition type, implement RESULTS_AS_FULL_VISIT or put everything needed into a visit node and deprecate FULL_VISIT, expose frecency.
 
*'''PROS:''' better queries, allow for further enhancements.
*'''CONS:'''
*'''EST:''' 2 weeks.
*'''BUG:'''
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Better JSON-friendly querying API ===
Querying Places is hard, having a better JSON API would be cool, this is actually under experimentation in JetPack, but we would like to uplift that.
 
*'''PROS:''' easier to query for extensions.
*'''CONS:'''
*'''EST:'''
*'''BUG:'''
*'''DEPENDS:'''
*'''STATUS:''' active
*'''TEAM:''' ddahl
 
=== Provide extended API to insert or get bookmark properties ===
Transaction manager, sync services and restore/import have to insert bookmarks and then set various additional properties. We also do not provide a way to get back all properties for a bookmark with a single call. This causes more queries traffic and notifications than needed. Would be cool to provide insertBookmarkExt and getItemProperties to allow setting getting all properties at once.
 
*'''PROS:''' faster bulk inserting and reading
*'''CONS:''' API noise
*'''EST:''' 1 week.
*'''BUG:''' {{bug|473666}}, {{bug|473664}}
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Fix Cut in Places frontend, to avoid dataloss ===
Actually Cut is doing Remove&Copy, this means to undo it user will have to undo twice, and after a Cut if user closes browser or it crashes the cutted elements will be lost.
 
*'''PROS:''' no dataloss, single action undo
*'''CONS:'''
*'''EST:''' 2 days.
*'''BUG:''' {{bug|484578}}
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Make bookmarks service initialization fault tolerant and faster ===
Check roots are in a good shape on start, but only do that when we are sure something has changed in the db.
 
*'''PROS:''' avoid bloating places.sqlite
*'''CONS:''' harder to query
*'''EST:'''
*'''BUG:''' {{bug|478912}}
*'''DEPENDS:'''
*'''STATUS:''' active
*'''TEAM:''' adw
 
=== deCOM internal bookmarks and history observers ===
Avoid xpcom overhead, use results globally to observe changes.
 
*'''PROS:''' less queries. faster observers.
*'''CONS:''' Compatibility with extensions.
*'''EST:'''
*'''BUG:''' {{bug|497608}}
*'''DEPENDS:''' {{bug|497387}}, {{bug|497389}},  {{bug|497605}},  {{bug|497606}},  {{bug|497607}}
*'''STATUS:''' active
*'''TEAM:''' mano
 
=== Add UI for quick tagging ===
Quick tagging UI through keyword.
 
*'''PROS:''' faster tagging for heavy taggers.
*'''CONS:''' discoverability?
*'''EST:''' practically done
*'''BUG:''' {{bug|434946}}
*'''DEPENDS:'''
*'''STATUS:''' active
*'''TEAM:''' dietrich
 
=== Add hooks for extensions in Library ===
Library needs to provide hooks for extensions content. Maybe a specific root where they can put dynamic containers or personalized content. There should be some sort of "registration" for both content and special views.
 
*'''PROS:''' easier for extensions to provide their own views for the Library
*'''CONS:''' adds complexity to the Library, Library perf/bloat.
*'''EST:'''
*'''BUG:'''
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Use Places Temp Tables for Private Browsing ===
Actually when private browsing starts it "freeze" Places, so that no new visits are added. In this state i could not use the awesomebar, the history menu or sidebar to see where i was 5 minutes ago or find a website i've closed. IDeally all Places features should continue working.
 
The private visits could be showed differently in the primary UI, maybe by putting a special private icon near them or changing their color to grey, or their background. They would be marked as private in the temp table through a special "private" column, on sync we would avoid syncing to disk "private" visits. On exiting private browsing we would clear all private items from the temp tables (they would so disappear from the UI)
 
*'''PROS:''' all Places features would work and help user during private browsing.
*'''CONS:''' Needs UI changes to clearly show that informations are added only "temporary", till PB is disabled.
*'''EST:''' 1.5 weeks.
*'''BUG:'''
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Add Advanced Search UI in Library ===
This has been disabled, should be re-enabled, or rethought (maybe a content page?)
 
*'''PROS:''' allow users to create better personalized searches.
*'''CONS:'''
*'''EST:''' 2 weeks.
*'''BUG:''' {{bug|436380}}
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Better handle large number of annotations ===
Google Toolbar has demonstrated that an extension heavily using annotations can easily bloat places.sqlite, they should either be saved in a separate attached db, or at least binary ones.
 
*'''PROS:''' avoid bloating places.sqlite
*'''CONS:''' harder to query
*'''EST:'''
*'''BUG:'''
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Enable full-text indexing ===
Being able to search in queries with full text indexing should give back good results, once we can vacuum.
 
*'''PROS:'''
*'''CONS:'''
*'''EST:'''
*'''BUG:''' {{bug|342913}}
*'''DEPENDS:'''
*'''STATUS:''' partly active
*'''TEAM:''' adw
 
=== Revise Bookmarks and History sidebars ===
Sidebars UI is quite old, and needs rethought.
 
*'''PROS:''' better UX.
*'''CONS:''' moving away from consolidated way of interaction.
*'''EST:'''
*'''BUG:'''
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Revise Library UI ===
Library interaction is quite messed up and not perfect.
 
*'''PROS:''' better UX.
*'''CONS:''' needs lot of brainthinking
*'''EST:'''
*'''BUG:'''
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Allow to search folders in Places search fields and awesomebar ===
 
*'''PROS:''' better search UX
*'''CONS:'''
*'''EST:'''
*'''BUG:''' {{bug|469424}}, {{bug|406157}}
*'''DEPENDS:'''
*'''STATUS:''' inactive
 
=== Allow searching and managing downloads in Library ===
Library was initially intended to manage not only history and bookmarks but also downloads, as personal data.
 
*'''PROS:''' Central place to manage navigation data.
*'''CONS:''' adds more bloatness to Library.
*'''EST:''' 1,5 weeks.
*'''BUG:''' {{bug|402231}}
*'''DEPENDS:'''
*'''STATUS:''' inactive
[http://www.example.com titolo del collegamento]
 
== Further ideas yet to be parsed ==
These are enhancements that need further thoughts or involve minor changes.


= To-be-parsed stuff =
* investigate use of templates
* more natural dragging through menus (diagonal dragging)
* Places performance tests
* Fix Cut in frontend, to avoid dataloss
* deCOM internal bookmarks and history observers
* Add UI for quick tagging
* Allow to search folders
* More reduction of writes and fsyncs
* More reduction of writes and fsyncs
* reduce query volume
* reduce query volume
* get better tree views performance on large history trees
* awesomebar extensibility (frecency bonus, external providers, ...)
* reduce copy/paste/delete operations weight {{bug|391836}}
* awesomebar extensibility (frecency bonus, external providers, {{bug|399213}})
* tags in HTML export/import?
* tags in HTML export/import?
* Pluggable views in Library based on collection type
* Pluggable views
* Unified search in Library and Sidebars
* make Most Visited better (show most visited typed uris)
* make Most Visited better (show most visited typed uris)
* support for browser.chrome.favicons ({{bug|331228}})
* support for browser.chrome.favicons ({{bug|331228}})
Mak77
Confirmed users
595

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/290866"

Navigation menu