Confirmed with Firefox 25 and Writer Rev. 1525015 Win 7.

Created attachment 82510 [details]
Example file contains a table in a row of another table

The file indicated in the reporter's desciption contains table in table.
When I load the file, the first TH makes the cell and it contains hole following 
tables that should be placed in the following rows.

The attached file contains small table in table. "th" element is not the problem 
but the same problem happen with tr element.
When I replaced the second table (placed in the table) with some string, 
the problem did not happen.

(In reply to hanya from comment #2)
> Created attachment 82510 [details]
> Example file contains a table in a row of another table
> 
> The file indicated in the reporter's desciption contains table in table.
> When I load the file, the first TH makes the cell and it contains hole
> following 
> tables that should be placed in the following rows.
> 
> The attached file contains small table in table. "th" element is not the
> problem 
> but the same problem happen with tr element.
> When I replaced the second table (placed in the table) with some string, 
> the problem did not happen.

Still a problem in the latest Git.

These workarounds, brilliantly noted by pawo509 on bug 38961 comment 11, get the table to show properly in your sample document too:

---quote---
To make it work under Oo 3.x put the nested table in the <div>:

<td>
<div><table><tr><td>nested table</td></tr></table></div>
</td>

or just put something between <td> and nested <table> tags, for example:

<td>&nbsp;
<table><tr><td>nested table</td></tr></table>
</td>

If You put something AFTER the nested table it still does not work.

Anyway those are just workarounds, permanent solution for that issue is needed.
Attached You will find HTML files where this problem can be observed.
---quote---

What we expect to see is:
+------------------+
|(Table 0, A1)     |
| Hotkeys          |
+------------------+
|(Table 0, A2)     |
|+-------------+   |
||(Table 1, A1)|   |
|| File        |   |
|+-------------+   |
|                  |
+------------------+

But instead we see:
+------------------+
|(Table 0, A1)     |
| Hotkeys          |
|+-------------+   |
||(Table 1, A1)|   |
|| File        |   |
|+-------------+   |
+------------------+
|(Table 0, A2)     |
|                  |
+------------------+

We don't know where the problem occurs, but today it dawned on me that we could discover that in several ways.

Logically, the process of loading and displaying the HTML file must look something like this:

+----+          +----------+          +----+
|HTML| Loading  | In-memory|  Saving  |HTML|
|file|--------->|  state   |--------->|file|
| A  |          +----------+          | B  |
+----+               |                +----+
                     | Rendering
                     v
                +----------+
                |  Screen  |
                +----------+

Now what we see on the screen is wrong, but what is broken, loading or rendering?

If, once loaded, we save the file to another HTML file, and examine the contents of that one:

<TABLE CELLPADDING=2 CELLSPACING=2 STYLE="page-break-before: always">
    <TR>
        <TD BGCOLOR="#f6b64c">
            <P STYLE="margin-bottom: 0in">Hotkeys</P>
            <TABLE CELLPADDING=2 CELLSPACING=2>
                <TR>
                    <TD>
                        <P>File</P>
                    </TD>
                </TR>
            </TABLE>
            <P><BR><BR>
            </P>
        </TD>
    </TR>
    <TR>
        <TD></TD>
    </TR>
</TABLE>

which is the same as what we see on the screen: the nested table is in the outer table's cell A1, not A2.

So saving and rendering agree with each other.

But we can go even further and examine the in-memory state using a macro I stitched together:

Sub Main
    doc = ThisComponent
    textTables = doc.getTextTables()
    text = "Have " & textTables.count & " tables." & Chr(13)
    text = text & "----------" & Chr(13)
    For i = 0 to textTables.count - 1
        table = textTables(i)
        rows = table.getRows()
        text = text & "Table " & i & " has " & rows.GetCount() & " rows" & "." & chr(13)
        columns = table.getColumns()
        For rowIndex = 1 To rows.getCount()
            For columnIndex = 1 To columns.getCount()
                cellName = Chr(Asc("A") - 1 + columnIndex) & rowIndex
                cell = table.getCellByName(cellName)
                innerTable = GetTableFromCell(cell)
                If IsNull(innerTable) Then
                    text = text & "Cell " & cellName & " has text: "  & cell.String & Chr(13)
                Else
                    text = text & "Cell " & cellName & " has a nested table"  & Chr(13)
                End If
            Next
        Next
        text = text & "----------" & Chr(13)
    Next
    MsgBox text
End Sub

Function GetTableFromCell(cell)
    e = cell.createEnumeration()
    While e.hasMoreElements()
        paragraph = e.nextElement()
        If paragraph.supportsService("com.sun.star.text.TextTable") Then
            GetTableFromCell = paragraph
            Exit Function
        End If
    Wend
End Function


which gives the output:

Have 2 tables.
----------
Table 0 has 2 rows.
Cell A1 has a nested table.
Cell A2 has text:
----------
Table 1 has 1 rows.
Cell A1 has text: File


This conclusively proves the in-memory state is wrong, and since it was created by loading the file, the process of loading the file must be buggy.

Unfortunately loading the file happens in the 47171 line of code filter under main/sw/source/filter/html.

Before we start trying to find the buggy code, it might be a good idea to get a deeper understanding of the bug with some tests.

In a 2x2 table:
- Nested table intended for A2 => ends up in B1
- Nested table intended for B2 => ends up in A2

BUT in a 2x2 table where A2 is just <TD/>, a nested table intended for B2 goes into B1, NOT A2!!!

In other words, a nested table is placed in its outer table's most recent NON-EMPTY cell.

SwHTMLParser::BuildTable() is called when parsing a table, and is called exactly twice in samples with one outer table and another nested table.

It really is in a monster sized file though, with 5579 lines, German comments, a large number of 3rd party classes, and generally difficult to work through.