Listing all Firefox keywords at the same time?

Easy:

I have discovered a trick! When you search within the Firefox Bookmarks Library, it will return a list of bookmarks that contain your sequence of characters in any of their fields. 99% percent* of bookmarks will contain a period in their location. If you search using ., it should list all of your bookmarks. If not, the space character seems to function as a wildcard.

After, you've listed all the bookmarks, click the Keyword tab to sort. :)

_{*I have a few bookmarks simply mapped to host names on my network.}

Hardcore:

Alternatively, you could export your bookmarks to HTML, and write a little program which scans the file, collecting keyword and bookmark pairings which are then sorted before printing the result. I was going to do this, until I played around with the search...

Add a tag (i.e "KEYWORDS") as well as a keyword everytime you associate a keyword with a link. Now click on Tags in the "Bookmarks Library" and find your links with the tag "KEYWORDS". Shizam! Wizadry!

Sadly, the "easy" method in iglvzx's answer no longer works. The "Keyword" column is missing from the list of choices, on modern FireFox builds.

See: https://support.mozilla.org/t5/Firefox/Firefox-library-keyword-column-missing/m-p/1140708 as well as the bugzilla item

Furthermore, on recent Firefox, they took away the ability of extensions to access profiles.sqlite, so the "SQLite Manager" option no longer works, either!

Firefox design is increasingly hostile towards keywords, sadly ):

Now, it seems the only good option to dump keywords is using the "hardcore" method from the other answer (dump to HTML) or edit the places.sqlite file directly, using sqlite3 CLI or otherwise.

Note: if you go the places.sqlite route, you have to make sure to update the hash value of the URLs as well as the URLs themselves, if you are making changes. I've used this with success: sqlite-mozilla-url-hash

For reference, this seems to be the order of events:

1. 2015-03-19: a bug is opened to remove the column. The reason seems to be that its presence was making some code migration difficult, and with some hand-waving, it was declared that the current UI was not good anyway, so it was okay to remove.

2. 2015-05-04: the change is made to remove the column.

3. 2015-10-20: people noticed the change, and started complaining. Response is "we will likely provide an alternative ui in the future".

4. now: The bug to track implementing a new UI is 648398, which is still open this many years later.