When using the table export function with an InnoDB table, you will not always get every row in the table. This is because the table export function seems to rely on 'show table status' to get the number of rows in the table, which is then used to specify a range of rows to be exported. This defaults to the number of rows shown in the 'show table status' command with the starting row of 0.
Unfortunately, as indicated in many related bug reports, the 'show table status' call on an InnoDB table is an estimate which can sometimes be too small. If the estimate ends up being too small at that point in time, you will not get every row in the table. You could use $cfg['MaxExactCount'] integer to work around this issue but it will severely impact the performance all around. Another option, which is being used by some, is to manually increase the number that is set where it says Dump x row(s) starting at record #0.
A solution would be to make that a radio selection where another choice is to export the whole table or to always force MaxExactCount when the export functionality is being used and the underlying table uses the InnoDB engine. The first solution would perform much better but be a small UI change. This feels like a bug to me but I would not be offended if this is reclassified as a feature request.
A related problem: when you export at the database level, you don't even have the option of specifying the number of rows for each table, and the InnoDB export can still be incomplete.
I did not test correctly the exporting at database level. The problem is only at the table level.
Fixed in subversion, thanks for reporting.
New choice added; needs a new message (using $strAll did not look good) so fix is present for 3.3.