We should separate the "add" row from the rest of the table as part of the UX refresh in bug 1533856.

Having a special "add" row as a separate table, as shown in bug 1533856, may be more complex to implement than just adding a different top border on the last row of the main table, or change its background color.

Additionally, once the "add" button is pressed, the row becomes just a regular preference row. If this was originally shown in a separate table, it would probably be too jarring to remove such a prominent visual separation, so the row would have to stay separated until the next search or refresh, when it will also be placed in the proper sort order.

On the other hand, if this was implemented as a style that adds a top border or changes the background color, it would be easy to remove the style immediately when the row becomes a regular preference row.

When a preference is deleted it currently gets the same style as a preference that can be added. A top border would not be needed in that case, but only for this new special "add" row.

When this bug is about to be assigned, it may be worth asking Markus if the solution of a border or background is compatible with the UX goal.

Markus, here's a screenshot with just the border added. Does this work for the design? As Paolo pointed out there could be a fairly large shift once a pref is added if we fully separate it from the table.

Seems ok. It at least resolves the odd state of 2 white rows next to each other when there is only one result.

(In reply to Markus Jaritz [:designakt] (UX) from comment #3)

It at least resolves the odd state of 2 white rows next to each other when there is only one result.

This is actually a bug, I'm fixing this in bug 1580180.

https://hg.mozilla.org/mozilla-central/rev/4e83dcd91c83